Production Readiness Review Checklist
A production readiness checklist for launching a new service: ownership, monitoring, alerts, capacity, security, backups and runbooks, reviewed before launch.
- Typical schedule per new service
- The checklist 5 sections, 22 items
- Variables
{{service}}
Use this checklist before a new service, a major rewrite or a newly acquired system starts taking real production traffic. It asks a simple question: if this breaks at night, will we know, and can someone who did not build it fix it? Small teams can run the whole review in one meeting. Larger launches can spread it over a few weeks, with the run open until every item is done or consciously waived.
Who owns it
The team that builds the service owns the run and does the work. A reviewer from outside the team, such as an experienced engineer or the person who will be on call for it, checks the answers and signs off. The point is a second pair of eyes, not a gate run by a separate department.
Common pitfalls
- Reviewing too late. A review the day before launch can only say yes. Start it when the design is stable, so there is time to add alerts, load tests and runbooks.
- Dashboards instead of alerts. Nobody watches a dashboard at night. Check that the important failure modes page someone.
- Ownership by a person, not a team. If the only owner leaves or goes on holiday, the service is orphaned. Name a team and an on-call rotation.
- Waivers that become permanent. It is fine to launch with gaps, but each waived item needs a ticket and a date.
Keep each review in Runbook as a run per service. Later, the audit trail shows what was checked at launch and who signed off.
The checklist: Production readiness review: {{service}}
Ownership
-
Owning team and on-call rotation for
{{service}}named -
Service listed in the service catalogue or inventory with links to code, dashboards and runbooks
-
Upstream and downstream dependencies listed, and their owners informed of the launch
Observability
-
Key metrics collected: request rate, error rate, latency and saturation
-
Alerts defined for user-facing failure, routed to the on-call rotation and tested
Alert on symptoms users feel, such as errors and slowness, rather than on every internal metric.
-
Logs are structured, searchable and free of secrets and unnecessary personal data
-
Service level objectives defined optional
-
Health check endpoint reflects real readiness, including critical dependencies
Reliability and capacity
-
Load test or capacity estimate done for expected peak traffic, with headroom
-
No single points of failure, or each one accepted in writing
-
Timeouts, retries with backoff and limits set on calls to dependencies
-
Graceful behaviour checked when a dependency is slow or down
Security and data
-
Secrets stored in a secret manager, not in code or images
-
Authentication and authorisation reviewed for every endpoint
-
Dependencies scanned for known vulnerabilities
-
Personal data identified and handled according to your privacy policy optional
-
Backups configured and one restore tested for every data store
Operations
-
Deployment is automated and a rollback has been tested
-
Runbook written for the most likely failures and how to mitigate them
-
On-call engineers walked through the service and its runbook
-
Launch plan agreed: date, gradual rollout or feature flag, and who watches it
-
Waived items ticketed with owner and due date, and the review signed off
Checklist as Markdown
Frequently asked questions
What is a production readiness review?
A production readiness review is a structured check, before launch, that a service can be run reliably in production. It covers ownership, monitoring, alerting, capacity, security, backups and operational documentation. The idea is popular in SRE practice and works just as well in small teams.
What is the difference between operational readiness and production readiness?
The terms are often used interchangeably. Operational readiness sometimes puts more weight on the people side, such as support training, on-call staffing and processes. Production readiness tends to focus on the technical side. A practical review covers both.
Do we need a readiness review for every small service?
Not a full one. For small internal tools, mark the heavier items as optional or waive them with a note. Keep the core items, though: an owner, alerts, backups and a rollback. Those are the ones people regret skipping.
Updated