Skip to content
Back to Quality Assurance

Review Metrics

Track review cycle time, comment quality, and defect escape rate to improve the review process itself.

Why

Code review is a process, and like any process it can be measured and improved — but most teams do not measure it, so they do not know if their reviews are getting faster or slower, if the feedback is useful, or if bugs are escaping review to production. The key metrics are: review cycle time (how long from PR open to merge — if it is 3 days, the team is blocked), defect escape rate (how many bugs reach production despite passing review — if it is high, the review is not catching bugs), and comment quality (are the comments actionable, or just "looks good" — if the comments are vague, the review is not teaching). Measuring these is not about judging reviewers; it is about finding bottlenecks (is review the bottleneck, or is the bottleneck upstream?) and improving the process (do we need smaller PRs? more reviewers? better tooling?). Without metrics, review improvement is guesswork; with metrics, it is targeted.

When

Track continuously, review monthly, and act on the trends — a metric that is tracked but not acted on is wasted.

How

1. Track review cycle time
   - Time from PR open to merge (the total cycle time)
   - Time from PR open to first review (the response time)
   - Time from first review to merge (the iteration time)
   - Target: < 24 hours for small PRs, < 48 hours for large

2. Track defect escape rate
   - Count bugs that reach production (from user reports or monitoring)
   - Of those, how many were in code that passed review?
   - Defect escape rate = reviewed bugs / total bugs
   - Target: < 10% (90% of bugs caught before production)

3. Track comment quality (sample, do not automate)
   - Sample 10 review comments per month
   - Are they specific (quote the line, name the issue)?
   - Are they actionable (provide the fix or direction)?
   - Are they kind (about the code, not the person)?
   - Target: > 80% of sampled comments meet all three

4. Track review participation
   - Is one reviewer doing 80% of reviews? (bus factor risk)
   - Are some developers never reviewing? (knowledge silo)
   - Target: reviews distributed across the team

5. Act on the trends
   - Cycle time increasing? → PRs are too big, or reviewers are slow
   - Defect escape high? → reviews are superficial, or the checklist is incomplete
   - Comments low quality? → train the team on review etiquette
   - Participation skewed? → rotate reviewers, or pair junior with senior

Example

// Track review cycle time with a GitHub Action
// .github/workflows/review-metrics.yml
name: Review Metrics
on:
  pull_request:
    types: [closed]
jobs:
  track:
    if: github.event.pull_request.merged
    runs-on: ubuntu-latest
    steps:
      - run: |
          echo '{ "pr": ${{ github.event.pull_request.number }},
            "cycle_hours": ${{ (github.event.pull_request.merged_at - github.event.pull_request.created_at) / 3600 }},
            "author": "${{ github.event.pull_request.user.login }}",
            "lines": ${{ github.event.pull_request.additions + github.event.pull_request.deletions }}
          }' >> metrics.json
          curl -X POST https://metrics.example.com/api/review -d @metrics.json

// Dashboard: review cycle time over time
// Week 1: avg 18 hours, median 8 hours, p90 72 hours
// Week 2: avg 24 hours, median 12 hours, p90 96 hours ← trend up, investigate
// Week 3: avg 16 hours, median 6 hours, p90 48 hours ← after intervention

// Defect escape rate (from production incidents)
// Q1: 30 bugs in production, 24 passed review → 80% escape rate (bad!)
// Action: add a review checklist, train the team
// Q2: 20 bugs in production, 8 passed review → 40% escape rate (improving)
// Q3: 15 bugs in production, 3 passed review → 20% escape rate (target: <10%)

// Comment quality sample (monthly)
// Sampled 10 comments from January:
// - 7 specific, actionable, kind (good)
// - 2 vague ("this is bad") (needs training)
// - 1 unkind ("you always do this") (needs coaching)
// Score: 70% — below the 80% target, schedule a review etiquette session

// Review participation (quarterly)
// Q1: alice 40%, bob 30%, carol 20%, dave 5%, eve 5%
// Action: dave and eve are not reviewing — rotate the review rotation,
// pair them with alice and bob to build the skill
// Q2: alice 25%, bob 25%, carol 20%, dave 15%, eve 15% ← more distributed

Common Problems

  • ⚠Tracking cycle time but not acting on it — the dashboard shows cycle time rising from 1 day to 3 days, but nobody investigates, and the team's velocity drops without intervention.
  • ⚠Using the metrics to judge individual reviewers — the reviewer with the highest defect escape rate is punished, they stop reviewing, and the team loses a reviewer and the metric becomes a weapon.
  • ⚠Tracking only cycle time and missing quality — the cycle time is 4 hours (great!), but the reviews are rubber stamps, the defect escape rate is 60%, and the speed is hiding a quality problem.
  • ⚠Collecting metrics manually in a spreadsheet — the data is stale, the trends are invisible, and the team spends more time collecting than acting.

Best Practices

  • ✓Track review cycle time, defect escape rate, and comment quality, and act on the trends — a metric without action is wasted, and the goal is improvement, not measurement.
  • ✓Use the metrics to improve the process, not to judge individuals — a high defect escape rate means the process is broken (missing checklist, PRs too big), not that the reviewer is bad.
  • ✓Track both speed (cycle time) and quality (defect escape, comment quality) — fast reviews that are rubber stamps are not good reviews, and the metrics must balance both.
  • ✓Automate the data collection (GitHub Actions, a metrics dashboard) so the team spends time acting on trends, not collecting data — stale data in a spreadsheet is ignored.