Production Readiness Review (PRR): What Makes a Service Worth SRE Taking Over

The previous fifteen posts almost all talked about “the service is already live; how do we make it more reliable” — SLOs, monitoring, postmortems, degradation. But one earlier question never got asked: what qualifies a new service to launch at all, and to be worth SRE taking over and carrying its pager? Google SRE’s answer is a gate — the Production Readiness Review (PRR). This post covers that gate: what it reviews, why it must happen before launch, and the lever behind it that’s most useful to a lead — SRE can say no.

PRR is a gate, not a document

Start with the root of the problem. The traditional approach is that development finishes the service and throws it over the wall for ops/SRE to “look after”. But there’s a fatal asymmetry here: features can be added slowly afterwards; reliability can’t. Discovering after launch that there’s no monitoring, no rollback, that one dependency going down takes everything with it — patching that then is the most expensive way to patch, and usually comes with a 3am incident attached. SRE’s solution is direct: before the service launches and SRE takes it over, it passes a PRR. It isn’t a form for bureaucratic sign-off; it’s a checklist that turns reliability into a “hard launch gate”:

The key isn't the checklist itself; it's the fork on the right: pass, and SRE takes over and shares the pager; fail, and it goes back to be fixed — and until it's fixed, the pager stays with Dev. This power of "not done? don't expect us to take it" is PRR's real force. It turns the bounced cheque of "we'll add monitoring after launch" into a list that has to be cashed before launch

What PRR reviews: accepting every previous post, before launch

The PRR list looks intimidating, but you’ll notice nothing on it is new — it’s this series’ lessons, accepted line by line on one form before launch:

Is the SLO defined? (SLI/SLO) Without a target there’s no way to judge “reliable enough”, and the alerting and capacity behind it lose their baseline.
Monitoring and alerting? (the four golden signals, alert on symptoms) From the first moment of launch it must be visible, and able to wake someone when it truly hurts.
Capacity and load testing? (load shedding) Know where your limits are, and shed actively under overload rather than swallowing until everything rots together.
Release and rollback? (release engineering) When it breaks, can you roll back in one step, fast and safely — the most-used escape hatch after launch.
Dependencies and failure modes? (degradation) When a dependency dies, does it degrade to usable, or does the whole chain fall?
Runbook and docs? (incident response) The on-call can operate it at 3am by following along, rather than only the author knowing.

In one sentence: PRR introduces no new requirements; it compresses the whole series’ practice into one check-up before launch. Everything you learned in the earlier posts — PRR is the acceptance form.

Why it must be “before launch”: shift reliability left

The same gap — no rollback, no degradation path — costs wildly different amounts depending on when you fill it:

The same gap, filled at the PRR stage, is daytime, cheap, no consequences; wait until it explodes after launch as a 3am incident and it's the most expensive way to fill it, with a postmortem thrown in. PRR's entire value is moving the expensive fixes on the cost curve left, to when they're still cheap — the same thinking as [[sre-testing|testing for reliability]]: "catch it earlier, cheaper, so you dare move fast"

Reflections

The lesson I feel most from years of leading teams: if reliability requirements have no gate that “must be passed before launch”, they will always be squeezed out by the deadline. “We’ll add monitoring after launch”, “ship first, sort rollback out later” — I’ve heard these too many times, and they almost always turn into “we’ll add it after it blows up in Production”. What PRR gives SRE is a real bargaining chip: “If you want us to take over and carry the pager, do these things first.” The chip works because the pager is scarce — you can’t unconditionally promise to get up at 3am for anything. Once “SRE support” isn’t a free gift but something to be earned, reliability shifts from “goodwill when we have time” to “a condition to be met before launch”. Now, when I take on a new service, my first act isn’t scheduling features; it’s asking one question: when this blows up at 3am after launch, who carries it, and following what? If that can’t be answered clearly, it isn’t at the point where it can launch.

PRR isn’t a rubber stamp; it’s a design review

The worst PRR is a form thrown out the day before launch, everyone rushing to tick boxes over a fait accompli. Its most valuable moment is exactly the opposite — early, stepping in while the architecture can still change. Because what a good PRR forces out is often architectural: “this downstream dependency has no degradation path at all; when it dies you die with it”, “this write isn’t idempotent; a retry will double-charge” — things almost impossible to change once live, propped up only by a pile of operational workarounds. So I position PRR as SRE’s highest-leverage collaboration with development: it isn’t acceptance testing; it’s both sides designing reliability in while there’s still time. Reducing it to after-the-fact ticking throws away the most valuable moment.

Taking over isn’t the end; the engagement is revocable

One last, often-neglected second half. Services decay: clean through PRR today, and a year later stuffed with toil, SLO chronically broken, runbook long stale. SRE’s engagement model has a principle I very much agree with — after taking over, if a service rots long enough to drag SRE into a swamp of toil, SRE has the right to hand the pager back. That isn’t a threat; it’s protection: it makes “operable” not a snapshot at the moment of launch but a state to be continuously maintained, and it stops development from launching and walking away. It also ties the whole series together — from the error budget to PRR, the underlying logic of SRE’s entire toolkit has always been one sentence: reliability isn’t anyone’s goodwill; it’s an engineering contract with explicit thresholds, bargaining chips, and the right of refusal.