GitHub has added pull request review stage timings to its enterprise and organization repository-level Copilot usage metrics API, according to a September 25, 2026 changelog entry.
A new pull_request_review_times array on each repos-1-day report row now reports the median and 90th-percentile duration (in minutes) for three review stages: from ready-for-review to first review, from first review to final review, and from final review to merge. Each entry also records the author and reviewer (both human in this release) and the count of qualifying merged pull requests for that day. Existing pull_requests fields are unchanged.
Only human reviews are timed. Reviews from Copilot code review, other bots, and the PR author are excluded, so a pull request reviewed by both a person and Copilot code review still appears in the data. As a result, the total_merged figure in pull_request_review_times is typically lower than the broader pull_requests.total_merged, which also counts merges with no reviews.
The data builds forward from the release date with no backfill; pull requests that became ready for review before September 21, 2026 are excluded from this section. Days with no qualifying merges return an empty array rather than a zero value, and the first-to-final review stage reads 0 when a pull request receives only a single review.
GitHub states the feature is present in the enterprise and organization repos-1-day reports. Access requires the Copilot usage metrics policy to be enabled and is available to enterprise owners, billing managers, organization owners, and users with a custom role granting the View Copilot Metrics permission.
In the changelog, GitHub frames the update as letting teams distinguish whether a pull request is waiting for an initial look, stuck in back-and-forth between reviewers, or sitting approved and unmerged—each pointing to a different operational fix. The 90th percentile alongside the median is intended to surface whether a small number of slow pull requests is driving overall delay.