GitHub Copilot Code Review Metrics API Adds Comment Addressed Rates by Repository

The repository-level endpoints return a daily, per-repository breakdown of pull request activity for Copilot coding agent and Copilot code review. They are GET /enterprises/{enterprise}/copilot/metrics/reports/repos-1-day?day=YYYY-MM-DD and the matching /orgs/{org}/ path. GitHub's November 5, 2026 changelog adds a copilot_code_review object to every row of those reports.

What the new object contains​

According to the changelog, the object holds these fields:

• total_comments_evaluated is the number of Copilot code review comments checked to see whether the developer acted on them.
• total_comments_addressed is the number of those comments the developer acted on. Acting includes applying the suggestion, asking Copilot to make the fix, editing the code, or replying that the fix will come in a later pull request.
• Four breakdown fields split both counts by dimension:
  • review_comments_by_severity (for example high, medium, low).
  • review_comments_by_review_tier (lite, balanced, max).
  • review_comments_by_comment_type (bug, security, or custom for a repository's own coding guidelines).
  • review_comments_by_customization (custom instructions, skills, MCP servers, or none).
• total_merged_no_human_change_request_after_review is the number of merged pull requests reviewed by Copilot code review where no person requested changes after Copilot's first review.

The addressed rate isn't a returned field. GitHub tells you to divide addressed by evaluated yourself, so your reporting pipeline has to do the math.

Why it matters​

The older numbers were weak proxies. GitHub earlier pitched applied suggestions as a signal of actionable feedback. That only captured clicks on ready-to-apply suggestions. Developers often fix an issue by hand, so those fixes never showed up.

The changelog states the difference directly. pull_requests.total_copilot_applied_suggestions counts only suggestions that someone applied. The new counts cover every evaluated comment, however the developer responded. Don't treat the addressed rate as a suggestion-application rate, and don't compare the two numbers directly.

The breakdown by customization is the part likely to interest admins most. If you've invested in custom instructions, skills, or MCP servers for review, you can compare addressed rates with and without them. GitHub says the fields show whether those customizations make a difference. A difference in the data is still observational, not proof of cause.

Reading the data correctly​

Several rules in the changelog change how you should interpret a row:

1. Merge-day attribution. Comments are evaluated when their pull request merges. They count on the merge day, not the day Copilot posted them. A daily chart tracks merge activity, not review activity.
2. Empty days. Counts are 0 and arrays are empty when a repository had no Copilot code review activity that day. Treat that as no data, not as poor performance.
3. Division by zero. Where total_comments_evaluated is 0, the addressed rate is undefined. This is my own practical note, not a GitHub rule. Skip those rows rather than plotting 0%.
4. Bot-authored pull requests. Copilot usually doesn't evaluate comments on pull requests opened by bots, such as Copilot cloud agent. total_merged_no_human_change_request_after_review still includes those pull requests. The comment counts and the merged-PR count therefore don't cover exactly the same set of pull requests.
5. Clean merges aren't proof of quality. The merged-without-change-request count describes a sequence of events. It doesn't show that the code was correct or that Copilot caught everything. Reviewers might simply have approved quickly.

Daily repository rows can also be small. GitHub gives no guidance on minimum sample sizes. Aggregating over weeks before comparing repositories is a sensible habit, though that is general analytics advice, not GitHub guidance.

Access and retrieval​

The changelog says access is open to enterprise owners, enterprise billing managers, organization owners, and anyone with a custom organization or enterprise role that grants the View Copilot Metrics permission. The Copilot usage metrics policy must be enabled.

GitHub's REST documentation adds some specifics:

• The reports return signed download links to NDJSON files, not an inline body. Reports are generated daily and the links expire after a limited time.
• The day query parameter is required and uses YYYY-MM-DD format.
• Only repositories with pull request activity on the requested day appear in the report.
• Documented status codes for the repository endpoints include 200, 204 (no content), 403, 404 and 500.
• For the enterprise endpoint, OAuth app tokens and classic personal access tokens need either manage_billing:copilot or read:enterprise. For the organization endpoint they need read:org.
• Fine-grained tokens need the Enterprise Copilot metrics or Organization Copilot metrics read permission. The documented request examples send X-GitHub-Api-Version: 2026-03-10.

How this fits GitHub's metrics rollout​

This is another step in a steady expansion. GitHub added Copilot-reviewed merge counts and median time to merge in April. In July it made the repository-level reports generally available. The repository docs now also include pull request review-stage durations. Those durations time only human reviews and ignore Copilot and other bots.

Taken together, the reports are moving from "how much is Copilot used?" toward "what happens afterward?" That is the question finance and engineering leaders ask when licenses come up for renewal.

Bottom line​

For teams running Copilot code review, the new fields give a better measure of whether feedback gets acted on than the old applied-suggestion count. They aren't a quality score. Pair the addressed rate with merge-day timing, bot-PR exclusions and a reasonable sample size before putting it in front of leadership.