The Hook (The "Byte-Sized" Intro)
A PR sits open for 3 days. The author context-switches to another task. When reviews finally arrive, the author has forgotten the details. Conflicts pile up. The merge becomes a chore. Review SLAs prevent this: first response within 4 hours, full review within 24 hours. Fast reviews keep the team in flow.
📖 What are Review SLAs?
Service Level Agreements for code reviews — agreed-upon time limits for responses, approvals, and re-reviews.
Conceptual Clarity
Recommended SLAs:
| Metric | Target | Why |
|---|---|---|
| First response | < 4 hours | Show the author their PR is seen |
| Full review | < 24 hours | Prevent stale PRs |
| Re-review (after changes) | < 4 hours | Don't block the author twice |
| Hotfix review | < 1 hour | Production is down |
PR size targets:
| Size | Lines Changed | Review Time |
|---|---|---|
| Small | < 50 lines | < 15 minutes |
| Medium | 50-200 lines | 15-30 minutes |
| Large | 200-500 lines | 30-60 minutes |
| Too large | 500+ lines | Split the PR |
Real-Life Analogy
Review SLAs are like restaurant service standards. If your food takes 2 hours, you leave. If your PR takes 3 days, you context-switch. Setting expectations keeps things moving — appetizer in 10 minutes, entree in 30, review in 24 hours.
Visual Architecture
Why It Matters
- Flow: Fast reviews keep developers in context.
- Quality: Stale PRs lead to rushed "just approve it" reviews.
- Morale: Waiting days for review is demoralizing.
- Velocity: Team throughput directly correlates with review speed.
Code
# ─── Measure review times ───
# GitHub: Insights → Pull Requests → Review time
# Or use tools like LinearB, Sleuth, or Swarmia
# ─── Slack/Teams notifications ───
# Set up PR notifications:
# - New PR → #team-reviews channel
# - Review requested → DM to reviewer
# - Stale PR (> 24h) → Reminder in channel
# ─── GitHub Actions: stale PR reminder ───
# .github/workflows/stale-pr.yml
# name: Stale PR Reminder
# on:
# schedule:
# - cron: '0 9 * * *' # Daily at 9am
# jobs:
# remind:
# runs-on: ubuntu-latest
# steps:
# - uses: actions/stale@v9
# with:
# days-before-pr-stale: 2
# stale-pr-message: "This PR hasn't been reviewed in 2 days."
# ─── Keep PRs small (the best SLA hack) ───
# Small PRs get reviewed faster!
# Target: < 200 lines changed per PRKey Takeaways
- Set clear SLAs: first response < 4h, full review < 24h.
- Small PRs are the best way to ensure fast reviews.
- Use notifications and reminders to prevent stale PRs.
- Track review metrics and adjust SLAs as the team grows.
Interview Prep
-
Q: What are code review SLAs and why are they important? A: Agreed-upon time limits for review responses (e.g., first response < 4h, full review < 24h). They prevent context-switching delays, keep PRs from going stale, and maintain team velocity.
-
Q: How do you handle a team that consistently misses review SLAs? A: Investigate root causes: PRs too large (set size limits), too many in-progress PRs (set WIP limits), insufficient reviewers (rotate reviewers), or unclear ownership (use CODEOWNERS).
-
Q: What is the most effective way to reduce review time? A: Keep PRs small (< 200 lines). Small PRs are reviewed faster, more thoroughly, and merged sooner. They also have fewer conflicts and are easier to revert.