Production Readiness Reviews: A Launch Checklist That Works

Production Readiness Reviews

Most launch-day outages are not caused by exotic bugs. They come from ordinary gaps nobody checked: no alert would have fired, the on-call rotation did not exist yet, a dependency had no timeout, the database had never been restored, the service was load-tested at a tenth of the marketing campaign's traffic. A production readiness review (PRR) is a structured look at a service before it takes real users — or before a major change — to find those gaps while they are still cheap to fix.

A good review is not a form to fill in or a committee to appease. It is a conversation between the people who built the service and people who have operated many others, backed by evidence: dashboards that exist, alerts that have fired in a drill, rollbacks and restores that have actually been rehearsed. Its output is a launch decision with the remaining risks named and owned.

TL;DR

Review operability, not features: ownership, observability, capacity, dependencies, failure modes, rollback, recovery, security, and cost.
Require evidence — links to dashboards, test results, and drill records — rather than yes/no answers.
Scale the review to risk: a full review for critical services, a short checklist for internal tools.
Prefer testing readiness over documenting it: load tests, failure injection, paging drills, rollback and restore rehearsals.
End with a clear outcome: launch, launch with accepted risks (owned and dated), or not yet.
Automate recurring checks with service scorecards so readiness is maintained after launch, not checked once.

Quick Example

A readiness record kept in the service's repository, filled in by the owning team with links to evidence and reviewed before launch:

Every line is either evidence or an explicitly accepted risk with an owner and a date — nothing is "probably fine".

Core Concepts

What a Review Covers

When to Hold One

Before a new service takes production traffic.
Before a major change: new architecture, new region, new data store, or a large dependency swap.
Before an expected traffic event: a marketing launch, a big customer onboarding, a seasonal peak.
When a service moves to a higher criticality tier or is handed to another team.

Tiering

Applying the same heavyweight review to every service makes teams avoid it. Define tiers by business impact and scale the checklist:

Running the Review

Start early. Share the checklist when the design is agreed, not the week before launch, so findings can still change the design.
Owners prepare evidence. The building team fills in the record asynchronously, linking to dashboards, test results, and drill notes.
Reviewers read first. The meeting — an hour is usually enough — focuses on gaps and risks, not on reading the checklist aloud.
Decide. Launch; launch with accepted risks, each with an owner and a revisit date; or not yet, with a short list of blockers.
Follow up. Track action items like any other work, and revisit the service after a month of real traffic.

Reviewers should come from people who operate production — SRE, platform, or senior engineers from other teams. The tone matters: the aim is to help the service succeed, not to collect signatures.

Testing Readiness, Not Just Documenting It

A checklist answered "yes" proves less than a test that was run. The strongest reviews include:

A load test at expected peak with margin, finding the first bottleneck — see Performance Testing.
Failure injection: kill instances, add latency to a dependency, block a hard dependency entirely, and observe — see Chaos Engineering.
A paging drill: trigger a real alert, confirm it reaches the rotation, and have the responder follow the runbook — see On-Call Operations and Incident Command.
A rollback rehearsal in a production-like environment — see Release Rollback and Database Compatibility.
A restore drill that measures real recovery time — see Database Restore Drills and Recovery Targets.

A pre-launch game day combining several of these, with the real on-call team, often finds more problems than the rest of the review.

Automating Readiness

Many checks are mechanical and can run continuously:

The service has a catalog entry with an owner and an on-call schedule.
An SLO is defined, and its alerts route to a real rotation.
Deployments set resource limits, health probes, and multiple replicas.
Backups are enabled; dependency timeouts are configured; tracing and structured logs are present.

Service scorecards in developer portals such as Backstage show these checks for every service, so readiness does not decay after launch — see Platform Engineering. Policy checks in CI can block configurations that fail the basics:

Automation frees the human review to focus on judgment: failure modes, risky dependencies, and whether the team is ready to run what it built.

Best Practices

Keep the Checklist Short and Earned

Every item should exist because its absence once caused an incident or a near miss. Add items when postmortems reveal gaps, and remove items that never change a decision.

Record Accepted Risks With Dates

Some gaps are reasonable to launch with. Name the risk, who accepted it, and when it will be revisited. Undated risk acceptance quietly becomes permanent.

Include Support and Communication

Decide how customers report problems, which status page component the service maps to, and how support learns about incidents. Users experience the whole response, not just the code.

Review Again After Launch

Real traffic reveals what pre-launch estimates missed. A short review after the first month — alert quality, capacity headroom, incidents so far — catches drift before it becomes an outage.

Common Mistakes

Checkbox Theater

Reviewing Too Late

One Size for Everything

No Follow-Through

FAQ

What is a production readiness review?

A structured assessment, before launch or major change, of whether a service can be operated reliably: whether it is observable, has enough capacity, handles dependency failures, can be rolled back and restored, has an owner and on-call rotation, and has documentation for responders.

Who should run the review?

The owning team prepares it; reviewers are people with operational experience — site reliability engineers, platform engineers, or senior engineers from other teams. The owning team remains accountable for the service; reviewers bring perspective and patterns from other incidents.

How long should a review take?

For a well-prepared critical service, a few hours of preparation spread over the build and a one-hour meeting. Most of the time goes into producing evidence — tests, drills, dashboards — which is work the service needs anyway.

Do small teams need formal reviews?

They need the questions, not necessarily the ceremony. A one-page checklist reviewed by someone outside the team before launch catches most of the same gaps. The key items — an alert that works, a rollback that works, a restore that works — matter just as much at small scale.

How is this different from an architecture review?

An architecture review happens early and asks whether the design solves the problem well. A readiness review happens before launch and asks whether the built system can be operated: monitored, scaled, recovered, and supported. Findings from the readiness review often feed back into design, which is another reason to start early.