Code Review Metrics: The 5 Numbers Worth Tracking

The Five Review Metrics

1. Time to first review

The void between "PR opened" and "anyone cares". It is the cheapest metric to collect and the largest single component of PR cycle time in most teams. A PR that waits a day for a first look inflates your lead time for changes by 24 hours with zero engineering work done. The fix is a norm or rotation — a response within one working hour, not a completed review.

2. Review depth

The rubber-stamping detector. A stream of one-word approvals on PRs with real complexity means reviews have become ceremony. Review depth can be read from comment density per line reviewed, or simply by checking whether significant PRs receive substantive comments before approval. A rubber stamp is worse than no review: it grants false confidence.

3. Iterations per PR

How many times the PR bounces back to the author before approval. Three or more bounce-backs is rarely a sign of slow reviewers — it is a sign of unclear requirements. The PR that needed three rounds should have been a spec conversation, a design note, or two smaller PRs. This metric shifts review pain from a people problem ("we review too strictly") to a process problem ("we open PRs too big, too vague").

4. Approval rate distribution

A reviewer approving 100% of their PRs is a signboard, not a reviewer. A reviewer rejecting everything is a bottleneck. The distribution matters more than any individual number: healthy teams show variance — most PRs approved with real feedback, some rejected. If one person's approval rate is a flat line, the review process they participate in does not actually gate anything.

5. Review load per person

Who carries the queue. When two people absorb 80% of review load, they set the pace for the entire team — and both the team's cycle time and the reviewers' context-switching cost pay for it. Review load is a distribution problem disguised as a speed problem. Rebalancing it is usually an assignment-rotation change, not a "review faster" pep talk.

A review metric is useful only if changing it requires changing the system — norms, rotations, PR size — not changing a person.

How the Five Fit Together

Read them as a chain: time to first review exposes queue neglect, review depth tells you whether the gate is real, iterations per PR tell you whether requirements were clear, approval rate distribution tells you whether the gate is honest, and review load per person tells you who is burning out carrying it. Fixing downstream numbers shadows upstream ones: a first-review norm alone typically pulls the other four back into healthy ranges.

Collecting Them Without Overhead

All five metrics derive from standard GitHub events — reviews, comments, approvals, merges. Collected passively, they produce zero developer overhead and no reason to game them: the reviewer is not compared to the reviewer next door, the team just sees where its blocking stage is stuck.

DevLyTicks surfaces time to first review, review turnaround, iterations and review load automatically from your repositories — see where your review queue is stuck at devlyticks.com.

Conclusion

The review stage is the slowest blocking stage in most delivery pipelines, and it runs on vibes because nobody measures it. Instrument it with these five numbers — time to first review, review depth, iterations per PR, approval rate distribution and review load — and expect organizational fixes to fall out: response norms, review conventions, PR size ceilings, and load balancing.