Production Readiness Reviews

Every other page in this course assumes a service is already on the pager — that SLOs exist, that an on-call rotation answers when the SLO burns, that someone owns the runbook. This page is about the gate before that: the moment an SRE team decides whether to accept a new service onto its pager in the first place. That gate is the production readiness review (PRR) — a structured checklist run against a service before launch, covering monitoring, capacity, dependencies, rollback, on-call ownership, and documented SLOs. Done well, a PRR isn't paperwork bolted onto a launch date; it's the specific mechanism by which operational risk changes hands from the team that built a service to the team that will be woken up for it.

What a production readiness review actually gates

☺ Like you're 10: It's not a review of whether the code is good — it's a review of whether SRE is willing to be the one who gets woken up for it.

A PRR is not a code review, and it is not a launch approval in the product-management sense — a service can be fully approved to ship, fully funded, and completely blocked from SRE support at the same time, because those are two different questions answered by two different gates. The question a PRR answers is narrower and more specific: if this service starts failing at 3 a.m., is the organization actually equipped to notice, respond, and recover — and is SRE willing to be the team holding the pager when it happens? What is SRE? already introduced the underlying instinct — SRE teams gatekeep what they'll operate, because a service that isn't reviewed for reliability before launch generates toil by design, and an SRE team that accepts it uncritically ends up doing by hand, forever, what should have been designed out once. A PRR is that instinct turned into a repeatable, scored process instead of a judgment call made in a hallway.

The term itself varies by company — some call it an operational readiness review (ORR, the name AWS's Well-Architected program uses for its own version of the same idea), some fold it into launch readiness or launch coordination review, and Google's own SRE literature discusses the practice under a few overlapping names. Treat the label as flexible and the mechanism as the constant: before a service starts consuming SRE's on-call capacity, someone runs a structured check against it and makes an explicit accept/reject decision, rather than the service drifting onto the pager by default because it shipped.

The six categories, in depth

☺ Like you're 10: Six specific things get checked, every time, in the same order — not "does this feel ready," but six yes-or-no questions with evidence attached to each one.

A good PRR checklist resists two opposite failure modes: too vague to fail anyone ("is the service reliable?") and too long to finish (a 200-item spreadsheet nobody reads past item 40). Most working checklists converge on some version of the same six categories, because each one maps to a specific way services actually go down at 3 a.m. and catch an unprepared team off guard.

Monitoring & alerting

Can the team even tell the service is unhealthy, and will the right person find out in time? The bar here is higher than "we have a dashboard." It means request-based SLIs exist on the four golden signals — latency, traffic, errors, saturation — not just infrastructure metrics that don't reflect what a user actually experiences; it means alerting is derived from burn rate against a documented error budget rather than an arbitrary static threshold someone picked once and never revisited (see multi-window, multi-burn-rate alerting for exactly how that's built); and it means at least one check — a synthetic probe or blackbox monitor — verifies the service from outside its own metrics pipeline, so a total observability outage doesn't also leave the team blind to the outage it was supposed to reveal.

Capacity

Has anyone verified the service survives more load than it sees today, or is "it'll probably scale" the entire capacity plan? A PRR wants evidence: a load test at a specific multiplier of current peak traffic (2–3× is a common bar, higher for anything with seasonal or promotional spikes), horizontal autoscaling that's been triggered and observed working, not merely configured, and an identified next bottleneck — the specific resource that will constrain growth first, whether that's a database connection pool, a single-threaded queue consumer, or a downstream rate limit. Capacity planning & performance and queueing theory for SRE cover how that headroom number actually gets derived rather than guessed.

Dependencies

What does this service call, and what happens when one of those calls is slow or down? A PRR wants the full dependency graph enumerated, each hard dependency's own SLO compared against this service's target — a service can't credibly promise 99.99% while depending synchronously on something that only promises 99.9%, without an explicit fallback for that gap — and every synchronous call across a network boundary wrapped in a timeout, a bounded retry with backoff and jitter, and a circuit breaker, exactly the patterns in reliability patterns. It also wants shared-fate risk called out explicitly: does this service share an availability zone, a DNS provider, or an auth system with something else critical, in a way that turns an unrelated outage into this service's outage too. Dependency management & Hyrum's law goes deeper on the subtler version of this problem — the dependencies you didn't design, that formed anyway because callers started relying on incidental behavior.

Rollback

If the next deploy is bad, how does it get undone, and has that path actually been exercised? "We can kubectl rollout undo" is a claim, not evidence — a PRR wants to know the rollback has been tested under realistic conditions, that database migrations follow an expand-contract pattern so an old binary can run against a new schema during the window a rollback would need, and that there's a documented time bound on how long a rollback takes, checked against how much error budget that duration would burn. Feature flags and progressive delivery — canary or staged rollout — matter here too, because they let you decouple deploying a bad change from releasing it to everyone; see release engineering & progressive delivery for the full mechanics.

