top of page

Measure Review Health — Code Reviews That Help, Part 10

Shawn West
Jul 8
3 min read

Updated: 2 days ago

Code Reviews That Help · Part 10

Corrected, 4 October 2026. Updated the DORA metric name: what this post called MTTR is now failed deployment recovery time.

When code review feels slow or shallow, "we should review better" goes nowhere — you need to know where it's breaking. A few honest metrics (how long PRs wait, how fast the first response comes, how many get stuck) turn a vague complaint into a fixable one. This walks through measuring review health without creating numbers the team games instead of improving.


Reviews can become a bottleneck or a strength. Numbers tell you which.


Step 1: Pick Useful Metrics (10 min)


Good signals:


  • Cycle time — open to merge

  • First-response time — open to first review comment

  • Review depth — comments per PR; weighted by severity

  • Stuck PR count — open > N days

  • Rework count — pushes after first approval


Bad signals:


  • Comments per PR alone — encourages bikeshed

  • Approval count — encourages rubber stamps

  • PR size — encourages tiny non-features


Pick metrics tied to outcomes.


Step 2: Cycle Time (10 min)


Target:


  • Small PRs (< 100 lines): < 24h

  • Medium PRs (100-300): < 48h

  • Large PRs (300+): < 1 week


If your median cycle time is 5 days for small PRs: review is bottlenecked.


Step 3: First-Response Time (10 min)


How long until any human responds?


Target: < 4 hours during business hours.


Slow first response = author stalls and context-switches. Productivity tank.


Solutions: better notifications, oncall reviewer rotation, async-friendly culture.


Step 4: Review Depth (10 min)


Approvals on huge PRs with no comments = red flag.


Tracked through:


  • Comments per 100 lines of code

  • Time spent in review (some tools track)

  • Substantive comments vs. nits


Manual review of recent PRs every quarter: are reviews actually thorough?


Step 5: Stuck PRs (10 min)


PRs open > 7 days
PRs with unresolved comments > 5 days
PRs awaiting review > 3 days

Track and act:


  • Surface in team standup

  • Auto-tag stuck PRs

  • Rotate reviewers if original isn't responding


Stuck PRs accumulate. They cost author motivation.


Step 6: Tools (10 min)


  • GitPrime / LinearB / Pluralsight Flow — full analytics

  • Sleuth / Swarmia / Code Climate Velocity — DORA + review metrics

  • Custom dashboards — query GitHub API


Free option: GitHub's "Insights" tab has basic data.


For larger orgs: paid tools pay for themselves in finding bottlenecks.


Step 7: Don't Game Metrics (10 min)


Bad pattern:


  • "Cycle time is high" → reviewers rubber-stamp to speed up

  • "Comment count is low" → reviewers add nits to inflate


Measure outcomes, not activity. Quality + speed; not one at the cost of the other.


Step 8: Survey the Team (10 min)


Numbers don't capture everything. Ask:


  • Do you feel reviewed PRs improve in quality?

  • Are reviews tolerable in time and tone?

  • Do you trust the review process?


Anonymous survey. Quarterly.


Numbers + sentiment = real picture.


Step 9: Iterate on Process (10 min)


Quarterly retro:


  • What's slowing reviews?

  • Where are juniors stuck?

  • What conventions need updating?


Test changes:


  • Pair reviewing for big PRs

  • Async stand-up note about review queue

  • Mandatory oncall reviewer role


Measure impact. Keep what works.


Step 10: Tie to DORA Metrics (5 min)


DevOps Research and Assessment metrics:


  • Lead time — commit to prod (includes review)

  • Deploy frequency — how often you ship

  • Change failure rate — % of deploys causing problems

  • Failed deployment recovery time — how long it takes to restore service after a change fails in production. Older material calls it MTTR; DORA renamed it in 2023.


Slow review = slow lead time. Track DORA; review health is part of it.


What You Just Did


Review metrics: cycle time, first response, depth, stuck PRs, tools, anti-gaming, surveys, iteration, DORA. Reviews as a measurable practice.


Common Failure Modes


Track metrics; never act. Numbers in a vacuum.


Game the metric. Cycle time drops; quality suffers.


No surveying. Quantitative-only; miss culture issues.


One-time measurement. Drift between checks.


Review metrics in isolation. Disconnect from outcomes (DORA, quality).



Continue the Code Reviews That Help path



Part of the Code Reviews That Help learning path.

bottom of page