Production Readiness Review Checklist Template

Owned by the service owner, with the PRR reviewer. Enter the planned launch date on the first task: every due date counts back from it in working days, and the launch and follow-up tasks count forward. Agree what the review covers and the standard the service is checked against before the analysis starts.

• Set up the review: the service, the launch date and the people — the service under review, what is new or changing, the day it is planned to take production traffic, whether it is a new service or a significant change, whether it is critical, and the service owner, PRR reviewer, on-call lead, security reviewer, readiness approver and support lead; later tasks are assigned from these fields
• Agree the scope and the readiness standard — what the review covers and leaves out, the standard or checklist the service is checked against, the areas that matter most for this service, and what has to be true for the readiness approver to say Ready
• Book the review sessions and the readiness meeting — short, regular sessions between the service owner and the reviewer to work through each area, and the readiness meeting with the approver before the launch
• Share the design documents and the current state — the design document, an architecture diagram, the code repository, existing dashboards and alerts, known gaps and the open tickets the team already has for the service
• Register the service in your service catalogue — the service name, owning team, tier and repository, with the on-call rotation and the runbooks added once Phase 4 sets them up, so people can find who owns it once it is live
• Review recent incidents and postmortems for the service — the incidents of the last few months, their postmortems and whether the follow-up actions were done, to see what emergency response the service has needed so far

The reviewer learns how the service works and where it can fail. Walk through the request flows, list every dependency and what the service does when each one is slow or down, record the data the service holds, and look for single points of failure.

• Walk through the architecture and request flows — how a request moves through the service, where data is stored, what runs in each region or zone, and anything batch or scheduled that shares the same resources
• List every dependency and what happens when each one fails — each service, database, queue and third party the service calls, the team that owns it, whether the service can work without it, and the timeout and retry it uses
• Record the data the service stores and who can reach it — each data store, what it holds, how long it is kept, who can read it, and whether any of it is personal data
• Check whether a data protection impact assessment is needed — ask your data protection lead whether the processing needs a data protection impact assessment before launch, and record the answer
• Check that one bad change cannot break too much of the system — whether the design limits what one bad change can break: separate zones, regions or cells, and no global setting or shared component that every instance reads at once; the staged rollout itself is checked in Phase 7
• Check for single points of failure — single instances, a single zone or region, one database without a replica, a shared credential or a manual step only one person can do
• Check that configuration changes are versioned and reviewed — configuration and feature flags kept in version control, reviewed like code, rolled out in stages and easy to revert

The service needs to show what its users experience and to wake someone up only when that is at risk. Agree the indicators and objectives, then check that errors are logged and every user-visible failure is alerted on. The Monitoring & Alerting Setup Checklist covers building the monitoring itself.

• Define the SLIs that show what users experience — the service level indicators for the requests users care about, such as the share of successful requests and the share served fast enough, and where each one is measured
• Set the SLOs and the error budget — a target and a time window for each SLI, the error budget that leaves, and who agreed the targets
• Agree an error budget policy with the product owner — what the team does when the error budget is spent, such as pausing feature releases to work on reliability, and who decides
• Check that errors reach central logging — every error and every condition that gives users a degraded response or a failure is logged where the on-call engineer can search it
• Check that every user-visible failure is monitored and alerted — an alert for each SLO at risk, routed to the on-call rotation, with each alert tested so you know it fires
• Check the dashboards cover every SLO — a dashboard the on-call engineer opens first, showing each SLI against its SLO, the traffic and the state of the main dependencies

Owned by the on-call lead. Before launch, the people who will carry the pager need a runbook for every alert, a rotation with an escalation path, the access to act and the training to understand the service.

• Write a runbook for every alert — what the alert means, how to check the impact, the first steps to take, how to roll back or fail over, and who to escalate to
• Set up the on-call rotation and the escalation path — who is on call and when, the hours the rotation covers, the second level to escalate to and the owners of the main dependencies
• Confirm round-the-clock cover for a critical service — the rotation covers every hour of every day, response times are agreed for a page, and there are enough people on it to take time off
• Give the on-call engineers the access they need — access to the dashboards, logs, deployment tool and runbooks, and the rights to roll back, restart or scale the service, checked by someone on the rotation
• Train the on-call engineers on the service — a design overview, a walk through the main request flows, how it runs in production and a hands-on exercise, led by the service team

Show the service holds the load expected at launch and fails safely when something it depends on does not. Forecast the load, test above it, then break dependencies on purpose in a test environment and watch what users would see.