On-call ownership

When the page fires, whose phone actually buzzes, and are they ready for it? Vague ownership — "the platform team," with no rotation defined in the paging tool — is one of the most common PRR failures, because it looks like an answer and isn't one. A PRR wants a named primary and secondary rotation with realistic timezone coverage, an escalation path for when primary doesn't acknowledge, and runbooks linked directly from each alert rather than a wiki search away, matching the bar set in the on-call readiness checklist. It also wants the humans in that rotation to have actually been trained or shadowed on this specific service before go-live — see incident management & on-call for what "ready" means once the page does fire.

Documented SLOs

Is there an actual number, agreed by stakeholders, that defines "reliable enough" for this service — or is reliability a feeling everyone privately disagrees about? A PRR wants SLIs that are request-based and user-facing rather than resource-utilization proxies, targets with explicit sign-off from both the owning team and SRE (not a number one engineer picked), and an error-budget policy attached that says, concretely, what happens when the budget runs out — see SLIs, SLOs & error budgets for how that number gets derived in the first place. Without this category, the other five have nothing to be measured against: "is capacity enough" and "did monitoring catch it in time" are unanswerable questions until "enough" and "in time" are defined in writing.

Risk transfer, not bureaucracy

☺ Like you're 10: Signing off on a PRR isn't stamping a form — it's SRE saying "yes, if this breaks, page us," which is a real promise with a real cost attached.

The most common way a PRR goes wrong isn't a missed checklist item — it's treating the whole exercise as a formality that blesses work already decided. It isn't one. Before a PRR, operational risk for a service sits entirely with the team that built it: if it pages at 3 a.m., that team's own engineers are the ones who wake up, whether or not anyone officially agreed to that arrangement. Passing a PRR is the specific moment that risk changes hands — SRE is agreeing to accept a slice of it, in the concrete form of being the team the pager escalates to, in exchange for the service clearing a bar SRE itself defined. That's not a symbolic gesture. On-call capacity is a finite, scarce resource, the same way the 50% rule treats an SRE team's operational bandwidth as a hard ceiling rather than an infinitely absorbent sink — every service SRE accepts is a slice of that ceiling spent, permanently, until the service is decommissioned or handed back.

This is also why a PRR should never be run by, or rubber-stamped at the request of, the team being reviewed. The entire point is an independent party — SRE, or a review board with SRE representation — deciding whether they're willing to accept the risk, not the building team self-certifying that their own creation is fine. The same logic that makes blameless postmortems credible — an incentive structure where the person closest to the decision isn't the one grading it — applies here for the same reason.

Scoring the review: blocking, time-boxed, and advisory findings

☺ Like you're 10: Not every problem the reviewer finds stops the launch — some just get a deadline and an owner, like a homework assignment with a due date.

Treating every finding as equally launch-blocking is how PRRs turn into multi-month standoffs that teams learn to route around. A working PRR sorts findings into three tiers, the same triage instinct postmortem action items use for follow-up work:

Here's a scorecard from a real-shaped review, tracked the same way a team would track it in an issue tracker rather than a document that gets closed and forgotten:

service: checkout-api
review_date: 2026-08-16
reviewer: sre-oncall-lead
categories:
  monitoring_alerting:  { status: pass }
  capacity:
    status: time-boxed
    finding: "Load-tested at 1.5x current peak; policy requires 3x before Q4 sale event"
    owner: team-checkout
    due: 2026-09-15
  dependencies:
    status: blocking
    finding: "Call to payments-gateway has no timeout or circuit breaker"
    owner: team-checkout
    due: 2026-08-30
  rollback:              { status: pass }
  on_call_ownership:
    status: blocking
    finding: "No secondary rotation staffed — single point of failure overnight"
    owner: team-checkout-eng-manager
    due: 2026-08-25
  documented_slos:       { status: pass }
decision: conditional_fail
support_model: >
  team-checkout remains primary on-call for all pages until both blocking
  items close. SRE re-reviews on 2026-09-01; blocking items reopen the
  review, time-boxed items do not.

What happens when a service fails: fix the gaps, or launch unsupported

☺ Like you're 10: Failing doesn't mean the restaurant can't open — it means the fire department isn't promising to show up until the exit sign gets fixed.

This is the detail that most separates a healthy PRR from a launch-blocking one, and it's worth stating precisely: in most organizations, a failed PRR does not stop a service from shipping. Product and engineering leadership can still choose to launch on schedule — what a failed PRR actually withholds is SRE's agreement to operate it. A service that fails its review has exactly two paths forward, and both are legitimate outcomes, not consolation prizes:

