Code review quality score: five numbers that tell you if review is real
Review Quality Index is a five-row scorecard over every pull or merge request that merged in the window: what share got a genuine peer approval, how long they sat open, what share merged suspiciously fast, what share got a written comment, and what share linked a ticket. Individually each row is easy to game. Read together, they're hard to fake.
| Metric | Value | Good direction |
|---|---|---|
| Peer-approval coverage | 88% | higher |
| Median PR-open time | 9.4h | lower |
| Instant-merge rate (<10 min) | 4% | lower |
| Comment rate | 61% | higher |
| Ticket-linked rate | 76% | higher |
A healthy-looking review-quality scorecard.
What it measures, and where the data comes from
Every merged pull or merge request in the window — from GitHub, Azure DevOps, and GitLab — feeds five rows:
- Peer-approval coverage — % with at least one approval from a reviewer who is not the author. A self-approval doesn't count — but an approval from a bot account does, as long as its login differs from the author's.
- Median PR-open time — the middle value of hours from open to merge across the window. Not a rate — a duration.
- Instant-merge rate — % merged in under 10 minutes of being opened. This is a red flag row: a PR reviewed, discussed, and approved in nine minutes is possible but rare. Most of the time it means nobody looked.
- Comment rate — % that received at least one written comment from someone other than the author (not just a silent approval click).
- Ticket-linked rate — % that reference at least one tracking ticket.
How to read it
Never read peer-approval coverage on its own. Read it against instant-merge rate and comment rate first. A high coverage number sitting next to a high instant-merge rate and a low comment rate is the signature of rubber-stamping: people are clicking approve, not reviewing.
Median PR-open time is context, not a target to minimize. A very low median paired with a high instant-merge rate confirms the rubber-stamp read. A very high median is a different problem entirely — that's a review-pickup issue, and belongs with a different widget, not this one.
What it tells you over time
Watch comment rate and instant-merge rate more closely than coverage — coverage tends to be sticky (teams rarely stop requiring an approval), while comment rate and instant-merge rate are where a slipping review culture shows up first. A comment rate drifting down over a quarter while coverage holds steady is usually the earliest sign that "review" has quietly become a formality.
Example situations
1. Coverage looks fine, but nobody's actually reading anything
| Metric | Value | Good direction |
|---|---|---|
| Peer-approval coverage | 91% | higher |
| Median PR-open time | 1.8h | lower |
| Instant-merge rate (<10 min) | 34% | lower |
| Comment rate | 19% | higher |
| Ticket-linked rate | 70% | higher |
Coverage high, comment rate low, instant-merge rate high.
What you're seeing: 91% peer-approval coverage looks like a healthy review culture at a glance. But a third of merges happened inside 10 minutes, and fewer than one in five PRs got an actual comment. This board technically requires review — it doesn't practice it.
How to react: resist the instinct to add a second required-approver rule. That makes rubber-stamping twice as expensive to fake and doesn't touch the actual behavior — you'll likely just get two fast approvals instead of one.
2. Review theatre: every signal pointing the same way
| Metric | Value | Good direction |
|---|---|---|
| Peer-approval coverage | 76% | higher |
| Median PR-open time | 0.9h | lower |
| Instant-merge rate (<10 min) | 41% | lower |
| Comment rate | 14% | higher |
| Ticket-linked rate | 33% | higher |
Low ticket-link rate, low comment rate, high instant-merge rate — all at once.
What you're seeing: this isn't one weak row — it's three of five rows pointing the same direction at once. Low ticket-linking, near-silent reviews, and nearly half of merges going through in under 10 minutes. There's no traceability, no scrutiny, and barely a pause between "opened" and "merged." This is review theatre: the ritual exists, the substance doesn't.
How to react: a pattern this broad usually isn't a review-process problem in isolation — it's a symptom of delivery pressure that made every quality gate feel optional at once. Fixing review alone without addressing why people felt they had to skip it will just move the shortcut somewhere else.
Frequently asked
- How do you measure code review quality?
- The Review Quality Index is a five-row scorecard over merged pull and merge requests: the share with a genuine peer approval, how long they sat open, the share that merged suspiciously fast, the share with a written comment, and the share that linked a ticket.
- How can I tell real review from rubber-stamping?
- Read the five rows together. Each is easy to game on its own — approvals are cheap, comments can be trivial — but high approval coverage combined with near-zero open time and no written comments is a recognisable rubber-stamp signature.
- What counts as a genuine peer approval?
- An approval from someone other than the pull request author. Self-approvals and author comments are excluded, which is what makes the coverage figure meaningful.
Related widgets
- Review Quality Trend — the same coverage and comment signals, plotted week over week instead of one snapshot.
- Reviewer Participation — breaks the same review activity down by who's actually doing it.
- Ticket Coverage Rate — a closer look at the traceability row on its own, with an 8-week trend.
- Back to the widget reference.
Last updated