Production Readiness Review

Definition

A Production Readiness Review (PRR) is a structured evaluation of a service before it is allowed to serve production traffic. The review covers the aspects that will determine whether the service can be operated safely once it is live: reliability, observability, security, capacity, deployment, on-call ownership, dependencies, data handling. The review is normally driven by a checklist maintained by an SRE or platform team and signed off by both the owning team and the platform reviewer.

Origin

The formal PRR was popularised by Google's Site Reliability Engineering practice and documented in the SRE book. Similar practices exist under different names — launch reviews, operational readiness gates, production checklists — and are now normal at any organisation running non-trivial numbers of services. The underlying idea is that "ready for production" is a definable state, not an opinion.

What a PRR Covers

• Ownership — a named team, an on-call rotation, an escalation path.
• SLOs — service level objectives agreed with the consumers of the service.
• Observability — logs, metrics and traces at a defined baseline, with dashboards.
• Alerting — every SLO breach paging the on-call, with a runbook for every alert.
• Deployment — automated, repeatable, with rollback tested and demonstrated.
• Capacity — load test results at expected peak, headroom stated.
• Dependencies — mapped, with graceful degradation strategy for each.
• Security — threat model, authentication, authorization, secrets management, dependency scanning.
• Data — backup, restore tested, retention policy, PII handling.
• Incident response — runbooks, communication templates, past-incident learnings incorporated.

Why It Matters

Services that go live without a PRR routinely take out other services. They page teams that didn't know they were a dependency. They fail silently because there was no alerting. They can't be rolled back when the first incident hits. They are recovered manually because there is no runbook. The PRR is not bureaucracy; it is the organisation refusing to accept that going live is a design decision that can be deferred.

Real-World Example

A retail company launched a new recommendations service into production without going through their platform team's PRR. Within two days it was answering 40% of homepage requests. Within a week it was overloading a downstream personalisation store that had been provisioned for 20% of that load. The store degraded, the checkout service that depended on it degraded, and revenue dropped for three hours during peak shopping. The postmortem identified that the PRR had been skipped because the team had considered the service "just a proof of concept" — but production traffic doesn't care about that label. The next PRR the team went through added a section that any service serving more than 1% of production traffic required review, regardless of what it was called internally.

How to Run a PRR

1. Publish the checklist. Every engineer should know what they will be reviewed against long before they are ready for review.
2. Schedule the PRR when the service is 70% complete, not 100%. Findings need time to be addressed.
3. Do it as a working session, not a sign-off. Walk the checklist together, agree what is done, what is deferred with justification, and what blocks launch.
4. Distinguish blockers from improvements. A missing runbook is a blocker; a nicer dashboard is an improvement.
5. Record the outcome — the review, the findings, the follow-ups, the go/no-go decision.
6. Re-review at defined intervals — every 6 or 12 months for critical services, or whenever the service materially changes.

Practical Lessons Learned

• Checklists date quickly. Review the checklist itself every year — new threats, new tools, new lessons.
• PRRs that only happen at launch miss the drift. A service that passed two years ago may fail today.
• The most valuable finding is often about ownership. Many production problems come from services with unclear owners, not from technical gaps.
• Load testing is where most services stumble. Every team believes they've done enough; most haven't.
• Runbooks written after the review are usually written badly. Insist they exist and are usable before sign-off.
• PRR should be lightweight for small services. Same checklist, less depth in each item.

Expert Tips

• Make PRR part of the release path, not a side quest. Deploy pipelines can require evidence of a passed PRR before promoting to production.
• Pair the reviewer with the on-call engineer, not just the tech lead. The person who will be paged has the sharpest questions.
• Rehearse a rollback during the review — the theoretical rollback plan that everyone signs off on is not the same as the rollback that actually works.
• Include a real chaos test at the review — kill a dependency and see whether the service degrades gracefully.
• Score consistently across services so the PRR is comparable — otherwise it becomes negotiation, not review.

Common Mistakes

• Running the PRR at 100% completion when nothing can be changed.
• Treating it as sign-off theatre rather than a working session.
• Never re-reviewing existing services.
• No distinction between blockers and improvements.
• Runbooks written to pass the review rather than to be usable at 3am.
• Load tests run against artificial traffic patterns.
• No rehearsed rollback.

Key Takeaways

• Production readiness is a definable state, not an opinion.
• A published checklist plus a working-session review beats a sign-off form.
• Distinguish blockers from improvements; record deferrals with justification.
• Re-review periodically — services drift.
• Pair the reviewer with the on-call engineer, and rehearse a real rollback.

Related Concepts

Interlocks with SLOs, Error Budgets, Runbooks, On-Call Rotation, Chaos Engineering, and Observability. Templates at PMMilestone.org.