GitHub has added human pull-request review-stage timing data to its Copilot usage metrics. The new pull_request_review_times field is available in enterprise- and organization-level repository reports generated for a single day, giving engineering and platform teams more detail than a basic merged-pull-request count.
The data separates time spent waiting for the first review, moving through the review process, and reaching merge after the final review. That makes it useful for locating workflow bottlenecks, although it should not be treated as a complete measure of every pull request or every type of review activity.
What changed in the usage metrics API
Repository-level repos-1-day reports now include a pull_request_review_times array. Each entry identifies the pull-request author and reviewer, counts qualifying merged pull requests through total_merged, and reports timing statistics for three stages:
- Ready for review to the first review
- First review to the final review
- Final review to merge
For each stage, the report provides median and 90th-percentile duration values. Durations are expressed in minutes and attributed to the day the pull request merged, rather than necessarily the day on which a review action occurred. The GitHub changelog announcement describes the new field and its qualification rules.
The feature applies to qualifying pull requests opened by a person and reviewed by at least one other person. Only human reviews are timed. Reviews performed by Copilot code review, other bots, or the pull-request author are ignored for this section. A pull request reviewed by both a person and Copilot code review remains eligible because it includes a human review.
Why the three stages matter
A single end-to-end merge duration can hide where work is slowing down. These separate measurements allow teams to distinguish between several different operational patterns.
A high ready-for-review-to-first-review value can indicate that pull requests are waiting too long before someone begins reviewing them. A large first-review-to-final-review value may point to extended discussion, multiple review cycles, or changes requested during review. A high final-review-to-merge value can indicate delays after the review process has effectively finished.
Comparing the median with the 90th percentile can also show whether delays are broadly distributed or concentrated in a smaller group of pull requests. That distinction matters when engineering leaders assess process changes or evaluate whether review queues are affecting delivery performance.
These metrics are specifically about the qualifying reviewed population. The value of pull_request_review_times[].total_merged will generally be lower than pull_requests.total_merged, because the latter also includes pull requests merged without reviews. The two counts should not be substituted for one another in dashboards or reports.
Availability and report behavior
According to GitHub’s Copilot usage metrics reference, repository-level reports are available at both enterprise and organization scope. The new field is supported in enterprise and organization repos-1-day reports. Reports contain one record per repository with pull-request activity for the requested day.
GitHub generates these reports daily, and each report covers a complete processed day. The documented enterprise request uses the following endpoint pattern:
GET /enterprises/{enterprise}/copilot/metrics/reports/repos-1-day?day=DAYThe day value uses YYYY-MM-DD format. GitHub’s REST documentation shows application/vnd.github+json and API version 2026-03-10 in its example. The response provides links for downloading generated reports, and those signed URLs are time-limited. The documentation supplied for this update does not specify the exact expiration duration.
The exact organization-level endpoint path and a complete field-by-field response example for pull_request_review_times are not established in the available documentation. Teams should therefore avoid assuming that the enterprise endpoint pattern can be reused for organization requests.
No historical backfill
The new review-stage section does not include historical backfill. Data builds forward from the release, and pull requests that became ready for review before September 21, 2026 are excluded from pull_request_review_times. Those pull requests remain included in pull_requests.total_merged.
This boundary is important when establishing a baseline. The first reports collected after the September 25, 2026 announcement should not be compared with older data as though the new review-stage measurements had always been present. Teams may need to label the initial period clearly and wait for a consistent forward-looking dataset before using it for trend analysis.
An empty pull_request_review_times array means that the repository and day had no qualifying merged pull requests. It is not a measured zero-minute duration. A pull request with only one review has a first-review-to-final-review value of zero because the first review is also the final review.
Requirements and administrative considerations
The Copilot usage metrics policy must be enabled throughout the enterprise before the metrics endpoints are available. Access also requires an authorized GitHub role or a custom role with the relevant View Copilot Metrics permission. The supplied documentation identifies enterprise owners, billing managers, organization owners, and supported custom-role permissions, while documenting enterprise endpoint token permissions separately.
Organization-specific authentication roles, token types, and fine-grained permissions for the repository report endpoint are not fully established in the available reference material. Administrators should use the permissions documented for their scope rather than extrapolating from the enterprise endpoint.
The report data identifies pull-request authors and reviewers. That makes access control and data-governance practices relevant for organizations that use the metrics in internal dashboards or developer-experience systems. Signed report URLs should also be treated as access-controlled links and should not be exposed unnecessarily.
What you should do
- Update report consumers. Add handling for the
pull_request_review_timesarray in repository-level daily report processing. - Separate the counts. Keep
pull_request_review_times[].total_mergeddistinct frompull_requests.total_mergedso reviewed and unreviewed pull requests are not conflated. - Handle empty arrays correctly. Represent an empty array as no qualifying activity, not as a zero-duration observation.
- Document the population. Make clear that the timings exclude bot reviews, Copilot code review, author reviews, and pull requests without a qualifying human review.
- Mark the baseline boundary. Account for the September 21, 2026 cutoff and the lack of historical backfill when building trends.
- Confirm access before retrieval. Enable the Copilot usage metrics policy and use documented permissions for the relevant enterprise or organization scope.
- Plan for normal REST limits. Inspect
x-ratelimit-*response headers, handle 403 and 429 responses, and use delayed or exponential backoff when required. GitHub has not documented an endpoint-specific rate limit for these reports.
The new measurements provide a more useful view of human review flow, but they remain a focused operational signal rather than a universal pull-request performance metric. Teams should combine them with an understanding of report scope, qualifying-review rules, and the absence of historical backfill before using them to compare repositories or evaluate changes to the development process.
