GitHub’s new pull request review-stage metrics give delivery leaders a more specific way to discuss delayed changes: whether work is waiting for an initial review, moving slowly through review cycles, or remaining unmerged after final review. That is more useful for diagnosing delivery flow than a single end-to-end merge time, but it is not a complete measure of engineering productivity or individual performance.
What has changed
GitHub has added a pull_request_review_times array to enterprise and organisation repository-level Copilot usage-metrics reports on repos-1-day rows. For qualifying pull requests, it reports median and 90th-percentile durations in minutes for three intervals: ready for review to first review, first review to final review, and final review to merge. Durations are attributed to the day a pull request merged.
Why separating the stages matters
A long overall pull request cycle can conceal different operational problems. A delay before the first review may indicate competing priorities or limited review capacity. A long period between first and final review may point to extended feedback cycles or work that is difficult to assess. A delay after final review can raise questions about release coordination, ownership or the route from approval to merge. The metrics do not establish the cause, but they can make the right management conversation more precise.
Read typical experience alongside delayed cases
The median describes the middle of the qualifying pull requests merged in a period, so it is a useful view of the typical experience. The 90th percentile indicates how long the slower end of that group took. A wide gap between the two can suggest that a smaller set of unusually delayed pull requests is affecting delivery flow. Neither figure should be treated as a target in isolation: the complexity, risk and purpose of the work still matter.
Limits leaders should account for
- The timings cover pull requests opened by a person and reviewed by at least one other person. Only human reviews are timed.
- Copilot code reviews, other bot reviews and author reviews are excluded from the timing. A pull request reviewed by both a person and Copilot code review can still qualify.
- The review-time total is therefore usually lower than the wider merged-pull-request total, which can include pull requests merged without review.
- The data builds forward from the release date, so early reporting will be thin. Pull requests made ready for review before 21 September 2026 are excluded from this part of the data.
- An empty array on a day means that no qualifying pull requests merged; it does not mean review duration was zero.
- A first-to-final-review duration of zero can simply mean that a pull request received one review.
Use it as delivery evidence, not a scorecard
These measures are best used to identify questions worth investigating across a product or delivery process, rather than to rank people or teams. They omit work that never reaches merge, may not reflect all review activity, and cannot show whether a longer review produced a better outcome. Decisions should combine the figures with product priorities, release risk, the nature of the work and qualitative feedback from the people involved.
What good decision-making looks like
For a business deciding where to improve software delivery, the useful outcome is a clearer distinction between capacity issues, collaboration friction and post-approval flow. Before acting, leaders should ask whether the data represents the work they care about, whether the median and slower cases tell the same story, and whether any observed delay is materially affecting customer, commercial or product priorities. GitHub’s change offers a narrower diagnostic lens, not a verdict on delivery health.
OUROPT can support organisations that need to turn software-delivery evidence into better web product workflows and development decisions.
Explore our services →Sources and references
- Usage metrics API adds pull request review stagesGitHub Changelog · 25 September 2026