Development Activity Versions

• Overview
• Available Versions
• What Version 2.0 Changes
• Selecting a Version
• Which Version to Use

The Development Activity and GitHub Activity metrics have two versions. Version 2.0 focuses on the work done by people. Unlike version 1.0, it does not count bots or automation that runs under a personal account.

Version 1.0 reflects GitHub activity as it is. It counts the events a project generates, regardless of whether a person, a bot or a script produced them.

As bots, automation and AI agents produce a growing share of GitHub activity, version 2.0 takes a different approach. It aims to approximate how much people take part in developing a project.

Version 2.0 does not try to tell apart work a developer does alone from work they do with the help of AI tools. If a developer uses AI assistance and their activity follows normal human patterns, it is counted like any other activity. Version 2.0 removes only bots and spam-like, high-volume activity that can inflate the metric far beyond the real development effort.

Versions are available only for the metrics computed on the fly:

The precomputed metrics (dev_activity_1d, github_activity_1d, ecosystem_dev_activity, ecosystem_github_activity), the change metrics and the contributors count metrics have only version 1.0.

All versions of the development activity metrics are free and available on every plan, including anonymous requests.

You can pass either the version ("2.0") or its name ("modern:v1") as the version argument. Both return the same data.

In version 1.0, dev_activity counts every event except a list of non-development events, such as issues, comments, forks and stars. GitHub event types that are not on that list, including any new ones, are counted.

In version 2.0, dev_activity counts only these events:

• PushEvent - pushing commits;
• PullRequestEvent - opening, closing and merging pull requests;
• PullRequestReviewEvent - reviewing pull requests;
• PullRequestReviewCommentEvent - commenting in a pull request review;
• ReleaseEvent - publishing releases.

Creating and deleting branches and tags (CreateEvent, DeleteEvent) is not counted. How many branches a team creates depends on its workflow, for example one branch per pull request, rather than on the amount of work done. Any other event type, including ones GitHub introduces later, is not counted as development activity.

github_activity still counts every event type.

Version 2.0 does not count events by these accounts in either metric:

• GitHub apps, whose names end in [bot] (for example dependabot[bot]);
• machine accounts whose names end in -bot;
• other known bot accounts, such as copilot.

Some automation runs under a regular user account, so its name does not show that it is a bot. Version 2.0 treats a contributor’s day in an organization as automation if the contributor has, on that UTC day:

• development events in 20 or more different hours of the day, or
• 100 or more development events within a single hour.

A person does not work around the clock or at that pace. All events of that contributor in that organization on that day are left out of both metrics.

Only development events count toward these limits. A burst of other events, such as deleting many merged branches at once, is not treated as automation.

Version 2.0 limits how much a single contributor can add to the metric. A contributor’s development events in one repository on one UTC day count as at most 100 events.

If a contributor has more than 100 development events in a repository on a day, each of their events in that repository on that day gets the weight 100 / development events. For example, 400 pushes in a day count as 100 events, each with a weight of 0.25.

github_activity uses the same weight for the contributor’s other events in that repository on that day. Only development events decide the weight, so a contributor with only non-development events in a repository on a day is not capped.

Because of the weights, version 2.0 returns decimal values, while version 1.0 returns whole numbers.

In version 2.0, github_activity includes every event dev_activity counts, with the same weights and the same days left out as automation. Because of this, github_activity is never lower than dev_activity in version 2.0.

The automation checks and the daily cap are computed over whole UTC days. The value of an event does not depend on the time range or interval of the query. With intervals shorter than a day, such as 1h, the cap still applies to the whole day.

Pass the version name or number in the version argument of getMetric. When version is omitted, the API returns version 1.0.

1
{
2
  getMetric(metric: "dev_activity", version: "modern:v1") {
3
    timeseriesDataJson(
4
      slug: "ethereum"
5
      from: "utc_now-30d"
6
      to: "utc_now"
7
      interval: "1d"
8
    )
9
  }
10
}

Compare the two versions side by side using GraphQL aliases:

1
{
2
  original: getMetric(metric: "github_activity", version: "original:v1") {
3
    timeseriesDataJson(
4
      slug: "ethereum"
5
      from: "utc_now-30d"
6
      to: "utc_now"
7
      interval: "1d"
8
    )
9
  }
10
  modern: getMetric(metric: "github_activity", version: "modern:v1") {
11
    timeseriesDataJson(
12
      slug: "ethereum"
13
      from: "utc_now-30d"
14
      to: "utc_now"
15
      interval: "1d"
16
    )
17
  }
18
}

Fetch the total over a period with aggregatedTimeseriesData:

1
{
2
  getMetric(metric: "dev_activity", version: "modern:v1") {
3
    aggregatedTimeseriesData(
4
      slug: "ethereum"
5
      from: "utc_now-30d"
6
      to: "utc_now"
7
      aggregation: SUM
8
    )
9
  }
10
}

List the versions of a metric, with their names and descriptions:

1
{
2
  getMetric(metric: "dev_activity") {
3
    metadata {
4
      availableVersions {
5
        version
6
        versionName
7
        description
8
      }
9
    }
10
  }
11
}

Use version 2.0 to measure how much people work on a project. It is better for comparing projects, because a project’s numbers do not grow with the number of bots it runs, how often its automation runs, or how it uses branches.

Use version 1.0 when you need the values that existing dashboards, alerts or stored datasets are based on, or when you want the precomputed metrics (dev_activity_1d, ecosystem_dev_activity and others), which are only available in version 1.0.

Use one version for all queries in a single analysis, dashboard or backtest. The values of the two versions are computed differently and should not be mixed.

For general information about metric versions, see Metric Versions.