Code review metrics worth tracking, and the traps behind each one

Code review metrics have a bad reputation for a good reason: most teams that adopt them either track vanity numbers that measure typing, or wire real numbers into dashboards that people immediately learn to game. Both failure modes are avoidable. There is a short list of review metrics that reflect things worth caring about, and one rule for using them: they are conversation starters, not scorecards. Here is the list, and the trap attached to each.

Time to first response

The single highest-value number, because waiting is the dominant cost of review. Google’s engineering practices set the reference point: one business day is the maximum to respond to a review request, with the guidance treating review speed as a property that shapes the whole team’s velocity. Measure the distribution, not the average: a two-hour median with a three-day tail is a routing problem (lost notifications, absent reviewers), while a uniformly slow median is a capacity problem. The two look identical in an average and require opposite fixes. If you formalize expectations here, do it as a responsiveness SLA, not a completion deadline.

The trap: target the number individually and reviewers discover the placeholder comment. “Looking!” stops the clock and helps nobody.

Review cycle count

How many author-reviewer round trips a PR takes before merge. One or two cycles is a healthy conversation; five is a symptom. High cycle counts almost always decompose into one of three causes: reviews arriving as a dribble of partial comments instead of one complete pass, unclear PR descriptions that force discovery through comment threads, or genuine design disagreement that should have happened before the code was written. The metric will not tell you which, and that is fine. Its job is to flag the PRs worth asking about. A useful refinement is to segment by change type: refactors and migrations legitimately take more rounds than feature work, so a single blended average hides more than it shows.

The trap: push the number down as a goal and reviewers start swallowing legitimate second-round concerns to avoid “causing” another cycle.

PR size distribution

Size is the upstream variable that drives everything else. SmartBear’s review research found defect detection falls off past roughly 400 lines of code, with inspection rates above about 500 lines per hour degrading review effectiveness. So a team whose PR size distribution is drifting upward is watching its review quality decay in advance. Plot the distribution monthly; the interesting number is the share of PRs over the threshold your team can actually review well, and what a right-sized PR is depends on the kind of change. A creeping tail of giant PRs predicts every other metric on this page getting worse a quarter later.

Rubber-stamp rate

The share of approvals with zero comments on non-trivial diffs. Some silent approvals are legitimate (a rename, a dependency bump, a change discussed in person), which is why the qualifier matters: filter to diffs above a size floor and outside mechanical categories, then look at what is left. A rising rubber-stamp rate is the quantitative shadow of LGTM culture: reviews still happen on paper while reading has quietly stopped. This one is the best early-warning metric of the four, because it moves before defect rates do.

The trap is the mirror image of the others: make “comments per review” a virtue and you get nitpick theatre, reviewers seeding trivial style comments to prove they read the diff. The point is not more comments; it is honest ones.

Code review metrics meet Goodhart’s law

Every metric above stops working when it becomes a target, which is Goodhart’s law doing exactly what it always does. The pattern repeats: turnaround targets produce placeholder responses, cycle targets suppress real feedback, comment targets produce noise. This is not an argument against measurement; it is an argument about placement. Keep code review metrics at the team level, review them monthly as distributions and trends, and treat every surprising movement as a question: what changed, which PRs drove it, what would we like to try.

It also helps to name the metrics you refuse to track. Comments per reviewer rewards noise. Lines reviewed per day rewards skimming. Defects caught per reviewer punishes people for reviewing clean code and starts arguments about what counts as a defect. Approval rate per person turns reviewers into either rubber stamps or gatekeepers depending on which direction the dashboard frowns. Each of these measures activity, and activity is the one thing reviewers can manufacture on demand.

Metrics are conversation starters, not scorecards

The operating model that keeps all four numbers useful: pull them monthly, put them in front of the team, and ask what they make people curious about. A metric that prompts “why did our first-response tail double in March” is doing its job. A metric that decides someone’s rating has already been gamed, whether or not anyone admits it. Start with time to first response and rubber-stamp rate if you adopt only two, since together they answer the questions that matter most: do reviews start, and are they real. The numbers are instruments for noticing; the conversation is where the improvement actually happens.