Usage metrics API adds pull request review stages

GitHub added a `pull_request_review_times` array to its enterprise and organization repository-level Copilot usage metrics reports, breaking pull request review time into three stages: ready-for-review to first review, first review to final review, and final review to merge, each reported as a median and 90th percentile in minutes. The array appears on each `repos-1-day` row and counts only pull requests opened by one person and reviewed by at least one other person, with Copilot code review, bot, and author reviews excluded, so `pull_request_review_times[].total_merged` is usually lower than `pull_requests.total_merged`. Data builds forward from the release date with no backfill, and pull requests that became ready for review before September 21, 2026 are excluded from the new section.

Usage metrics API adds pull request review stages The enterprise and organization repository-level Copilot usage metrics https://github.blog/changelog/2026-07-17-repository-level-github-copilot-usage-metrics-generally-available/ reports now break down how long pull requests spend in each stage of review. A new pull request review times array on each repos-1-day row reports a median and a 90th percentile for the time from ready for review to first review, first review to final review, and final review to merge. What’s new whats-new Each entry in pull request review times includes: - authored by and reviewed by : Who opened and who reviewed the pull requests in this entry. Both are human in this release. - total merged : The number of qualifying pull requests merged in the repository that day. - median minutes ready to first review and p90 minutes ready to first review : Time from the pull request becoming ready for review to its first review. - median minutes first to final review and p90 minutes first to final review : Time between the first and final review. - median minutes final review to merge and p90 minutes final review to merge : Time from the final review to merge. Durations are in minutes and attributed to the day the pull request merged. The existing pull requests fields are unchanged. Why this matters why-this-matters Teams can already see when pull requests take a long time to merge, but not where the time goes. Splitting the wait into three stages shows whether a pull request is waiting for someone to look at it, waiting on back-and-forth between reviewers, or sitting approved and unmerged. Each of those points to a different fix, and the 90th percentile beside the median shows when a handful of slow pull requests is driving the delay. Important notes important-notes - Availability: Present in the enterprise and organization repos-1-day reports. - What is counted: Pull requests that a person opened and at least one other person reviewed. Only human reviews are timed. Reviews from Copilot code review, other bots, and the author are ignored, so a pull request reviewed by both a person and Copilot code review is still included. As a result, pull request review times .total merged is usually lower than pull requests.total merged , which also counts pull requests merged without any reviews. - No backfill: Data builds forward from the release date, so early days will be thin. Pull requests that became ready for review before September 21, 2026 are left out of this section but still count toward pull requests.total merged . - A quiet day is an empty array, not a zero: The array is on days a repository merged no qualifying pull requests. The first-to-final review stage is 0 when pull requests receive a single review. - Access: Enterprise owners and billing managers, organization owners, and anyone with a custom organization or enterprise role that grants the View Copilot Metrics permission can access these reports. The Copilot usage metrics policy must be enabled. Visit the Copilot usage metrics API documentation https://docs.github.com/rest/copilot/copilot-usage-metrics to get started.