Understanding GitHub Copilot Usage Metrics

GitHub Copilot usage metrics help organizations understand how developers are using Copilot across their repositories, teams, and enterprise.

For an individual developer, Copilot usage may simply mean accepting a code suggestion or asking a question in chat. For an organization, however, administrators may need a broader view:

• How many developers are using Copilot?

• Which Copilot features are being used?

• How frequently are developers engaging with Copilot?

• How much code-generation activity is occurring?

• Which repositories or teams are adopting Copilot?

• How is usage changing over time?

GitHub provides usage metrics through dashboards, APIs, and downloadable reports. These sources use the same underlying telemetry, but the data is aggregated and presented differently depending on the reporting surface.

This article explains the main concepts behind GitHub Copilot usage metrics and how developers, engineering managers, and administrators can interpret them correctly.

What Are GitHub Copilot Usage Metrics?

Copilot usage metrics are data points that describe how GitHub Copilot is being adopted and used.

GitHub groups the information around areas such as:

• Adoption

• Engagement

• Feature usage

• Code generation

• Code acceptance

• Pull request activity

• AI credits

• IDE and language usage

The exact fields available depend on the report and aggregation level.

For example, the current user-level schema includes fields such as:

{
  "day": "2025-10-01",
  "code_generation_activity_count": 3,
  "code_acceptance_activity_count": 3,
  "ai_credits_used": 12.5
}

GitHub's documented schema contains additional fields covering Copilot activity and feature usage.

The important point is that these metrics describe usage activity. They should not automatically be interpreted as a direct measurement of developer productivity or software quality.

Why Usage Metrics Matter

When an organization introduces an AI coding tool, simply assigning licenses does not tell you whether the tool is actually being used.

Consider an organization with 500 Copilot seats.

A licensing report can tell you that 500 seats exist.

Usage metrics can provide additional information about actual engagement.

For example:

Copilot seats
      |
      v
Active users
      |
      v
Feature usage
      |
      v
Code generation
      |
      v
Code acceptance
      |
      v
Pull request activity

This makes the data useful for understanding adoption patterns.

It can also help administrators identify areas where developers may need documentation, training, or better configuration.

Adoption vs Usage

One of the easiest mistakes is treating adoption and usage as the same thing.

They are different.

Adoption

Adoption answers a question such as:

How many assigned users are actually engaging with Copilot?

Usage

Usage provides more detail about what those users are doing.

For example:

Adoption
    |
    +-- User is active

Usage
    |
    +-- Code completions
    +-- Chat
    +-- Code generation
    +-- Code acceptance
    +-- Other Copilot features

An organization can therefore have high seat assignment but lower active usage.

That does not necessarily mean the product is failing. It may indicate that users have different workflows, different levels of experience, or different reasons for using the tool.

Important Copilot Metrics

GitHub's current metrics model contains a number of fields. The exact fields available can change as Copilot features and reporting evolve, so administrators should use GitHub's current schema when building reporting systems.

Some useful categories are described below.

Code Generation Activity

Code generation activity measures activity associated with Copilot generating code.

A simplified example could look like:

code_generation_activity_count = 25

This means the metric recorded 25 relevant code-generation activities for the reporting scope and period.

It should not be interpreted as "25 useful pieces of production code."

The metric describes activity, not business value.

Code Acceptance Activity

Code acceptance activity records activity associated with developers accepting Copilot-generated suggestions or output.

For example:

code_generation_activity_count = 25
code_acceptance_activity_count = 15

This can help organizations understand how generated suggestions are being used.

However, acceptance should not automatically be interpreted as code quality.

A developer may accept a suggestion and immediately modify it.

AI Credits Used

Current usage reporting can also include AI credit consumption.

For example:

{
  "ai_credits_used": 12.5
}

AI credits are relevant to Copilot's usage-based billing model and should be analyzed separately from adoption metrics. GitHub documents AI credits as part of usage-based billing for organizations and enterprises.

Lines of Code Metrics

GitHub also documents Lines of Code metrics.

These provide a directional measurement of Copilot output by quantifying lines of code suggested, added, or deleted across supported Copilot experiences.

This can be useful for understanding the scale of generated output.

However, there is an important limitation.

Lines of code are not the same as engineering value.

For example:

Developer A
    100 generated lines
    20 accepted lines

Developer B
    20 generated lines
    18 accepted lines

The numbers alone do not tell you which developer produced better software.

The code could differ dramatically in complexity and purpose.

For that reason, LOC metrics are better treated as directional telemetry rather than a standalone productivity score.

Pull Request Lifecycle Metrics

Copilot usage reporting can also provide visibility into pull request lifecycle trends.

This is useful because organizations often want to understand whether Copilot adoption is associated with changes in development workflows.

For example:

Copilot activity
       |
       v
Code changes
       |
       v
Pull request
       |
       v
Review
       |
       v
Merge

These metrics can provide additional context around the development process.

