Enterprise Copilot adds granular pull‑request review timing metrics

GitHub’s Copilot usage metrics API now adds a pull_request_review_times array to each repos-1-day row, exposing median and 90th‑percentile durations for three distinct review stages. Engineers can now see whether a pull request is stalled waiting for a reviewer, caught in iterative feedback, or sitting approved but unmerged, which directly informs process tuning and capacity planning.

New Review‑Stage Timing Fields

The added array contains one entry per author/reviewer pair and includes:

• authored_by and reviewed_by: human participants for the PR.
• total_merged: count of qualifying PRs merged that day.
• median_minutes_ready_to_first_review and p90_minutes_ready_to_first_review: time from "ready for review" to the first human review.
• median_minutes_first_to_final_review and p90_minutes_first_to_final_review: time between the first and final human review.
• median_minutes_final_review_to_merge and p90_minutes_final_review_to_merge: time from the final review to merge.

All durations are expressed in minutes and are attributed to the day the PR merged. If a PR receives only a single review, the first‑to‑final stage reports zero.

Operational Impact and Data Interpretation

Only human reviews are timed; reviews generated by Copilot, other bots, or the PR author are excluded. Consequently, total_merged in this array is often lower than the overall pull_requests.total_merged count, which also includes PRs merged without any review. Data collection starts on the release date, so early days may show sparse or empty arrays. An empty array ( [] ) indicates a day with no qualifying merges, not a zero count.

Practitioners should treat the median as the typical case and the 90th percentile as an indicator of outliers that may be inflating overall cycle time. When the 90th percentile diverges sharply from the median, targeted investigation of the slowest PRs can reveal process or staffing bottlenecks.

Access and Availability

The metrics are available in enterprise and organization‑level reports for owners, billing managers, and any role granted the "View Copilot Metrics" permission. The underlying Copilot usage metrics policy must be enabled for the data to appear.

Related CloudNinjas coverage: AI engineering.

What This Means For Practitioners

Teams should integrate the new timing fields into existing CI/CD dashboards to surface stage‑specific latency. Monitoring the 90th‑percentile values can help prioritize reviewer capacity or automation improvements. Because bot‑generated reviews are omitted, engineers relying on Copilot for code review should still track separate Copilot‑specific metrics if needed. Finally, be aware that the dataset is forward‑only; historical analysis before the release date will be incomplete, so plan any trend analysis accordingly.