SRE Production Readiness Reviews
Launching a service without preparation invites late-night emergencies. A Production Readiness Review, or PRR, checks that a service meets reliability standards before real users depend on it. Teams that run reviews launch with fewer surprises.
What Is a Production Readiness Review?
A PRR is a structured checkup that an SRE team and a service team complete together. Think of an airline pre-flight inspection. Pilots and engineers walk through a checklist before every flight, because a few minutes of checking prevents serious trouble in the air. A PRR performs the same job for a new service or a major change.
When to Run a Review
- Before the first public launch of a service
- Before a large change in architecture or traffic
- When a service moves to a new owner
- On a yearly schedule for critical services
Review Areas
| Area | Key Questions |
|---|---|
| Objectives | Do clear SLIs and SLOs exist, and does the business agree with them? |
| Monitoring | Do dashboards and alerts cover the golden signals? |
| On-call | Does a rotation exist, with runbooks for every alert? |
| Deployment | Can the team release safely and roll back fast? |
| Capacity | Has load testing confirmed the expected peak? |
| Dependencies | Does the service survive when a dependency fails? |
| Data | Do tested backups and recovery targets exist? |
| Security | Are access, secrets, and updates under control? |
| Documentation | Can a new engineer understand the service quickly? |
The Review Process
[Request Review] → [Service Team Fills Checklist] → [SRE Review Meeting]
↓
[Launch Approved] ← [Fix Gaps and Re-Check] ← [Findings and Action List]
- The service team requests a review and shares an architecture diagram.
- The team completes a checklist with evidence, such as links to dashboards.
- SREs read the answers and ask questions.
- Both groups meet and rate each area.
- The group records actions with owners and dates.
- The team closes critical gaps before launch.
A Simple Scorecard
| Rating | Meaning |
|---|---|
| Green | Meets the standard |
| Yellow | Gap exists, plan and date agreed |
| Red | Blocks launch until fixed |
Red items stop the launch. Yellow items need an owner and a due date. A visible scorecard keeps the conversation fair and factual.
Example: New Notification Service
A team plans to launch a notification service next month. The review finds three issues. Alerts exist, yet no runbook describes the response. Load testing covered half of the expected peak. The queue has no limit and could fill the disk. The team writes runbooks, repeats the load test at full peak, and adds a queue cap. A second check turns every area green, and the launch proceeds with confidence.
Making Reviews Helpful
Partnership
Approach the review as help, never as a trial. The goal is a strong launch that both teams own.
Evidence
Ask for links and screenshots. A claim such as "we have alerts" becomes real once the team shows the alert rule.
Proportion
Match review depth to risk. A small internal tool needs a short checklist. A payment system deserves a deep review.
After Launch
Revisit the findings after 30 and 90 days. Compare real traffic and incidents with the review assumptions. Update the checklist with lessons from each launch, so the process improves over time.
Common Mistakes
- Running the review the day before launch, when changes cost too much.
- Accepting answers with no evidence.
- Using one long checklist for every service.
- Skipping follow-up on yellow items.
Key Takeaways
A PRR checks objectives, monitoring, on-call readiness, deployment, capacity, data protection, and security before launch. Start early, require evidence, and track every action to completion.