Copilot Code Review Addressed Rate: What It Measures

GitHub announced new Copilot code-review fields on November 5, 2026. Enterprise and organization repository-level usage reports now include a copilot_code_review object that counts evaluated comments, comments a developer addressed and pull requests merged without a later human change request. The release calls the ratio of addressed to evaluated comments an addressed rate. That label needs care: it measures a recorded response to feedback, not whether Copilot found a real defect or whether the final code is correct.

“Addressed” includes several kinds of developer response

GitHub evaluates comments when the pull request merges. A comment can count as addressed when a developer applies a suggestion, asks Copilot to make a fix, edits the code or replies that the issue will be handled in a later pull request. The event therefore captures interaction with feedback; it does not require a verified correction in the same change.

The denominator is total_comments_evaluated, and the numerator is total_comments_addressed. Because evaluation happens on merge, the activity lands on the merge day rather than the day Copilot posted the comment. Reports should preserve that timing rule when teams compare repositories or release periods.

Breakdowns can reveal policy effects without proving them

The API separates counts by severity, review tier, comment type and customization. Customization can include repository instructions, skills or MCP servers. These dimensions can help a team locate where comments are generated and which feedback receives a response.

A difference between groups is not automatically caused by the selected tier or customization. Repository complexity, reviewer practice and team experience can change at the same time. Use controlled pilots or matched comparisons, and inspect representative comments before presenting the metric as evidence of improvement.

A missing later change request is a narrow signal

GitHub also counts reviewed pull requests that merged without a person requesting changes after Copilot’s first review. That can show whether later human change requests occurred, but not that review was complete. A person may approve weak code, comment without using the change-request state or never review the same risk Copilot discussed.

Bot-authored pull requests can appear in this total even though Copilot usually does not evaluate individual comments on those pull requests. Keep the field separate from addressed rate and document which repositories, bots and branch rules are in scope.

Canadian teams should connect review metrics to verified outcomes

Organizations should limit access to roles that need it and document how repository activity is retained. Usage records can expose work patterns even without source code. Labour, privacy and internal-governance reviews may be appropriate before ranking teams or individuals.

Pair the fields with confirmed defect yield, false positives, human review time, escaped incidents and rework. The useful question is whether the review system improves independently checked outcomes—not whether developers respond to many automated comments.

Sources and editorial method

We use the linked original statements and reports to distinguish documented facts from our analysis. Company announcements describe their authors’ plans and claims; they are not independent verification of future outcomes. This article is dated and will be revised if material evidence changes. Read our editorial standards and corrections process.

GitHub: usage metrics API adds code review details and addressed rate ↗ — Official November 5, 2026 changelog; definitions, timing, access conditions and stated limitations.