Review Coverage: How Much Code Ships Unread

TL;DR: Review coverage is the share of merged PRs that a second person actually read. Every dashboard tracks how fast reviews happen; almost none track whether they happen at all. So self-merges drift upward unnoticed, and every unreviewed change is code exactly one person understands. Measure it, set an honest target with explicit exceptions, and treat rising self-merge share as a system signal, not a wanted poster.

Your review dashboard says pickup time is four hours and review time is trending down. Lovely. Neither number includes the PRs that were never reviewed: a merged-without-review PR has no pickup time to measure, so it exits the dataset silently, flattering every average on the board. That blind spot has a name: review coverage. Here's what it is, why it's invisible by default, and how to watch it without turning it into a shame index.

What is review coverage?

Review coverage = merged PRs with ≥1 non-author review, divided by all merged PRs, over a window. The complement is the self-merge share: code that went from one keyboard to the main branch with zero second readers.

It's the existence check that comes before every other metric in this pillar. Pickup time, review depth, PR size - all of them describe reviews that occurred. Coverage asks the prior question: how much of the codebase is entering production having been read by exactly one human?

For calibration on what "normal" can look like: at Google, essentially every change to the main codebase is reviewed before it lands, across roughly 9 million reviewed changes, with a median of one approver. Full coverage there comes from a simple habit: one other person always reads it.

Why does nobody watch it?

Because the standard instruments don't show it. LinearB's widely-used benchmark table, drawn from 8.1 million+ PRs, tracks twenty metrics: pickup time, review time, PR size, merge frequency, deploy time. Review coverage is not one of them. The industry's shared scoreboard measures the speed of review, and speed metrics are structurally silent about the changes that skip the queue.

There's also a comfortable assumption doing quiet damage: "we have required reviews turned on, so coverage is 100%." Check the fine print of your own setup: admin bypasses, repos outside the rule, direct pushes to main, bot-authored merges, and the emergency exceptions that became habits. Coverage measured from what actually merged regularly disagrees with coverage assumed from branch protection settings. The gap between the two is your real number.

What an unreviewed change actually costs

Not "the code is bad." Plenty of self-merged code is fine - that's what makes the drift comfortable. The cost is in what review measurably provides and the self-merge silently skips:

1. The defect check - the obvious one, and per the research, the smaller one.
2. The evolvability check. 75% of what reviews catch is structure and clarity, not bugs. Unreviewed code accumulates unchallenged shortcuts at exactly the rate nobody is watching.
3. The second reader. Microsoft's study found review's measured outcomes lean heavily toward knowledge transfer and team awareness. A self-merge is the deliberate skipping of the one mechanism that spreads code knowledge as a side effect of normal work.

That third cost compounds into the expensive one. Code only one person has read is code only one person can safely change, a knowledge silo forming one merge at a time. And silos aren't a hypothetical tax: in the Stack Overflow 2024 survey, 45.2% of professional developers agree that knowledge silos prevent them from getting ideas across the organization. Low review coverage in a repo is an early leading indicator of the day that repo has a bus factor of one.

How do you track review coverage?

The query is simple; the discipline is in the segmentation:

• The number: share of merged PRs, per month, with at least one non-author reviewer interaction (approval or substantive comment) before merge. Count "approved by a bot" and "approved after merge" separately; neither one is coverage.
• Segment by repo and path, because the average lies. 92% org-wide coverage can hide the one deploy-scripts repo at 30%, and infra, CI, and migration code is precisely where an unread change hurts most.
• Watch concentration. Coverage failures cluster: one repo, one path, one workflow where self-merging became the norm. The cluster is the finding.
• Trend over snapshot. Coverage drifts during crunch: the emergency exception in March is the habit by June. A three-point drop over a quarter is worth a conversation; a one-week blip is not.

And the guardrail that keeps the metric honest: coverage is a system property, not a person score. A rising self-merge share is telling you something about the system. Review is too slow to wait for (see reducing review time), nobody else knows that area well enough to review it, or the rules quietly don't apply to some class of work. Every one of those is a fixable process problem. Publishing a self-mergers leaderboard fixes none of them; it just teaches people to game the approval.

An honest target

For substantive changes: ~100%, with a short, written exception list. One reader - remember Google's median of one approver - not a committee.

The exceptions, made explicit instead of ambient: automated dependency bumps and lockfiles (define the boundary), generated code, and the genuine emergency hotfix, merged now and reviewed after the fact, where the post-hoc review actually happens and is checked. An exception list you wrote down is policy; the same list, unwritten, is drift with better branding.

If review is so slow that waiting for it feels irresponsible, that's a queue problem with a known cost and a known fix, not a coverage problem. Fix the queue; don't route around the reading. And if your review dashboard looks healthy while this share climbs, read your review stats only count the PRs that got reviewed: latency metrics are conditioned on a review existing at all.

The whole point of this metric is one honest sentence you currently can't say: "X% of the code we shipped last quarter was read by a second person." Find out what X is. If it's lower than you assumed - and it usually is - you've found the cheapest review improvement available: a second reader for the code that currently has none.