However, correlation does not establish that Copilot caused a particular change in pull request performance.

Other factors can influence pull request duration, such as:

• project complexity

• review requirements

• team size

• release schedules

• incident response

• changes in engineering processes

Where Can You Access Copilot Metrics?

GitHub currently provides Copilot usage metrics through several surfaces.

Dashboard

The Copilot usage metrics dashboards are available at enterprise and organization levels. They provide a UI-based way to explore adoption and usage information.

REST API

The REST API provides programmatic access to usage reports.

This is useful when an organization wants to integrate Copilot data into:

• internal dashboards

• BI systems

• scheduled reports

• data warehouses

• governance tools

Exported Reports

The API returns download links for generated reports.

The downloaded reports use formats such as NDJSON, which makes them suitable for processing large amounts of structured data.

Enterprise-Level Metrics

At the enterprise level, authorized users can retrieve Copilot usage metrics for the enterprise.

GitHub provides endpoints for:

Enterprise usage
Enterprise users
Enterprise user teams

For example, the API provides a 28-day enterprise report endpoint.

Conceptually:

Enterprise
    |
    +-- Organization A
    |      |
    |      +-- Users
    |
    +-- Organization B
           |
           +-- Users

This makes enterprise-level reporting useful when Copilot is managed centrally across multiple organizations.

Organization-Level Metrics

Organizations can also retrieve their own Copilot metrics.

For example, the REST API supports organization-level reports covering:

• organization usage

• organization users

• user-team relationships

The organization-level reports can be retrieved for a specific day or as a latest 28-day report.

This makes it possible to build reporting pipelines without manually downloading data from the dashboard.

User-Level Metrics

User-level metrics provide more detailed information about individual Copilot activity.

For example, a report may contain fields such as:

{
  "day": "2026-05-07",
  "user_login": "developer1",
  "code_generation_activity_count": 18,
  "code_acceptance_activity_count": 11
}

The exact schema depends on the report and available metrics.

Access to these reports is controlled. GitHub documents specific permissions for users who can retrieve Copilot metrics, including enterprise and organization owners and authorized custom roles with the relevant Copilot metrics permissions.

This matters because user-level reporting contains more detailed activity information than an aggregate organization dashboard.

Team-Level Metrics Require Additional Work

A common assumption is that the API provides one ready-made report for every team.

GitHub's current documentation explains that team-level metrics are not provided as a single pre-aggregated team report.

Instead, team-level metrics can be constructed by joining:

1. The daily user-teams report.

2. The daily per-user usage metrics report.

The shared user identity can then be used to associate activity with team membership.

The process looks like this:

User-Team Report
       |
       | user_id
       v
Per-User Usage Report
       |
       v
Join
       |
       v
Team-Level Metrics

This is useful for organizations that need custom team-level BI reporting.

Example: Downloading an Organization Report

A REST API request for the latest 28-day organization report follows this general structure:

curl -L \
  -H "Accept: application/vnd.github+json" \
  -H "Authorization: Bearer $GITHUB_TOKEN" \
  -H "X-GitHub-Api-Version: 2026-03-10" \
  "https://api.github.com/orgs/ORG/copilot/metrics/reports/organization-28-day/latest"

The response contains download links rather than placing the complete report directly in the API response. GitHub documents this behavior for the organization and enterprise usage metrics endpoints.

A simplified response looks like:

{
  "download_links": [
    "signed-report-download-link"
  ],
  "report_start_day": "2026-08-01",
  "report_end_day": "2026-08-28"
}

The actual signed URL should be downloaded within its validity period.

Example: Calling the API From C#

If you are building an internal reporting service in .NET, HttpClient can be used to call the API.

using System.Net.Http.Headers;

var organization = "my-organization";
var token = Environment.GetEnvironmentVariable("GITHUB_TOKEN");

if (string.IsNullOrWhiteSpace(token))
{
    throw new InvalidOperationException(
        "GITHUB_TOKEN is not configured.");
}

using var client = new HttpClient();

client.DefaultRequestHeaders.UserAgent.ParseAdd(
    "CopilotMetricsReporter");

client.DefaultRequestHeaders.Authorization =
    new AuthenticationHeaderValue("Bearer", token);

client.DefaultRequestHeaders.Accept.ParseAdd(
    "application/vnd.github+json");

client.DefaultRequestHeaders.Add(
    "X-GitHub-Api-Version",
    "2026-03-10");

var endpoint =
    $"https://api.github.com/orgs/{organization}" +
    "/copilot/metrics/reports/organization-28-day/latest";

using var response = await client.GetAsync(endpoint);

response.EnsureSuccessStatusCode();

var json = await response.Content.ReadAsStringAsync();

Console.WriteLine(json);

The example deliberately reads the token from an environment variable rather than placing it directly in the application.

For production reporting tools, authentication should use the least privilege required by the selected endpoint.

Understanding the API Permissions

