GitHub has extended the enterprise and organization repos‑1‑day usage reports with a new copilot_code_review object. The addition surfaces raw counts of review comments that were evaluated at merge time, how many were acted on, and a derived addressed‑rate, plus detailed breakdowns by severity, tier, comment type, and customization. Practitioners can now measure the effectiveness of Copilot’s code‑review suggestions directly from the metrics API.
New Fields in the Copilot Code Review Object
- total_comments_evaluated: number of Copilot review comments examined to determine developer action.
- total_comments_addressed: number of those comments that resulted in a concrete developer response – applying the suggestion, invoking Copilot to fix, editing the code, or noting a future fix.
- addressed rate: ratio of addressed to evaluated comments, calculated on the client side.
- review_comments_by_severity, review_comments_by_review_tier, review_comments_by_comment_type, review_comments_by_customization: counts split by high/medium/low severity, tier (lite, balanced, max), type (bug, security, custom), and customization (custom instructions, skills, MCP servers, none).
- total_merged_no_human_change_request_after_review: merged pull requests where no human requested changes after Copilot’s initial review.
Why the Metrics Matter for Engineering Teams
The addressed‑rate provides a concrete signal of how much Copilot feedback translates into code changes, complementing existing suggestion‑apply counters that only capture ready‑to‑apply actions. Teams can correlate severity or security‑type comments with actual remediation, informing whether Copilot is reducing manual review load or surfacing actionable security findings. The tier and customization breakdowns let architects evaluate the ROI of enabling higher‑tier models or custom instruction sets across repositories.
Operational and Access Considerations
These fields appear on every row of the daily enterprise/organization reports; rows with no activity default to zero counts and empty arrays. Evaluation occurs at pull‑request merge, so the metrics are attributed to the merge day, not the day Copilot posted the comment. Bot‑originated pull requests are generally excluded from comment evaluation, though they still count toward the total_merged_no_human_change_request_after_review metric. Access requires the Copilot usage metrics policy to be enabled and a role that grants the View Copilot Metrics permission (e.g., enterprise owners, billing managers, organization owners, or custom roles with that permission).
Related CloudNinjas coverage: AI engineering.
What This Means For Practitioners
Enable the Copilot usage metrics policy in your enterprise or organization settings and verify that relevant roles have the View Copilot Metrics permission. Pull the daily repos-1-day rows via the API and incorporate the new fields into existing observability dashboards. Track the addressed‑rate over time to spot regressions or improvements after changes to custom instructions, skill deployments, or tier upgrades. Use the severity and comment‑type breakdowns to prioritize security‑related feedback and to assess whether higher‑tier models are delivering measurable value. Finally, monitor the total_merged_no_human_change_request_after_review count to understand if Copilot reviews are reducing human change‑request cycles.
