How long should code review take? What the evidence actually says

How long should code review take? The question hides two different questions, and teams that answer only one of them stay slow. The first: how quickly should a review start? The second: how long should the reading itself take once it does? The evidence gives usable numbers for both, and almost every chronically slow review process is failing the first question while agonizing over the second.

So how long should code review take?

Start with the queue. Google’s engineering guidance on review speed sets the outer bound plainly: one business day, maximum, for a first response to a review request, and the same document is explicit that slow review harms both team velocity and morale. Note what the bound governs: the response, not the completion. A clarifying question inside an hour beats a finished review three days later.

Then the read itself. SmartBear’s peer review analysis found reviewers should cover no more than about 400 lines per session, move no faster than roughly 500 lines per hour, and keep sessions to about 60 minutes, because defect detection drops measurably beyond each of those limits. Put the numbers together and the natural unit of review falls out: a change of a few hundred lines, read carefully in under an hour, started within a day of being requested.

The floor matters too. Google’s Critique study found changes there are typically small and get reviewed quickly, usually by one reviewer. Minutes-long reviews of small diffs are not corner-cutting; they are the system working. Duration should scale with size and risk, and at the small end the honest duration is genuinely short.

Elapsed time is not attention time

A pull request that was "in review for three days" may have received eleven minutes of human attention. Those three days decompose into: time waiting for anyone to look, time being read, time waiting for the author to respond, time waiting for the re-review. Only one slice is reading. The rest is queueing, and queueing responds to completely different fixes than reading does.

This distinction is the single most useful diagnostic for a slow process. If attention time is high, changes are too big or too murky, and the fix lives with authors. If elapsed time is high while attention time is low, the queue is unmanaged, and the fix lives with the team: expectations, notifications, and explicit ownership of the waiting pile. Measuring only total turnaround blurs the two failure modes into one useless number.

What stretches review time

• Size. Reading pace is roughly linear until it collapses; past the 400-line neighborhood, comprehension degrades and reviewers start skimming. A diff that respects sane size limits fits in one session. A diff that ignores them costs a multiple, not an increment.
• Rounds. Every round of comments and fixes re-enters the queue and pays the full waiting tax again. Three rounds at a day of latency each is three days gone, independent of any reading. Cheap re-review, of only what changed since last time, is how mature teams keep round two from costing what round one did.
• Queue neglect. The largest slice of most turnaround time is nobody being on the hook for the waiting pile. That is what a review SLA exists to fix: not faster reading, but a shared expectation about when reading begins.

These three multiply rather than add. An oversized diff gets picked up later because reviewers defer the changes they dread, then produces more comment rounds because comprehension suffered, and each extra round pays the full queue tax again. That is why a single 2,000-line pull request routinely takes longer to merge than the same work split into five sequential changes, even though the split involves more total review events. The waiting compounds; the reading never had to.

Benchmarks are a health check, not a stopwatch

One warning before these numbers go in a dashboard. The moment one-business-day and 60-minute figures become individual performance targets, reviewers will hit them the only way that is always available: by reading less. A stopwatch culture produces fast, hollow approvals, which cost more than the latency they replaced. The benchmarks earn their keep at the distribution level, tracked alongside the rest of your review metrics: medians and tails across the team, trending over quarters, pointing at process problems rather than people.

So: respond within a business day, read in sub-hour sittings at a pace that lets you actually think, and treat any change too large for that as the thing to fix. Teams that hold those three lines stop asking how long review should take, because review stops being where the time goes.