Copilot Code Review Metrics: What Addressed Rate Means

What changed on November 5

GitHub's November 5 announcement adds a copilot_code_review object to enterprise and organization repos-1-day rows. Addressed means acted on: applying a suggestion, asking Copilot to fix it, editing code, or replying that a later pull request will carry the fix. That last case makes this a feedback-response signal, rather than proof of corrected defects.

The repository reports became generally available on July 17, 2026. The organization route is GET /orgs/{org}/copilot/metrics/reports/repos-1-day?day=YYYY-MM-DD; an enterprise route replaces the organization scope with /enterprises/{enterprise}. Use the REST reference to check access and retrieve report download links. These examples below use invented counts; they are not observations from a GitHub account.

Start with the denominator

The formula is addressed rate = total_comments_addressed / total_comments_evaluated. The field definitions say ignored comments and comments later found wrong remain evaluated but unaddressed. Ready-to-apply suggestion counts are a different population. Do not substitute applied suggestions or reviewed pull requests for either operand.

Service A's six addressed comments could include four code edits and two replies deferring work. Its dashboard still reads 60%. A separate review of those four edits would be needed to establish whether any corrected a defect. Keep a follow-up issue and acceptance check for each deferred item; counting a response should not close that work in your team's tracker.

Service C and Service D need different labels. C has no denominator, so a percentage is undefined. D has five evaluated comments and no addressed ones, so 0% is meaningful. Showing both as zero would conceal the difference between no evaluation and evaluated feedback receiving no counted response. The example schema documents zero counts and empty arrays for a repository row without code review activity.

Attribute feedback to the merge day

GitHub evaluates comments when the pull request merges, assigning them to that date rather than their posting date. Bot-authored pull requests usually do not receive comment evaluation, although the separate no-human-change-request count includes them. Those scope rules come from the release notes.

Imagine a review on November 6 with ten comments. The developer edits four items and defers two, then merges on November 9. Put 10 evaluated and 6 addressed in the November 9 fixture. Do not move them back to November 6 to align them with a review-volume chart. A weekly comparison that ends before the merge will not yet contain that pull request's evaluated feedback.

For an operational report, label the period as a merge-day window and retain the requested report dates with the downloaded files. If a long-running migration merges in a batch, annotate that event beside the chart. A jump may reflect which work finally merged; investigate that possibility before treating it as evidence that a prompt or review policy improved.

Combine counts before dividing

For A and B together, the comment-weighted rate is (6 + 2) / (10 + 2) = 66.7%, rounded to one decimal place. Averaging 60% and 100% gives 80%, which answers a different question by giving each repository equal weight. State which question your dashboard answers. For a combined comment rate across disjoint repository-day rows, retain the numerator and denominator and calculate the ratio after aggregation.

This small JavaScript function implements that arithmetic and deliberately rejects missing, negative, fractional or inconsistent counts. Its null result is a presentation choice for a zero denominator, not an API status value. Supply a deduplicated set from one reporting scope; the function does not detect repeated rows or overlapping enterprise and organization exports.

function summarize(rows) {
  let evaluated = 0;
  let addressed = 0;
  for (const row of rows) {
    const c = row.copilot_code_review;
    const e = c?.total_comments_evaluated;
    const a = c?.total_comments_addressed;
    if (!Number.isSafeInteger(e) || !Number.isSafeInteger(a) ||
        e < 0 || a < 0 || a > e ||
        !Number.isSafeInteger(evaluated + e) ||
        !Number.isSafeInteger(addressed + a)) {
      throw new Error("Invalid or unavailable comment counts");
    }
    evaluated += e;
    addressed += a;
  }
  return { evaluated, addressed,
    rate: evaluated === 0 ? null : addressed / evaluated };
}

Before connecting your report loader, try four input cases: A alone should return 0.6; A plus B should return 8/12; C should return null; and a row with three addressed but two evaluated should throw. Also check that a missing object fails instead of silently becoming zero. These are arithmetic fixtures, not a test of how GitHub classifies real comments.

Keep breakdowns and quality evidence separate

The field reference lists breakdowns by severity, review tier, comment type and customization. Missing labels can leave severity, tier and type sums below the total. Multiple customizations can put their sum above it. The separate no-human-change-request metric excludes a pull request if someone requests changes after Copilot's first review, even if later dismissed. See the counting rules.

Use those distinctions to write a review agenda: inspect a sample of addressed high-severity comments, check whether deferred items have owners, and compare the actual patches with their regression checks. Our AI pull request review checklist gives that inspection a structure. Keep the conversation-resolution workflow separate from the new measurement; the arithmetic does not establish approval or repair quality.

GitHub also released telemetry and version-gap fields on November 5. Those describe client-data coverage, with unavailable values distinct from zero. Do not use them as a correction factor for addressed rate: their denominator concerns users, while this calculation concerns evaluated review comments.

A useful first dashboard therefore shows three things together: addressed/evaluated counts, the merge-day date window, and a separate list of deferred fixes awaiting verification. Begin with one repository and trace one merged pull request manually. Expand only after you can explain why its comments appear in the selected period and what evidence supports each claimed correction.