Production Readiness Review
Boring before it's launched
A PRR is the launch checklist for anything headed to prod: reliability, performance, security, operability, and rollback all proven — with evidence, owners, and a pass/fail verdict humans can actually read.
What you will learn
- Build a PRR checklist across reliability, security, operability, performance
- Require evidence, not vibes, for each item
- Fork a gate with severity-based outcomes
A production readiness review grades a service against the house standards before launch: architecture (multi-AZ/DR, tiers sized), reliability (SLO + error budget defined), security (least-privilege, secrets, scans, compliance evidence), operability (dashboards, alerts-on-SLO, runbooks, on-call rota), performance (load tested, headroom), and rollback (rehearsed strategy + migrations compatible). Each item needs an owner and evidence; the verdict is pass / pass-with-conditions / blocked, with conditions tracked to close.
What is this?
PRR framing: run it at launch and on significant change (new major tier, new data store). Checklist areas: (1) Reliability: multi-AZ/DR posture, backup+restore tested, RTO/RPO written and realistic. (2) Performance & capacity: load-tested peak shape, pools/queues sized, headroom stated. (3) Security & compliance: least-privilege IAM, secrets in vault, images scanned/signed, guardrails hit, compliance evidence. (4) Observability & operability: SLOs + burn alerts, dashboards, runbooks, on-call ownership, deploy/rollback rehearsed. (5) Cost & governance: budget + tags, owner registered. Scoring: each criterion = evidence + owner; the review produces a written verdict alongside the evidence, and conditions (if any) have owners + dates and a follow-up. Culture note: the PRR is a gate the platform (or a release-gate pipeline) can partially enforce (scans, budgets, tags), and partially a human review for judgment (rollback rehearsability, SLO plausibility).
Why do you need it?
- A checklist makes 'ready' concrete and auditable instead of a manager's hunch.
- Evidence + owners means gaps close, not just get argued about.
- Rollback and DR rehearsals catch the failures that code review can't.
- Pass-with-conditions keeps launch momentum while debt is tracked to zero.
Mental model
Launch day discovered to have no fire exits
The building passed inspection before furniture arrived
A PRR certifies the exits before the users move in.
How it works
- Baseline the house standards (SLO, rollback, runbooks, security).
- Run the service through the checklist; each item needs evidence + owner.
- Score for launch: pass / pass-with-conditions / blocked.
- Track conditions to close; re-review on significant change.
The production readiness loop.
In production
- A new search service launches only after the PRR shows load-tested peak, SLO alert wired, and a rehearsed rollback.
- A data-store migration triggers a mini-PRR: new DR test, backup restore drill, migration runbook.
- The platform blocks deploy if scans or budgets are red — the PRR card auto-verifies those.
Best practices
- Evidence for every line: a link, not a promise.
- Rollback and restore are rehearsed, not assumed.
- Conditions have owners + dates and get tracked to zero.
- Re-run PRR on major change, not just at launch.
Common mistakes
- A PRR that's a rubber stamp because nobody looks at evidence.
- Rehearsing rollback 'in theory' — the drill is the evidence.
- SLOs written but no burn alert wired, so the budget is fiction.
Debugging tips
- PRR flags 'no runbook' for an alert you triggered → the alert is the requirement's test; fix the doc before the pager finds out.
- Conditions pile up unowned → block the next change until conditions close; debt auto-pays either way.
Interview checkpoint
Hands-on lab
- Build the PRR checklist for a real or imagined service
- Score each item with evidence + owner
- Write the verdict and the tracked conditions
Run a Production Readiness Review
40 min · advanced
Quick quiz
Pass-with-conditions means...