Find Code Review Bottlenecks Before Changing the Whole Organization

On September 25, 2026, GitHub added pull request review stages to its repository-level Copilot usage reports. That gives engineering leaders another reason to ask a more specific question when delivery slows: which repository needs attention?

An organization-wide code review metric can tell you that something deserves investigation. It cannot tell you whether every team needs a new process. Before changing reviewer assignments, introducing a response target, or buying more automation, locate the affected work.

Product illustration from an AWS analysis dated August 23, 2026. These screenshot values are historical, not the October figures below. Small repository samples require particular care.

What GitHub added

The new reports distinguish ready-for-review to first review, first to final review, and final review to merge. Each stage includes a median and a 90th percentile, or P90. GitHub describes the aim as showing “where the time goes.”

The initial release covers qualifying merged pull requests opened by a human and reviewed by another human. Bot and author reviews are excluded from timing. This population is narrower than all merged PRs. GitHub also notes: “A quiet day is an empty array, not a zero.”

These definitions matter when comparing tools. GitQuick's first-review clock starts at PR opening, not GitHub's ready-for-review event. Its approval-to-merge metric is also not interchangeable with GitHub's final-review-to-merge interval. Matching labels loosely can produce a comparison that looks precise but measures different things.

The decision: one response target or a targeted intervention?

There is a reasonable case for a shared response expectation. Authors should know when feedback will arrive. Google's engineering review guidance says, “One business day is the maximum time it should take to respond to a code review request.” It also distinguishes a prompt response from completing the entire review.

But a shared expectation does not establish a shared cause. A service repository may wait for its only available domain reviewer. A documentation repository may receive many quick changes. An infrastructure repository may have deliberate release restrictions. Those are hypotheses to check with maintainers, not conclusions to infer from the repository name.

The management choice is whether to change policy everywhere or address a specific constraint. Start with a common expectation, then investigate exceptions at the level where someone can act. A broad policy is useful only if it helps the work that is actually waiting.

What the current AWS showcase tells us

The public AWS showcase provides a concrete starting point. Run 564 covers September 15 to October 15, 2026, with both boundaries at 03:00:42 UTC. The run completed on October 15 at 03:18:57 UTC. The figures below were retrieved from the live showcase API on October 15.

The median first review is relatively short, while its P90 is several days. That is a reason to examine the slow cases. It is not evidence that every AWS repository has a review problem, or that any particular team is understaffed.

These are separate eligible samples. Do not add the medians to reconstruct a typical PR, or subtract one stage from another. The public response used here contains organization aggregates, not repository rows. It therefore cannot establish whether the delay is concentrated in one repository. The historical screenshot illustrates the investigation surface; it does not fill that evidence gap with current data.

Find the repository before choosing the fix

Use this sequence on your own analysis:

1. Keep the comparison consistent. Start with one analysis window and a deliberate target-branch selection. Avoid combining release promotions with feature work without checking their different purpose.
2. Sort repositories by P90 first-review time. This identifies candidates whose slower reviewed PRs waited longer. Read the median alongside it rather than treating either number as sufficient.
3. Check the eligible sample. A repository's total PR count is not necessarily its first-review sample. A percentile based on very few reviewed PRs can move substantially after one more observation.
4. Inspect the actual work. Check review requests, ownership, draft status, change size, and author responses. Separate time waiting for a reviewer from time spent revising a change.
5. Choose one intervention with an owner. Try backup reviewer coverage if requests repeatedly wait for the same expertise. Clarify acceptance criteria if reviews repeatedly restart. Investigate checks and release policy if the delay comes after approval.

This is an investigation order, not a ranking of engineering teams. Repository purpose, contribution patterns, automation, and time zones can all affect what the numbers mean. Confirm the explanation with the people doing the work.

GitQuick's Repos Performance view supports repository filtering and sorting by first-review latency and review coverage; its scope selector lets you inspect a single repository. For recurring investigations across related repositories, saved groups support selected repositories and name prefixes, so the analysis can follow the area you own.

Measure the affected scope again

Write down the suspected cause, the change, and the repositories affected. On the next comparable run, inspect that same scope before looking at the organization headline. Keep the repository membership and branch selection stable, or explicitly record what changed.

A faster organization median alone is insufficient. The mix of repositories contributing PRs may have changed. Look for improvement in the affected scope, with enough eligible observations and no unexplained drop in review coverage. Review metadata still cannot prove that code quality improved.

For the underlying timing definitions, read Pull Request Review Latency. For evaluating the intervention, see Did Your Code Review Process Actually Improve?.

Explore the AWS showcase or all public showcases, with no GitHub installation required.

Find the repositories behind your review delays with GitQuick.

Disclaimer: This article uses public GitHub metadata and linked GitHub and Google primary sources. The live table is an AWS snapshot for the stated window, not a benchmark for private teams. Reviewer classification uses account-login heuristics and can misclassify accounts. Review activity and elapsed time do not measure review quality or reviewer effort. GitQuick is not affiliated with or endorsed by GitHub, Google, or AWS.