GitHub Adds Pull-Request Review Stages to Copilot Usage Metrics
Enterprise and organization reports now show median and 90th-percentile time across three human review intervals, with clear exclusions and no historical backfill.
Edited by Tyronne Panaino
GitHub expanded its Copilot usage metrics API on September 25 so enterprise and organization reports can show how long pull requests spend in three stages of human review. Each repository-day row can now include median and 90th-percentile durations from ready for review to first review, first review to final review, and final review to merge.
The change gives engineering leaders a more specific view than a single end-to-end merge time. A long wait for the first response suggests a different workflow question from an extended review conversation or an approved change that remains unmerged. GitHub presents those distinctions as diagnostic signals; the new data does not by itself explain why any stage was slow.
Three intervals replace one opaque wait
The official GitHub announcement adds a `pull_request_review_times` array to each `repos-1-day` row. Entries include the number of qualifying pull requests merged that day and identify the author and reviewer classes. GitHub says both classes are human in this release.
For every stage, the API reports a median and a 90th percentile in minutes. The median describes the middle qualifying pull request, while the 90th percentile can expose a smaller group of much slower reviews. Comparing the two can help a team decide whether delay is broad or concentrated, but a metric difference is not proof of a particular cause.
Durations are assigned to the day a pull request merges. The existing `pull_requests` fields remain unchanged, so consumers need to add the new array without assuming it replaces earlier report fields. On a day with no qualifying merged pull requests, GitHub returns an empty array rather than a zero. When a pull request receives only one review, the first-to-final review interval is zero.
The population is deliberately narrower
GitHub counts pull requests opened by one person and reviewed by at least one other person. Reviews from Copilot code review, other bots and the author are ignored for timing purposes. A pull request that receives both a human review and a Copilot review can still qualify, because the human review supplies the measured review event.
That definition means the new `total_merged` value will usually be lower than the broader merged-pull-request total, which also includes changes merged without reviews. A team should therefore avoid comparing the two totals as if they covered the same population. The stages measure a defined human-review workflow, not all pull-request activity and not Copilot's own review latency.
There is also no historical backfill. Data accumulates from the release date, and pull requests that became ready for review before September 21 are excluded from the new section even though they remain part of the broader merged total. Early trend lines will consequently have a short observation window. That is a source-defined limit, not evidence of missing records in the older metrics.
Access and practical use
The data is available in enterprise and organization `repos-1-day` reports. GitHub says enterprise owners and billing managers, organization owners, and custom organization or enterprise roles with the `View Copilot Metrics` permission can access it; the Copilot usage metrics policy must also be enabled.
A useful first analysis is to retain the three stages separately and compare median with the 90th percentile over multiple merge days. Teams should annotate holidays, release freezes or process changes before interpreting a shift. Those are analytical recommendations, not claims that the API identifies root causes or measures developer performance.
Status
Confirmed. GitHub documents the new fields, population, access rules and lack of backfill. Internal confidence is medium because the evidence is a single first-party changelog entry and this run did not independently test API output or reporting completeness.
Sources
Update note: Last reviewed 2026-09-26. We will revise this post if GitHub changes the qualifying population, backfill policy, access rules or field definitions.
Sources
Drafted with AI assistance from source briefs; reviewed for citation completeness and label accuracy.