Understanding Production Readiness Review
A production readiness review is a formal checkpoint, usually conducted before a new service launches or before an existing service takes on significantly more traffic or criticality, where SRE or platform engineers evaluate the service against a defined set of operational standards. The practice originated in large organizations like Google, where launching a new service without a consistent bar for reliability, monitoring, and operational maturity was found to reliably produce avoidable incidents. Rather than leaving readiness to the judgment of whichever team built the service, a PRR applies a consistent, cross-team standard, catching common gaps like missing alerting, no defined on-call ownership, or no tested rollback plan before they matter in production.
What a PRR Typically Covers
- Monitoring and alerting: does the service have dashboards covering the golden signals (latency, traffic, errors, saturation), and are paging alerts configured for genuinely actionable conditions?
- SLOs and error budgets: has the team defined service level objectives, and do they have a plan for what happens if the error budget is exhausted?
- On-call readiness: is there a defined on-call rotation and escalation policy, and do responders have runbooks for known failure modes?
- Scalability and capacity: has the service been load tested against expected peak traffic, and is autoscaling configured and validated?
- Resilience: does the service handle dependency failures gracefully, using patterns like circuit breakers, timeouts, and retries with backoff, rather than cascading failures upstream or downstream?
- Deployment safety: is there a tested rollback procedure, and does the deployment pipeline support safe rollout strategies like canary or blue-green deployment?
- Security and compliance: are secrets managed properly, is access controlled appropriately, and does the service meet any relevant compliance requirements?
A Concrete Example
A team is preparing to launch a new payments processing microservice and submits it for a PRR before go-live. The review surfaces several gaps: the service has dashboards for CPU and memory but nothing tracking actual payment success rate or latency percentiles, meaning the team would have no early warning of a degraded payment experience even though infrastructure metrics looked fine. It also has no defined on-call rotation yet, since the team assumed the platform team’s general on-call would cover it, an assumption the platform team wasn’t aware of and hadn’t agreed to. The PRR blocks launch until the team adds payment-specific SLOs and alerting, establishes an explicit on-call rotation with a documented escalation policy, and runs a load test simulating the expected launch-day traffic. Two of these gaps, in particular the missing on-call ownership, would very likely have caused a slow, confused response to the service’s first real production incident had they not been caught before launch.
Why It Matters for Reliability
A PRR shifts reliability work earlier, catching foreseeable operational gaps during design and pre-launch review rather than discovering them during the service’s first real incident, when the cost of finding out is far higher. It also creates organizational consistency: without a shared standard, reliability maturity across services in the same company can vary wildly based on which team built each one and how much operational experience they happened to have. A well-run PRR process also builds institutional knowledge over time, since the checklist itself evolves based on lessons learned from real postmortems, effectively encoding past incidents into a preventive check for future services.
How Teams Implement It
- Maintain a living checklist that’s updated based on findings from real postmortems, so the review reflects actual lessons learned, not a generic template.
- Scale the rigor of the review to the criticality of the service; a low-traffic internal tool doesn’t need the same depth of review as a customer-facing payments path.
- Involve the team building the service early, ideally during design, rather than only at the end right before launch, so gaps can be addressed as part of the build rather than as last-minute blockers.
- Treat the PRR as a genuine gate with the authority to delay launch for unresolved critical gaps, not just an advisory checklist that can be skipped under deadline pressure.
- Revisit readiness periodically for existing services, not just at initial launch, since operational maturity can drift as a service’s traffic, criticality, or dependencies change over time.
Trade-offs and Limitations
A PRR process adds time and friction to launches, which can create tension with teams under pressure to ship quickly, so the checklist needs to focus on genuinely high-value items rather than becoming exhaustive bureaucracy that gets rubber-stamped without real scrutiny. It also only catches what’s on the checklist; novel failure modes specific to a new service’s unique architecture may not be covered by a generic organizational standard, which is why PRRs work best alongside, not instead of, practices like chaos engineering and game days that test resilience empirically rather than just on paper.
Frequently Asked Questions
What is Production Readiness Review?
A production readiness review (PRR) is a structured, checklist-driven evaluation that assesses whether a new service meets an organization's operational, reliability, security, and scalability standards before launch.
How does Production Readiness Review work?
Production Readiness Review works by combining the components described in the sections above. The main page walks through the architecture, the typical use cases, and the trade-offs to weigh before adopting it.
Why does Production Readiness Review matter?
Teams adopt Production Readiness Review to ship faster, run more reliably, and reduce the cognitive load on engineers. The benefits, limits, and adjacent tools are covered in the body above.
When should you use Production Readiness Review?
Use Production Readiness Review when the problems it solves match what your team is hitting today. The page above outlines the signals that mean you should adopt it now, and the cases where a simpler approach is fine.
