InteliG
Sign Up
Glossary

Definition

Code Review Coverage

Code Review Coverage is the share of merged code changes that passed through a human review before reaching the main branch. It tells you how consistently changes are inspected, not whether the review caught anything that mattered.

What it measures

Code Review Coverage is the percentage of merged changes that were reviewed by at least one person other than the author before merge. It is usually computed over pull requests or merge commits in a window: reviewed merges divided by total merges. A coverage of 90 percent means nine of ten merges had a recorded review event.

It is a process-conformance measure. It answers one question: did a second set of eyes formally sign off before this code became part of the trunk. It says nothing about depth, only presence.

How to measure it

From git and your forge, take every change that landed on the default branch in a period and check each for a review event. On GitHub or GitLab that means an approval or a submitted review on the pull request tied to the merge commit; direct pushes to main with no PR count as unreviewed. Coverage is reviewed merges over total merges.

Decide your unit and your rules up front and apply them the same way every time. Self-approvals and rubber-stamp approvals with zero comments should be flagged or excluded if you want the number to mean anything. Bot commits, automated dependency bumps, and merge commits usually get filtered so they do not inflate the denominator.

What it does not tell you

Code Review Coverage tells you a review happened. It cannot tell you the review was real. An approval clicked in eight seconds with no comments counts exactly the same as a careful read that caught a security flaw, so a team can hold 100 percent coverage while reviews degrade into a formality. It also says nothing about what the reviewed code was for: a fully reviewed change can still ship the wrong feature, advance no priority, or pile onto a part of the system no one should be investing in.

Like every activity metric, it measures motion, not direction. It counts whether the process ran, not whether the work was correct, valuable, or aligned with what the business is trying to do. High coverage on work that does not serve a current initiative is disciplined effort pointed nowhere.

Execution Intelligence reads the other half: what is actually being built and why. The useful question is not how many merges were reviewed but whether the reviewed changes advance the initiatives that matter, who is doing that work, and what it costs. Coverage is a floor under quality, not a read on value.

How InteliG uses it

InteliG computes Code Review Coverage straight from your real git and deployment history, with no manual instrumentation and no agents to install. It reads commits, pull requests, and review events as they already exist in your forge.

Cognis then connects each reviewed change to the initiative it belongs to, the people who wrote and reviewed it, and the cost of that work. So coverage stops being a standalone percentage and becomes part of one chain: this work, on this priority, by these contributors, reviewed to this standard, at this cost.

Related terms