SREference

Operations Reviewed

Production readiness review checklist

A production readiness review (PRR) checks that a service can be run reliably before a team takes on its pager or its users depend on it. Reviewers and owners find the gaps, agree which must close first, and record the outcome. Google once gated every SRE takeover of a service on a PRR; it now keeps full reviews for the launches where they pay off and relies on safe-by-default platforms and lighter reviews for the rest.

On this page
  1. What a PRR covers
  2. Running a review
  3. Worked example
  4. The checklist
  5. Making it stick

What a PRR covers

The first edition of Google’s SRE book groups the concerns of production into six areas; a review gauges how mature the service is in each:

The book’s own example questions are specific and answerable: does an update touch too much of the system at once; do user requests depend on a system built for batch work; are all user-visible failures instrumented, monitored and alerted on. Reviewers also read the service’s recent incidents, postmortems and their follow-up tasks to judge what emergency response it will need.

Alerts tell you that something is wrong; debugging needs telemetry that says why. Observability Engineering (2nd ed., 2026) suggests checking that each change can answer “is this working as intended?” in production, and that telemetry carries context such as build ID, host, region and customer, so a problem confined to one build or one customer can be found by breaking down the data rather than by guessing.

Running a review

These six phases are the first edition’s model for onboarding a service to SRE; drop the training and handover phases when the owners will keep the pager.

  1. Engage. One to three reviewers agree with the owners on the SLO, any disruptive design changes, and a schedule.
  2. Analyse. Work through a checklist specific to the service, built from experience with similar systems and the team’s own standards.
  3. Improve. Rank the findings by their effect on reliability, agree a plan with the owners, and fix them together. This phase varies most in length.
  4. Train. The incoming on-call team learns the design, request flows and production set-up, with hands-on exercises.
  5. Hand over responsibilities progressively, with the developers backing up the new team for a while.
  6. Keep improving. New features and dependencies get reviewed as they arrive, and lessons go back into the checklist.

Earlier is cheaper. The SRE book contrasts a review of an already-launched service, which in Google’s experience took two or three SREs two or three quarters, with early engagement during design, and with shared frameworks that make services production-ready by construction; with frameworks, onboarding usually took one SRE one quarter. The same checklist works as a design review, a launch gate or a yearly check of a service you already run.

The second edition (2026) goes further. Google SRE has moved away from strict PRRs: reviews made SRE a gatekeeper, cost reviewer time that grew with every feature, and found problems late, when fixes are most expensive. Its SRE teams now invest in standard platforms with automated, supervised rollouts, give full reviews only to the most complex or risky launches, run a lightweight review for others, and train product teams to run their own launch reviews. A checklist like the one below is what such a self-review needs; the more of it your platform answers by default, the shorter the review.

Worked example

Can the SLO survive its dependencies, and how much capacity?

A new service promises 99.9% over 30 days (43m 12s of full outage). It has three hard dependencies, each with a 99.95% SLO. At peak it serves 19,000 requests a second, and load tests show one cluster breaks at 5,000. Failures are assumed independent.

  1. If each dependency only just meets its SLO, the best the service can do:99.95% × 99.95% × 99.95% = 99.85%
  2. That is below 99.9%, so the SLO is unachievable before the service fails on its own account. With one dependency made soft (served from a cache or dropped on failure):99.95% × 99.95% = 99.900025%, leaving 0.000025% for the service itself, about 649ms a monthThat is still out of reach in practice: any deploy or failover of its own would spend it.
  3. With two dependencies made soft:99.95%, leaving 0.05% for the service, about 21m 37s a month
  4. With dependencies at 99.99% instead:99.99%³ = 99.97%, leaving 0.07% of the 0.1% budget for the service
  5. Capacity for peak with two clusters lost (N + 2):⌈19,000 ÷ 5,000⌉ + 2 = 6 clusters

Not ready as designed: with three hard 99.95% dependencies, 99.9% is out of reach, and making one soft barely helps. Make two dependencies soft, negotiate stronger ones, or lower the SLO before launch. Plan 6 clusters for peak, the same answer as the SRE book’s example.

Multiplying availabilities assumes dependencies fail independently, so treat the result as an estimate: outages that overlap cost less than the product suggests, and dependencies often beat their SLOs, but planning on either leaves no margin. See the availability table for composite availability.

The checklist

A starting point to copy and adapt, built from the SRE book’s six areas, its example questions and Google’s 2005 launch coordination checklist. It is not a standard: drop what doesn’t apply, and add what your own incidents have taught you. 

# Production readiness review: [service]
Reviewers: [names]   Owners: [team]   Date: [YYYY-MM-DD]
Outcome: ready / ready with conditions (listed, with owners and dates) / not yet

## Service level objectives
- [ ] SLIs measure what users see, and SLOs are agreed with the product owner
- [ ] Error budget policy written and signed off
- [ ] Dashboards cover every SLI in the SLOs

## Architecture and dependencies
- [ ] Diagram of components, request types and data flows is current
- [ ] Every dependency listed as hard or soft, with its SLO and owner
- [ ] The SLO is achievable given the hard dependencies' SLOs
- [ ] Soft dependencies fail gracefully; nothing user-facing calls a batch system
- [ ] Every remote call has a timeout, bounded retries and backoff with jitter

## Capacity and performance
- [ ] Load tested to the breaking point; the limit per instance/cluster is known
- [ ] Capacity for peak at N + 2 (or survives losing a zone), with launch spikes
- [ ] Growth forecast and a plan for 10x; growth alerts before limits
- [ ] Overload behaviour: sheds load or degrades rather than falling over

## Monitoring and alerting
- [ ] Pages are symptom-based (burn-rate on the SLOs) and each links to a runbook
- [ ] Every user-visible failure is counted; errors go to central logging
- [ ] Each request emits a structured event or trace with build, endpoint and customer fields
- [ ] Trace context propagates across service calls and queues
- [ ] Monitoring of the monitoring: absent data and stopped traffic alert
- [ ] Expected page load fits the rotation (at most 2 incidents per shift)

## Emergency response
- [ ] On-call rotation staffed, trained and has production access
- [ ] Escalation path and incident process known; contacts for dependencies
- [ ] Runbooks for the top failure modes; a game day or drill has used them
- [ ] Open postmortem action items reviewed; none block readiness

## Change management
- [ ] Builds reproducible; deploys automated, staged and canaried
- [ ] Rollback tested; data and config changes are rollback-safe
- [ ] Configuration validated before use; feature flags have owners

## Data and recovery
- [ ] Backups taken and restores tested against RPO and RTO
- [ ] Behaviour known for machine, zone and region loss

## Security and access
- [ ] Security review done; secrets managed; least-privilege access

Making it stick

Sources: Google, Site Reliability Engineering, 1st ed., ch. 32 “The Evolving SRE Engagement Model”, appendix E “Launch Coordination Checklist” ch. 11 “Being On-Call” (at most two incidents per 12-hour shift) and ch. 22 “Addressing Cascading Failures” (N + 2 example); The Site Reliability Workbook, ch. 18 “SRE Engagement Model”; Site Reliability Engineering, 2nd ed. (2026), ch. 7 “SRE Engagement Models” (“The Evolution of Google SRE’s Engagement Model” and “Beyond Production Readiness Reviews”); Charity Majors, Liz Fong-Jones and George Miranda, Observability Engineering, 2nd ed. (2026), ch. 9 “Observability-Driven Development” (instrumentation with build and request context).