The GitHub Copilot usage metrics API now breaks down how long pull requests spend in three review stages. In daily repository-level repos-1-day reports, the new pull_request_review_times array provides the median and 90th percentile for the time from ready for review to first review, from first to final review, and from final review to merge. The practical benefit is that teams can separate delays that were previously hidden inside the overall merge time.
What changed in the API
Each pull_request_review_times entry contains authored_by, reviewed_by, total_merged, and six duration fields in minutes. In this first release, authored_by and reviewed_by are reported as human. The median and p90 pairs cover three stages:
- median_minutes_ready_to_first_review and p90_minutes_ready_to_first_review: from the moment the pull request becomes ready for review until its first human review.
- median_minutes_first_to_final_review and p90_minutes_first_to_final_review: from the first to the final human review.
- median_minutes_final_review_to_merge and p90_minutes_final_review_to_merge: from the final human review to merge.
Durations are attributed to the day the pull request merged. Existing fields in pull_requests remain unchanged.
What each stage can help diagnose
| Stage | Operational question | What a high value may indicate |
|---|---|---|
| Ready to first review | How long does code wait before someone starts reviewing it? | A review queue, limited reviewer availability, weak ownership routing, or poorly overlapping work hours. |
| First to final review | How long do review discussion and iterations take? | Multiple adjustment cycles, large scope, fragmented feedback, or dependency on several reviewers. |
| Final review to merge | How long does an already reviewed pull request remain unmerged? | Waiting for checks, deployment windows, external approval, merge policy, or pending operational work. |
These are diagnostic hypotheses, not automatic conclusions. The metric shows where time accumulates, but the cause still has to be investigated using repository and delivery-flow context.
Read the median and p90 together
The median represents typical behavior and is less sensitive to extreme cases. The 90th percentile exposes the slow tail: roughly 90% of cases are at or below that value, while the remainder are slower. A repository can have a healthy median and a very high p90, meaning most reviews move quickly but a meaningful subset experiences long waits.
For that reason, tracking only one overall merge-time average is not enough. For each of the three stages, it is useful to follow the median and p90 side by side. A derived p90-to-median ratio can also help expose dispersion, provided it is treated as a team-calculated indicator rather than an official API field. When the median is zero, the ratio should not be used.
Metrics worth tracking in practice
- Typical latency by stage: the three medians show where the normal flow spends the most time.
- Slow-tail latency by stage: the three p90 values highlight cases that fall outside typical behavior.
- Eligible volume: pull_request_review_times[].total_merged shows how many pull requests qualified for this slice on that day. Percentiles based on very low volume should be interpreted cautiously.
- Slice coverage: comparing pull_request_review_times[].total_merged with pull_requests.total_merged helps show how much of total merged volume is represented by human-review timing. This is a derived indicator, not a ready-made API field.
- Time trend: tracking daily values by repository helps determine whether a bottleneck is recurring or isolated. Medians and percentiles should not simply be summed to create a monthly percentile because percentiles are not additive.
Important limits of the new slice
The block covers pull requests opened by a person and reviewed by at least one other person. Reviews from Copilot code review, other bots, and the author are excluded from the stage timing. A pull request reviewed by both a person and Copilot remains eligible, but only human reviews are timed.
As a result, pull_request_review_times[].total_merged is generally lower than pull_requests.total_merged, which can also include pull requests merged without reviews. On days with no qualifying pull requests, the array is [], not zero. When there is only one review, the first-to-final review stage is zero.
There is also no complete backfill. GitHub states that data builds forward from the release and pull requests that became ready for review before September 21, 2026 are excluded from this section, even though they may still count toward pull_requests.total_merged. Early days can therefore have thinner samples.
Where the data appears and who can access it
The fields are available in daily repository-level repos-1-day reports for both enterprise and organization scopes. The API documentation describes endpoints such as GET /orgs/{org}/copilot/metrics/reports/repos-1-day?day=YYYY-MM-DD, which return temporary download links for the report.
Access depends on Copilot metrics permissions. Roles cited by GitHub include enterprise owners, enterprise billing managers, organization owners, and people with custom roles that grant the relevant Copilot metrics viewing permission. The Copilot usage metrics policy must also be enabled.
How to turn the new block into a useful dashboard
A simple implementation can store, for each repository and day, the six latency values plus total_merged. A dashboard can then display three median and p90 pairs with volume beside them. This prevents a p90 spike from being interpreted without knowing whether it represents dozens of pull requests or only a handful.
For operational analysis, the most useful approach is to compare the stages over time. If the largest delay is before the first review, investigation can start with reviewer capacity and routing. If it is between reviews, the focus can shift to change size, feedback clarity, and rework cycles. If it is after the final review, checks, policies, and integration processes are natural areas to inspect. The API identifies where delay appears in the lifecycle, but determining the cause and corrective action still depends on team context.
