Code Review & Review Queue

Overview

Code review is where most engineering teams lose the most time. The typical PR spends more time waiting for review than it does being coded. Koalr's Code Review and Review Queue pages give you detailed visibility into every stage of the review process — pickup time, depth, reviewer workload, and queue health.

Key metrics

Metric	Definition	Healthy benchmark
Time to first review	PR opened → first review comment	< 4 hours
Time to approval	PR opened → final approval	< 8 hours
Review depth	Comments per 100 lines changed	> 3
Reviewer coverage	% of PRs reviewed by CODEOWNERS	> 85%
Rubber-stamp rate	% of approvals in < 5 minutes	< 10%
Queue age P75	75th percentile age of open PRs awaiting review	< 24 hours

Dashboard sections

Organization review summary

• Median time to first review (current vs. prior period)
• Median time to approval
• Open PR queue size
• % of PRs stale > 48 hours

Review pickup time trend

Line chart of median pickup time per week. Pickup time is the most actionable metric — you can improve it immediately through process (review windows) without code changes.

Reviewer workload heatmap

A heatmap showing review volume per reviewer per week. Identifies:

• Overloaded reviewers — too many PRs, leading to slow pickup and shallow reviews
• Underutilized reviewers — team members who could absorb more review load
• Review concentration — when one or two senior engineers review everything, they become bottlenecks

Queue health histogram

Bar chart of all open PRs by age bucket:

• 0–4 hours
• 4–12 hours
• 12–24 hours
• 1–3 days
• 3–7 days
• 7+ days (stale)

A healthy queue is bottom-heavy (most PRs are young). A top-heavy histogram indicates reviews are backing up.

Time-to-first-comment vs. time-to-approval trend

Dual-line chart showing both metrics at P50 and P75 over 12 weeks. When both lines rise together, the review process itself is slow. When only time-to-approval rises, the issue is in the back-and-forth discussion.

SLA compliance

Configure review SLA targets (e.g., "first review within 4 hours") and track compliance rate. Displayed as a percentage with 30-day trend.

PR review table

Filterable table of all PRs in the period with:

• PR title, author, repo, size
• Time to first review
• Time to approval
• Reviewers assigned
• Review depth (comments per 100 lines)
• Link to GitHub PR

Review quality signals

• Rubber-stamp rate — approvals completed in < 5 minutes (likely not a real review)
• Review depth by author — which engineers write the most substantive reviews
• Comment-to-approval ratio — how many review rounds the typical PR requires

Reviewer pair analysis

The Reviewer Pairs section shows a matrix of who reviews whose code. Insights:

• Siloed pairs — two engineers only ever review each other's code (knowledge silo risk)
• Missing pairs — engineers who never review code outside their own area
• Balanced distribution — ideal state where reviews are spread across the team

Configuring review SLAs

Navigate to Settings → Work Configuration to:

• Set pickup SLA (default: 4 hours)
• Set approval SLA (default: 24 hours)
• Enable Slack alerts when PRs exceed SLA
• Configure which days/hours count toward SLA (business hours mode)
• Set minimum reviewer count per PR

Reducing review bottlenecks

1. Designate review windows — two daily 30-minute review blocks reduce interruptions while keeping pickup time low
2. Reduce PR size — the fastest way to reduce review time (PR Size Distribution)
3. Enforce WIP limits — reviewers can't review everything when authors have too many open PRs (WIP Limits)
4. CODEOWNERS clarity — clear ownership routes PRs to the right reviewers faster (GitHub integration)
5. Staggered review assignment — avoid assigning the same 2 senior engineers to every PR

Relationship to other metrics

• Cycle Time — pickup and review time are the largest components of total cycle time (Cycle Time)
• Deploy Risk — CODEOWNERS compliance is a core deploy risk signal (Deploy Risk)
• PR Size Distribution — large PRs have longer review times and lower review depth (PR Size Distribution)
• WIP Limits — WIP accumulation creates reviewer overload (WIP Limits)
• Context Switching — fragmented reviewers who switch between too many repos review more slowly (Context Switching)