Code review bottleneck analysis

Code review bottleneck analysis is the practice of measuring where pull requests spend their waiting time in the review pipeline so the slowest stage can be identified and fixed. The review process is a series of stages: a pull request waits for a first reviewer, sits in active review, waits for the author to address comments, then waits for a re-review. Bottleneck analysis measures the wait at each stage and finds the one that dominates the total.

The value comes from a simple truth about pipelines. The slowest stage sets the pace of the whole system, and time invested anywhere else is largely wasted. If pull requests wait twelve hours for a first reviewer but only twenty minutes in active review, the bottleneck is reviewer availability. Making review faster would change almost nothing. Bottleneck analysis stops a team from optimising the wrong stage.

There is no single number for bottleneck analysis. Instead you measure the median wait time and the queue depth at each stage, then compare them to find the stage that holds the most work for the longest. The stage that tops both lists is the bottleneck.

The practical method is to break the journey of a pull request into stages and timestamp each transition. From those timestamps you can compute how long the typical pull request waits at each step and how many pull requests sit in each step at once. Watching how the queue depth changes over a week shows whether the bottleneck is steady or moves around as the team batches work.

1. 1

   Define the pipeline stages

   Split review into discrete stages such as awaiting first review, in review, awaiting rework, and awaiting re-review.

2. 2

   Timestamp every transition

   Record when each pull request enters and leaves every stage.

3. 3

   Compute wait time per stage

   Take the median time pull requests spend in each stage across the period.

4. 4

   Measure queue depth per stage

   Count how many pull requests sit in each stage at a typical moment, then rank stages by wait and depth together.

Bottleneck analysis is itself a decomposition, which makes it a natural fit for a metric tree. The total review wait is the sum of the waits at each stage, and a tree lays those stages out so the dominant one stands out at a glance. Each stage then breaks down further into the causes you can act on.

When the tree shows that the first-review stage owns most of the wait, you look at its children: reviewer availability, queue depth, and time zone overlap. The bottleneck is rarely a single person being slow. It is usually a structural cause such as too few reviewers assigned to too many pull requests. The tree surfaces that cause instead of letting the team guess.

There is no single benchmark for a bottleneck because the metric points at a location rather than a value. What you can benchmark is how concentrated the wait is in one stage and how the team typically performs at each. The table below shows where the bottleneck usually lands and what a healthy versus unhealthy share of total wait looks like for each stage. A healthy pipeline spreads wait fairly evenly. An unhealthy one parks most of it in one place.

Improving bottleneck analysis means two things: getting better at finding the bottleneck, and clearing the one you find. Both depend on clean stage timestamps and a team agreement about who owns each stage. Once the dominant stage is clear, the fix is usually targeted at that stage alone rather than a general push to be faster.

1. 1

   Optimising a non-bottleneck stage

   Speeding up active review when the wait sits in first review changes nothing. Find the dominant stage first.

2. 2

   Blaming individuals

   A bottleneck is usually structural, such as too few reviewers, not one slow person. Look at the stage, not the name.

3. 3

   Measuring wait without queue depth

   A long wait with no queue is a slow step, not a bottleneck. You need both signals to locate the real pile-up.

4. 4

   Assuming the bottleneck stays put

   Once you relieve the dominant stage, the bottleneck moves. Re-measure rather than keep fixing the old one.