• Forecast the launch load and the growth after it — the traffic expected at launch and over the following months, the peak hour, and what that needs in compute, storage and connections
• Check quotas, limits and autoscaling — cloud quotas, connection limits, rate limits on the dependencies and autoscaling settings, raised before launch where the forecast needs more
• Run a load test at the forecast peak and above it — a test at the forecast peak and at a margin above it, recording the latency, errors and the first part to give way
• Run failure tests on each critical dependency — in a test environment, make each dependency slow or unavailable in turn and record what the service and its users see
• Check that the service degrades gracefully — timeouts on every call, retries with backoff and a limit, load shedding when overloaded, and a reduced service rather than a full outage where the design allows it
• Run a game day with the on-call rotation — a planned exercise where the on-call engineers handle a simulated failure using the runbooks and dashboards, with what slowed them down written up

The security reviewer checks the service and the way it handles secrets, and the team proves the data can be restored. This template asks for a timed restore from a real backup, not only a backup that reports success.

• Complete the security review — a threat model, authentication and authorisation on every endpoint, input handling, dependencies scanned for known vulnerabilities and network access limited to what the service needs
• Check secrets, keys and certificates — secrets kept in a secret store and not in code or configuration, keys rotated, and certificate expiry dates watched with an alert
• Fix or accept each security finding — each finding fixed before launch, or accepted by the security reviewer with a reason and a date to fix it
• Set up backups for every data store — how often each store is backed up, where the copies are kept, how long they are kept and who is alerted when a backup fails
• Restore a backup and time it — restore from a real backup into a separate environment, check the data, and record how long it took against the recovery time the service needs
• Run a disaster recovery failover test — fail the service over to its second zone or region, measure the time to recover and the data lost, then fail back

Prove the way changes reach production and the way back, agree how the launch itself will run, and hand the service over to support with the documents they need.

• Check the deployment pipeline and the staged rollout — every change goes through the pipeline with tests, reaches a small share of traffic first, and is watched before it goes further
• Test the rollback — roll a change back in a test environment, including any database change, and record how long it took
• Agree the launch plan and the criteria to stop it — how traffic reaches the service on launch day, in what steps, what is watched at each step, and the SLI levels that mean stop or roll back
• Write the service overview — what the service does, who owns it, its dependencies, its SLOs, where the dashboards and runbooks are, and how to reach the team
• Hand over to the support team — what the service does for customers, known issues and workarounds, what support can answer and how to raise an incident with the on-call engineer
• Agree who owns what after launch — who carries the pager, who fixes bugs, who owns the SLOs, and for how long the building team stays on hand to back up the on-call engineers

The reviewer brings every open finding to the readiness meeting, and the readiness approver alone records the decision. The checklist halts at the decision: nothing in the launch phase can be completed until it is done. Not ready hides the launch phase and adds a task before the decision to fix what stops the launch.

• List the open findings with an owner and a date — every finding from the review that is still open, how serious it is, who owns it, and whether it must be fixed before launch or can wait
• Hold the readiness review meeting — the reviewer walks the approver, the service owner, the on-call lead, security and support through each area and the open findings
• Not ready: fix what stops the launch — fix each finding the approver named, agree a new launch date if it has to move, then ask the approver for a new decision
• Record the readiness decision — the readiness approver decides Ready, Ready with conditions or Not ready, with the reasons and any conditions; on Not ready, leave this task open until a new decision is made

Applies only when the readiness decision is Ready or Ready with conditions: Not ready hides this phase until the decision changes. Launch in the agreed steps, hand the pager to the rotation, then check the SLOs and alerts against real traffic and hold a follow-up review.

• Brief the on-call engineer and support for launch day — the launch steps, the stop criteria, who is watching which dashboard and how to reach the service team during the launch
• Launch in the agreed steps and watch the SLIs — send traffic to the service in the steps agreed, check the SLIs at each step against the stop criteria, and record any step that was paused or rolled back
• Confirm the on-call rotation has taken over — the rotation is paging for the service, the building team knows how long it stays on hand, and the service catalogue shows the live owner
• Check the SLOs and alerts against real traffic — compare the SLIs with the targets over the first two weeks, tune alerts that fired without a real problem or stayed quiet when there was one, and adjust the SLOs if the evidence says so
• Close the conditions from the readiness decision — each condition the approver set, done by its owner by the date agreed, or taken back to the approver
• Hold the follow-up review after launch — the launch, the incidents and pages since, the findings that were left until after launch, and whether the service is meeting its SLOs
• Record what to change in the readiness standard — what this review missed or asked for without need, written back into your standard so the next review is better