Most teams that adopt a code review SLA do it after the same painful week: a two-line fix sat unreviewed for four days, someone shipped a hotfix around the process, and a retro produced the sentence “we need review SLAs.” Then the SLA gets written as “all PRs reviewed within 24 hours,” nobody instruments it, and three months later it is a dead rule everyone politely ignores. The failure is not the idea. It is that the SLA promised the wrong thing.
The short answer: A code review SLA that survives contact with a real team promises responsiveness, not completion: a first response within hours and a full review within one business day. Pair it with scheduled review blocks so keeping the promise costs no focus, and an escalation path that treats a breach as a routing problem rather than a personal failing.
Promise a first response, not a finished review
The distinction that separates SLAs teams keep from SLAs teams abandon: what exactly is promised. A finished-review SLA makes the reviewer accountable for the size and clarity of a diff they did not write. When a 2,000-line PR lands, the reviewer facing a 24-hour completion clock has two options, and both are bad: skim and approve, or blow the SLA and stop believing in it.
A first-response SLA promises something the reviewer actually controls: within a few working hours, the author hears one of “reviewing now,” “I can get to this at 3pm,” or “I am the wrong person, try Dana.” Any of those beats silence, because silence is what actually burns authors. Lou Franco made the sharp observation that authors control much of their own wait time: small PRs that take under fifteen minutes to review get picked up as mini-breaks between tasks, while big ones wait for a mythical free afternoon. The SLA covers the reviewer’s half of that bargain; the author’s half is keeping the diff small enough that a fast response is even possible.
One business day is the ceiling, not the target
Google’s engineering practices are unambiguous on the outer limit: one business day is the maximum time to respond to a review request, and the guidance frames speed as a first-class property of the whole system, because a slow review blocks the author, the feature, and everyone waiting behind the merge. Note what the rule is: a ceiling. A team whose median review lands in two hours and whose worst case is one business day has a healthy distribution. A team whose median is one business day has normalized the worst case.
This is also why a code review SLA should be measured at the distribution level, not policed per PR. Track time-to-first-response weekly, look at the tail, and ask what the slowest 10% have in common. Usually the answer is not a lazy reviewer. It is a lost review request: a notification buried in email, a re-request nobody saw, a PR assigned to someone on vacation. Fix the routing and the tail collapses on its own.
Review blocks make a code review SLA cheap to keep
The standard objection to any code review SLA is interruption cost: “I cannot drop into someone’s PR every time a notification fires and still do deep work.” The objection is correct, and the answer is not to soften the SLA but to change when reviews happen. Two or three scheduled review blocks per day (start of day, after lunch, before close) let a reviewer meet a four-hour first-response promise without ever being interrupted mid-task.
Predictability is the real product here. An author who knows reviews happen at 9, 1, and 4 stops pinging, plans their day around those slots, and queues work accordingly. The team stops paying the coordination tax of “is anyone looking at this?” This is the same capacity argument we made in review capacity planning: review time is a budgeted resource, and a budget you schedule is one you actually spend. An SLA without scheduled capacity behind it is a wish.
Scale the clock to the diff
A flat SLA treats a one-line config change and a cross-cutting refactor as the same object, which quietly rewards authors who batch everything into one giant PR (one SLA clock instead of five). Better: keep the first-response promise flat, and let the full-review expectation scale with size and risk. A small, well-described PR should get a complete review in the same block where it got its first response. A large one gets an honest timeline in that first response instead of a fake deadline. If large PRs dominate the queue, the SLA is not your problem; PR size is.
When the SLA breaks: escalate without shame
Every SLA breaks. The design question is what happens next, and the answer determines whether people keep reporting honestly. The escalation path that works is mechanical and blame-free:
- At the deadline, the author sends exactly one direct nudge.
- Two hours later, the PR moves: a named backup reviewer or the team’s shared review queue picks it up. The original reviewer is off the hook, no explanation required.
- Repeated breaches surface in the weekly numbers as a capacity conversation (“reviews are landing on two people”) rather than a performance one.
The moment a missed SLA becomes an accusation, reviewers start gaming it: placeholder “looking!” comments that buy time, quick approvals that end the clock. An SLA is there to make waiting predictable and to surface routing and capacity problems early. Keep it aimed at the system and teams keep it; aim it at individuals and it dies in a quarter.
Frequently asked questions
What is a reasonable code review SLA?
First response within four working hours, full review within one business day. Google’s engineering practices treat one business day as the outer limit, not the target. The first-response promise matters more than the completion promise: an author who hears “looking at this after lunch” can plan around the wait, while silence forces them to guess.
Should a code review SLA require the review to be finished?
No. Promise responsiveness, not completion. A finished-review SLA punishes reviewers for large or messy PRs they did not write, so they either rubber-stamp to hit the clock or quietly ignore the rule. A responsiveness SLA (acknowledge, give a timeline, or hand off) is within the reviewer’s control regardless of diff size, so it survives.
What should happen when a review misses its SLA?
Escalation should reroute the work, not shame the person. A missed SLA usually means the reviewer is overloaded or away, so the fix is a visible next step: the author pings once, then the PR moves to a backup reviewer or a team queue. Treating breaches as routing signals keeps people honest about capacity instead of hiding behind silence.
Top comments (0)