Code review quality is easy to talk about and hard to measure. If you only track speed, you miss whether the review was useful. If you only track defects, you miss whether the process is sustainable. The right metrics sit in the middle.
Useful metrics
- Signal: how many comments led to real improvements?
- Latency: how long does review add before merge?
- Coverage: how much of the risky code actually got reviewed?
- Actionability: were comments specific enough to act on quickly?
- Noise: how much feedback was discarded as irrelevant?
What not to optimize blindly
A low review time can hide superficial review. A high comment count can hide noise. A useful metric is one that helps the team improve judgment, not one that simply makes activity look impressive.
How to use the metrics
Start by measuring a small number of reviews consistently, then look for patterns: where do reviewers miss risk, where do authors get stuck, and where does automation help or hurt? That gives you a more honest view of the process than raw throughput alone.