GitHub now shows where human pull-request reviews wait

GitHub added review-stage durations to its repository-level Copilot usage reports on September 25. Teams can now see whether a human-reviewed pull request spent most of its time waiting for the first review, moving between reviews, or sitting between final review and merge. That is a more useful starting point for a workflow change than a single time-to-merge number.

What the daily report measures

The enterprise and organization repos-1-day reports add a pull_request_review_times array. Each entry separates the interval from ready for review to first review, first to final review, and final review to merge. GitHub provides a median and 90th percentile for each interval, in minutes, plus total_merged for the qualifying group. The durations are assigned to the day the pull request merged, not the day each review occurred.

The first interval can reveal a queue before anyone starts looking. A long first-to-final interval can reflect continued review discussion; for a pull request with only one review, that interval is zero. A long final-review-to-merge interval points to work after the last review, but the metric alone cannot say whether that delay came from checks, scheduling, or another cause. Compare the median with the 90th percentile to see whether the wait is typical or concentrated among slower merges.

Which pull requests belong in the comparison

GitHub includes pull requests opened by a person and reviewed by at least one other person. Author reviews, Copilot code reviews, and other bot reviews do not contribute to these timed intervals. A pull request with both a human review and a Copilot review can still qualify. That makes this a measure of a particular human-reviewed population, not all merged pull requests: pull_request_review_times[].total_merged will usually be lower than pull_requests.total_merged.

History needs care too. GitHub says the new data builds forward without a backfill, and pull requests that became ready for review before September 21, 2026 are excluded from the new section. An empty array on a day with no qualifying merges means there were no observations; it is not a measured zero-minute wait. Do not plot those days as zero or interpret the first few days as a complete baseline.

Use the slow stage to choose one experiment

For a repository with enough qualifying merges, compare the three stage distributions over a stable period and examine a sample of the slower pull requests. If the initial queue dominates, test clearer reviewer assignment or rotation. If the last interval dominates, inspect the actual merge checks and handoff before changing review policy. These are possible responses to observed waits, not claims that AI caused or solved them. The report does not establish how much Copilot improved productivity. For a different reporting trap, see why missing VS Code Agents metrics should stay distinct from zero.

Access requires the Copilot usage metrics policy and an eligible enterprise or organization role, including roles with the View Copilot Metrics permission. GitHub's usage metrics API documentation describes how to obtain the reports. The useful first decision is where to look at a real review queue, then whether a small process change reduces that specific delay without weakening review quality.