Introduction to the API update: Copilot usage metrics
GitHub has expanded its Copilot usage metrics API to show how developers respond to automated code review feedback and where missing editor telemetry limits usage reports. The additions answer two related questions: whether developers act on Copilot’s comments, and whether the organization has enough client data to interpret its usage metrics.
In two November 5 updates, GitHub describes repository-level review measurements alongside user-level telemetry and version checks. The review fields distinguish comments that developers acted on from suggestions they applied with a click. The telemetry fields identify users whose editor events are missing or whose IDEs or Copilot extensions fall below the minimum versions supported for usage metrics. Both updates cover enterprise and organization reporting. See GitHub’s announcements on code review details and addressed rate and telemetry and version gaps.
The distinction matters when interpreting the reports. An addressed review comment records a developer response, including some responses that defer a fix. Missing client telemetry, meanwhile, does not mean a user was inactive. These qualifications set the boundaries of what the new metrics can establish: they provide more detail about feedback handling and reporting coverage, without independently proving code quality or developer productivity.
Details on code review metrics
The review update adds a copilot_code_review object to every row in the enterprise and organization repos-1-day reports. It contains comment evaluation and response counts, breakdowns of those counts, and a count of merged pull requests without a subsequent human change request after Copilot’s first review.
The addressed rate uses two fields. total_comments_evaluated counts Copilot code review comments checked for a developer response. total_comments_addressed counts evaluated comments on which developers acted. GitHub defines the rate as total_comments_addressed divided by total_comments_evaluated.
That denominator is consequential: the rate concerns evaluated comments, rather than every comment posted during the reporting day. A report with no evaluated comments does not support a meaningful addressed-rate calculation. Consumers should preserve the underlying counts so that the rate remains interpretable.
What counts as addressed
GitHub’s definition includes applying a suggestion, asking Copilot to make a fix, editing the code, or replying that the fix will arrive in a later pull request. An addressed comment therefore signals action or an acknowledged plan; it does not necessarily establish that a correction has already landed.
This is broader than pull_requests.total_copilot_applied_suggestions, which counts only ready-to-apply suggestions that someone applied. GitHub says developers respond to most feedback through other routes. The new fields are intended to capture those routes, giving administrators a more complete view of responses than the existing suggestion count alone.
The two measurements should retain their separate meanings in a dashboard. A count of applied suggestions describes one specific action. An addressed-comment count describes a wider range of responses. Treating them as interchangeable would erase the distinction the update introduces.
Breaking down the feedback
Four fields provide breakdowns of evaluated and addressed comments:
| Field | Breakdown described by GitHub |
|---|---|
review_comments_by_severity | Severity, with examples including high, medium, and low |
review_comments_by_review_tier | Review tier, with examples including lite, balanced, and max |
review_comments_by_comment_type | Comment type, such as bug, security, or custom for repository coding guidelines |
review_comments_by_customization | Customization, such as custom instructions, skills, MCP servers, or none |
These dimensions make it possible to examine which categories of feedback developers address in a repository. For example, the comment-type breakdown can separate responses to security comments from responses to repository-specific guidance. The customization breakdown provides a way to inspect feedback associated with different customizations.
Such comparisons remain observational. A difference between categories does not, by itself, establish that a customization caused a better result. The supplied announcement describes the counts and their breakdowns, but supplies no benchmark demonstrating a quality improvement from any particular configuration.
Timing and population limits
Comments are evaluated when their pull request merges. They enter the counts on the merge day, even if Copilot posted them earlier. A daily change in addressed comments therefore reflects the feedback attached to pull requests merging that day; it should not automatically be interpreted as a change in comments posted that day.
GitHub also says Copilot usually does not evaluate comments on pull requests opened by bots, including Copilot cloud agent. This qualification matters when comparing comment metrics with total_merged_no_human_change_request_after_review. That field counts merged pull requests reviewed by Copilot where no person requested changes after Copilot’s first review, and it still includes bot-opened pull requests.
The comment counts and merged-pull-request count consequently have different population rules. The latter also describes a specific review sequence, not an independent finding that the code had no defects or needed no further attention.
For repositories with no Copilot code review activity that day, GitHub says counts are zero and arrays are empty. Those values represent the documented no-activity case in these repository reports.
User telemetry and version compliance
The second update addresses the completeness of usage reporting. GitHub says users without client telemetry still count as active, but their reports lack details such as lines of code, feature breakdowns, and model breakdowns. The new fields help distinguish that reporting gap from an absence of activity.
At the user level, client_telemetry_present indicates whether client telemetry arrived for the user that day. A value of false means Copilot detected the user’s activity but received no usage events from the editor. It is therefore a signal to investigate missing reporting detail, rather than evidence that the person did not use Copilot.
The companion field, usage_metrics_requirements, lists each user’s IDEs and Copilot extensions with a status of met, unmet, or unknown against the minimum supported versions. Here, version compliance concerns the requirements for usage metrics. The announcement does not establish a broader security or organizational compliance assessment.
GitHub identifies outdated editors or extensions, disabled IDE telemetry, and event-blocking proxies or firewalls as common causes of missing telemetry. The two new user signals help narrow a follow-up, but do not establish a single cause. A user can satisfy every version minimum and still lack telemetry, including when a proxy interferes with events.
Report scope and daily counts
The user fields appear in enterprise and organization user reports for both 1-day and 28-day reporting. Two aggregate fields expose the daily scale of the issue:
| Field | Meaning |
|---|---|
missing_client_telemetry_user_count | Users that day whose client_telemetry_present value is false |
below_usage_metrics_minimum_user_count | Users that day with at least one IDE or extension below the minimum version |
These counts appear in enterprise and organization 1-day reports and in each day_totals entry of 28-day reports. A longer reporting window does not turn them into counts of distinct people across the whole period: each value still concerns a single day.
There are two separate aggregation traps. First, a user can appear in both daily counts, so adding them does not produce the number of unique affected users. Second, adding daily counts across dates does not produce a unique-user total for the period. Reporting should preserve those distinctions rather than label either sum as a count of people affected.
Unavailable data needs separate treatment as well. GitHub says null or omitted values mean data is unavailable, not false or zero. Days before the release have no values. Filling those historical gaps with zeros would imply that nobody was affected when the report provides no such evidence.
These rules also prevent a misleading comparison with the repository review fields. The review announcement explicitly defines zero counts and empty arrays for days without review activity. The telemetry announcement explicitly defines null or omitted values as unavailable. Each report needs to be interpreted according to its own documented semantics.
Implications for developers
For teams assessing Copilot code review, the practical gain is a broader view of how feedback is handled. Counting only clicked suggestions misses responses made through code edits, requests for Copilot to fix an issue, or replies planning later work. The addressed rate can capture those responses, provided its label and explanation preserve that broad definition.
A useful reporting approach would display evaluated and addressed counts together with the rate, then inspect the supplied breakdowns where they answer a concrete question. The counts provide context for the ratio; the categories help locate differences in response patterns. Neither establishes that a high rate necessarily means better engineering outcomes. The announcement supplies no independent evaluation linking these measures to defect reduction or productivity.
Timing should shape any investigation. Because evaluation happens on merge, a team examining a day’s results should consider the pull requests that merged that day. Comparing that count directly with feedback posted on the same date would mix different events. Bot treatment creates another reason to avoid assuming every field covers the same set of pull requests.
For administrators responsible for usage reporting, the telemetry additions provide a way to identify both the size of a daily reporting gap and the users who may need follow-up. Aggregate counts show the daily extent; user fields indicate where investigation can begin. GitHub presents this as a way to close gaps without opening a support ticket, although the fields themselves do not guarantee a particular remediation will succeed.
An investigation can use the documented signals in sequence: check whether client telemetry is present, inspect version requirement statuses, then consider the other causes GitHub lists if versions meet the minimums. This is a diagnostic approach supported by the distinction between the fields, rather than an assumption that updating an extension resolves every missing event.
Taken together, the additions encourage more precise questions. For code review, the question becomes how developers responded to evaluated comments. For usage reporting, it becomes whether activity records include the client detail needed for analysis. Keeping those questions separate helps prevent a response metric from becoming an unsupported quality score, or a telemetry gap from becoming an unsupported judgment about a developer’s activity.
Access and permissions
Both announcements specify the same eligible roles: enterprise owners, enterprise billing managers, organization owners, and holders of custom organization or enterprise roles granting the View Copilot Metrics permission. The Copilot usage metrics policy must also be enabled.
Access planning therefore involves both the reader’s role and the reporting policy. An organization seeking to use the fields should verify that the intended report consumers have one of the documented access paths and that the policy prerequisite is satisfied. The supplied evidence does not specify endpoint syntax, authentication scopes, or numerical version minimums, so those implementation details cannot be established from these announcements alone.
The immediate value of the update lies in making two previously less visible aspects of reporting explicit: what happens after Copilot leaves review feedback, and where editor telemetry leaves gaps in usage detail. Extracting that value depends on preserving the definitions alongside the numbers—especially merge-day counting, the breadth of “addressed,” overlapping daily user counts, and the difference between unavailable data and zero.