• Close the blocking gaps and re-apply. The team fixes what's blocking — wires the timeout, staffs the second rotation, load-tests to the required multiplier — and the service re-enters the review, typically re-scoring only the categories that changed rather than starting over.
• Launch self-supported. The service ships on its own team's pager, with SRE support explicitly withheld until it re-applies and passes. This is not a punishment; it's an honest description of where the risk currently sits, made visible instead of assumed away.

The exception is the small set of organizations, or the small set of especially high-blast-radius services within any organization, where launch itself is gated on the review — a genuinely launch-blocking PRR, reserved for cases where an unready service could cause outsized harm (payment processing, data-loss risk, regulatory exposure) rather than "merely" paging the wrong team. Know which regime your organization runs before you promise a launch date against an unfinished PRR — the two models have very different failure costs.

Production readiness isn't a one-time stamp

☺ Like you're 10: The fire marshal doesn't inspect a restaurant once and disappear forever — she comes back if the kitchen gets rebuilt, or if the alarm keeps going off for the wrong reasons.

A PRR that only ever runs once, before the original launch, quietly stops meaning anything within a year or two, because the service it certified doesn't stay still. A few triggers should reliably reopen the review, not wait for someone to remember:

• Material architecture change. A new hard dependency, a new datastore, a move from synchronous to event-driven — anything that would have changed the answer to a category if it had been true at the original review.
• Ownership transfer. The team that passed the original PRR isn't the team on the pager anymore. Institutional knowledge about why a control exists doesn't transfer automatically with the repo.
• A pattern of misses, not just one incident. A single postmortem doesn't necessarily reopen a PRR — but a cluster of postmortems pointing at the same category (three incidents in a quarter all rooted in the same unprotected dependency) is exactly the signal a category needs re-scoring, not just a one-off fix.
• Scheduled recertification. Many teams re-run a lightweight version annually, or ahead of a known high-traffic event, independent of whether anything obviously changed — the same instinct that makes a fire marshal's certificate expire on a calendar rather than only on visible damage.

None of this is free — reviews cost the reviewing team's time as surely as they cost the reviewed team's — which is exactly why the six categories and the blocking/time-boxed/advisory split exist: to keep a re-review a focused, bounded exercise on what actually changed, not a full re-litigation of a service that's been fine for two years.

Where PRRs go wrong

☺ Like you're 10: A checklist that gets filled out but never actually read isn't a safety check — it's a piece of theater everyone's pretending is one.

A few failure modes recur often enough to name directly, and each one quietly turns a real safeguard into a ritual:

• PRR theater. The document gets filled out, filed, and never opened again — findings aren't tracked as action items with owners and deadlines, so "conditional pass" quietly becomes "pass" by attrition. The YAML-style scorecard earlier on this page exists specifically to resist this: a finding with no owner and no due date isn't a finding, it's a wish.
• Rubber-stamping under launch pressure. The most dangerous moment for a PRR's credibility is the week before a committed launch date, when "we'll fix it after we ship" starts sounding reasonable to everyone in the room, including the reviewer. See Google & the error-budget policy for how a comparable pressure — shipping features against a spent error budget — gets handled by pre-committing to the rule before the pressure exists, which is the same defense here: agree what "blocking" means before a launch date makes agreeing hard.
• Checkbox worship over intent. "We have alerts" satisfies the letter of the monitoring category while missing its point entirely if those alerts are so noisy the on-call engineer mutes the channel — see alert design & alert fatigue for exactly this trap. A reviewer's job is checking that a category's purpose is met, not just that a box has an artifact next to it.
• No single accountable reviewer. A PRR run by committee, with no one person able to say "this is blocking" and make it stick, degrades into negotiation — see SRE anti-patterns & pitfalls for this failure mode alongside its siblings. Someone needs the explicit authority to say no, or the review isn't a gate, it's a suggestion.

Where this fits

☺ Like you're 10: This page is the door; everything else in this course is what's supposed to already be true by the time someone knocks on it.

A production readiness review doesn't introduce any new mechanism of its own — it's an audit that a service already has the mechanisms the rest of this course covers, checked in one place before the pager gets involved instead of discovered piecemeal during an incident. SLIs, SLOs & error budgets supplies the documented-SLOs category; reliability patterns supplies the dependency-hardening category; release engineering & progressive delivery supplies the rollback category; and incident management & on-call supplies the on-call-ownership category. If you want to see what an unready service costs in practice rather than in the abstract, the worked incident case study and the reference-section case studies are exactly PRR gaps playing out in production. And if you want practice running one end to end, Capstone Part 3 — write the on-call runbook builds the artifact a PRR's on-call category actually checks for.