Access to Copilot metrics is not automatically available to every GitHub user.

For organization-level metrics, GitHub documents the Organization Copilot metrics read permission for fine-grained tokens. Enterprise metrics similarly require the corresponding enterprise permission.

Depending on the authentication mechanism, GitHub also documents relevant classic OAuth or personal access token scopes.

The practical rule is:

Give the reporting application only the access it actually needs.

If a service only needs organization-level metrics, there is little reason to grant it broader enterprise administration privileges.

Data Freshness Matters

Copilot metrics are generated and processed over time.

For example, GitHub's API documentation describes daily reports and latest 28-day reports. The data represents completed reporting periods rather than necessarily being a live stream of every Copilot event.

This matters when creating dashboards.

Do not label a report:

Live Copilot Usage

unless the underlying data actually supports that interpretation.

A better approach is to display the reporting period:

Copilot Usage
August 25 – September 21

That makes the meaning of the numbers clearer.

Reconciling Dashboard and API Numbers

You may sometimes see different numbers between a dashboard, an API report, and an exported file.

That does not automatically mean that one source is wrong.

GitHub explains that these surfaces use the same underlying telemetry but aggregate and present the information differently.

When reconciling data, check:

1. Reporting period

2. Enterprise vs organization scope

3. Aggregation level

4. Metric definition

5. Data processing status

6. Filters applied by the dashboard

7. User or repository scope

A useful internal report should always document these dimensions.

What Usage Metrics Do Not Tell You

This is one of the most important sections for anyone building an internal Copilot dashboard.

Usage metrics can tell you about activity.

They do not automatically tell you:

• whether generated code is high quality

• whether a developer became more productive

• whether code is more maintainable

• whether security improved

• whether a project was delivered faster because of Copilot

• whether a developer is a strong or weak engineer

For example:

High Copilot usage
        ≠
High software quality

and:

Low Copilot usage
        ≠
Low developer performance

There are many legitimate reasons developers use Copilot differently.

Common Mistakes

Mistake 1: Treating Acceptance as Quality

A high acceptance count does not prove that generated code was high quality.

Review actual engineering outcomes separately.

Mistake 2: Using LOC as a Productivity Score

Lines of generated or accepted code provide directional information, but they are not a complete productivity measurement. GitHub itself describes LOC metrics as directional.

Mistake 3: Ignoring the Reporting Period

A 28-day report and a daily report should not be compared without considering their time windows.

Mistake 4: Assuming Team Data Is Directly Available

Current team-level raw reporting requires joining user-team data with per-user usage data.

Mistake 5: Giving the Reporting Tool Excessive Permissions

Metrics reporting should use the smallest appropriate permission set.

Best Practices

Define the Question Before Selecting the Metric

Start with the business or engineering question.

For example:

Question:
Are developers actively using Copilot?

Metric:
Adoption and engagement

Rather than:

Question:
Are developers productive?

Metric:
Lines of code

The second approach can lead to misleading conclusions.

Use Multiple Metrics Together

A useful report might combine:

Adoption
+
Feature usage
+
Code generation
+
Code acceptance
+
Pull request trends

This gives more context than one number.

Keep Usage and Quality Separate

Pair Copilot telemetry with existing engineering signals such as:

• test results

• code review outcomes

• defect trends

• deployment frequency

• incident data

• cycle time

These should be analyzed together rather than treating one metric as a complete answer.

Document Metric Definitions

If an internal dashboard contains:

Acceptance Rate: 42%

document exactly how that number was calculated.

For example:

Accepted code-generation activity
---------------------------------
Total code-generation activity

Without a clear definition, two dashboards can calculate apparently similar metrics differently.

Advantages and Disadvantages

A Practical Reporting Model

For an internal engineering dashboard, a useful structure could be:

Copilot Overview
|
+-- Adoption
|     +-- Assigned users
|     +-- Active users
|
+-- Engagement
|     +-- Feature activity
|     +-- Code generation
|     +-- Code acceptance
|
+-- Cost / Usage
|     +-- AI credits
|
+-- Engineering Context
      +-- Pull request trends
      +-- Review activity
      +-- Delivery metrics

The key is to keep Copilot usage metrics in context.

Summary

GitHub Copilot usage metrics provide organizations with structured information about how Copilot is being adopted and used.

The available data covers areas such as adoption, engagement, code-generation activity, code acceptance, lines of code, AI credits, and pull request lifecycle trends. GitHub makes this information available through dashboards, APIs, and reports.

For organizations building custom reporting, the REST API is particularly useful because it provides downloadable daily and 28-day reports at enterprise and organization scopes, along with detailed user-level data.

The most important thing to remember is that usage metrics measure activity, not developer quality. A strong reporting system should use Copilot metrics as one source of engineering information and combine them with broader development and delivery signals.

When interpreted in that context, Copilot metrics can help teams understand adoption, identify usage patterns, plan enablement, and build more informed internal reports without reducing software development to a single number.