Pull request cycle time: measure where a PR really waits

Pull request cycle time has always been a single number that hid the answer. GitHub's usage metrics API now splits it into three: how long a pull request waits for its first review, how long it spends between first and final review, and how long it sits approved before anyone merges it. Each stage reports a median and a 90th percentile in minutes.

The change landed on 25 September 2026. What follows is what the API returns, and then our own mapping from each stage to the fix that actually moves it — that second part is ours, not GitHub's.

What the new pull request cycle time fields contain

The enterprise and organization repository-level Copilot usage metrics reports now carry a pull_request_review_times array on each repos-1-day row. GitHub documents each entry as containing:

• authored_by and reviewed_by — who opened and who reviewed. Both are human in this release.
• total_merged — the number of qualifying pull requests merged in that repository that day.
• median_minutes_ready_to_first_review and p90_minutes_ready_to_first_review.
• median_minutes_first_to_final_review and p90_minutes_first_to_final_review.
• median_minutes_final_review_to_merge and p90_minutes_final_review_to_merge.

Durations are in minutes and attributed to the day the pull request merged. The existing pull_requests fields are unchanged, so nothing you already chart breaks.

Read the counting rules before you read the numbers. Only pull requests a person opened and at least one other person reviewed are counted, and only human reviews are timed — reviews from Copilot code review, other bots and the author are ignored. A pull request reviewed by both a person and Copilot code review still counts. GitHub is explicit that this makes pull_request_review_times[].total_merged usually lower than pull_requests.total_merged, which also counts pull requests merged with no review at all.

Three more details will otherwise waste an afternoon. There is no backfill: data builds forward from the release date, and pull requests that became ready for review before 21 September 2026 are excluded from this section. A quiet day returns an empty array rather than zeros. And the first-to-final stage is legitimately 0 when a pull request got a single review — that is not missing data.

Who can pull the data, and how

Access is narrower than most engineering metrics dashboards assume. Enterprise owners and billing managers, organization owners, and anyone holding a custom organization or enterprise role that grants the View Copilot Metrics permission can read these reports, and the Copilot usage metrics policy must be enabled. If your delivery lead is not one of those, someone who is will be running the export.

Mechanically, the Copilot usage metrics API does not hand you JSON rows directly. You call GET /enterprises/{enterprise}/copilot/metrics/reports/repos-1-day?day=YYYY-MM-DD or the /orgs/{org}/ equivalent, and get back signed download links to NDJSON report files with a limited expiration. That shape suits a nightly job that pulls the previous day and appends, not a dashboard that queries live.

Which stage is slow, and what each one means

This section is our interpretation, not GitHub's. GitHub says only that the three stages point to different fixes; the diagnoses and the fixes below are ours, drawn from the teams we work with.

Slow stage	What it usually means	What actually fixes it
Ready to first review	Nobody owns the queue. Reviewers are heads-down on their own work and a pull request is nobody's task until someone complains.	Assign review as work, not goodwill: a named reviewer on open, a daily review slot, and a WIP limit so authors cannot start a fourth branch while three wait.
First to final review	Either the change is too large to hold in one head, or the team is arguing about something that was never decided — style, architecture, scope.	Smaller diffs and a written decision. If the same argument recurs, it is a standards problem, not a review problem; settle it once in a linter or an ADR.
Final review to merge	The bottleneck is mechanical: a flaky or slow CI run, a merge queue, a release freeze, or an author who has moved on and is not watching.	Fix the pipeline, not the people. Auto-merge on green, and treat a long tail here as a CI reliability metric rather than a review metric.

In the teams we work with, the first stage is usually the longest, and it is also the one people guess wrong about most often. Engineers remember the review that took four rounds of argument; they do not remember the two days the pull request sat untouched, because nothing happened during them. That is exactly the wait the ready-to-first-review median now makes visible.

Read the p90 before you read the median

The median tells you what a normal pull request experiences. The 90th percentile tells you whether a small number of slow pull requests is dragging delivery, and GitHub makes that point itself in the changelog. A repository with a 90-minute median and a 40-hour p90 does not have a review problem across the board — it has a specific class of change nobody wants to pick up. Find that class before you change anyone's process.

Two more cautions. Attributing durations to the merge day means a week of stalled work lands as one bad Friday, so read weekly, not daily. And because only human reviews are timed, a team that leans on AI code review automation for the first pass will see a first-review time that reflects the human who came second, not the bot that came first.

What to do with pull request cycle time once you have it

Publish the three stages, not the total, and publish them per repository. An aggregate across forty repositories averages a healthy service with a legacy monolith and tells you to fix neither. Then pick the single slowest stage in the two or three repositories that carry your roadmap, and change one thing.

Resist turning this into a per-person scoreboard. The fields are attributed to repositories and to human authors and reviewers, not designed as an individual performance measure, and the moment reviewers believe they are being timed you get fast approvals rather than fast reviews. The same failure mode we described when agents started writing the diff applies here: the metric moves, the quality does not.

If the slow stage turns out to be final review to merge, the problem is probably not review at all. That is a pipeline question, and the practical fixes are the ones in our write-up of speeding up CI pipeline runs under AI-era load — shorter critical paths, fewer serialised gates, and a merge queue that is not the slowest thing in the build. Where the bottleneck is test reliability rather than test duration, that belongs with your QA and automation practice.

Start the nightly export now rather than when you next need the argument. There is no backfill, so the history you will want in January is the history you begin collecting this week.