Checklist · Cloud and DevOps
Production Readiness Checklist
Opens with creditsA production readiness review you can run before launch, or on a service you just inherited. Each check has a severity and a concrete way to verify it, covering ownership, reliability and capacity, observability and alerting, deployment and rollback, data and recovery, security and incident response.
What you will learn
7 chapters · about 15 min
1Ownership and documentationSomeone has to own the service, and the people paged for it need enough written down to act without its author.4 checks · 2 min
2Reliability and capacityWhether the service meets an agreed target under real load, and fails in contained, predictable ways when something it depends on goes wrong.7 checks · 3 min
- 1SLOs are defined, measured and agreed with stakeholders
- 2The service has been load tested beyond expected peak
- 3No single instance, node or zone failure takes the service down
- 4Every outbound call has a timeout, and deadlines propagate
- 5Retries use exponential backoff with jitter and are limited
- 6The service sheds load and degrades instead of falling over
- 7Readiness and liveness checks reflect real health
7 in this chapterOpen this chapter- Observability and alertingWhether the team will know about a problem before users report it, and have the data to find the cause.6 checks · 2 minOpens with credits
- Deployment and rollbackWhether changes reach production through a repeatable, gradual process, and whether a bad change can be undone in minutes.6 checks · 2 minOpens with credits
- Data, backups and recoveryWhether data survives mistakes and disasters, and whether the team knows how long recovery takes.4 checks · 2 minOpens with credits
- Security basicsThe minimum security posture for a service that handles real users and data. Use a full security checklist for anything sensitive.5 checks · 2 minOpens with credits
- Incident readinessWhether the people on call can respond well, and whether the team learns from each incident.5 checks · 2 minOpens with credits
About this checklist
A production readiness checklist answers one question before a service takes real traffic: when it breaks, and it will, will someone find out quickly, know what to do and be able to fix it without making things worse? Most launch problems are not exotic. A call with no timeout ties up every thread. A retry loop with no backoff turns a small blip into an outage. An alert fires into a channel nobody reads. A backup exists but has never been restored. The fix for each is small if you catch it before launch, and painful if you catch it during an incident.
This checklist follows the shape of Google's SRE launch coordination checklist and the reliability chapters of the SRE book and workbook, adapted for a typical team shipping web services and APIs today. The chapters cover ownership and documentation, reliability and capacity, observability and alerting, deployment and rollback, data and recovery, security basics, and incident readiness.
Every check has a severity. A must is something that will turn an ordinary failure into a long or user-visible outage if it is missing. A should closes a common gap that tends to bite within the first few months. A nice adds depth for services that matter more. Every check also says how to verify it: a command to run, a setting to look at, a drill to perform. A box ticked without that evidence does not count.
Run it as a review with the people who will be on call for the service, not as a form one person fills in. It takes an hour or two for a small service, and the gaps it finds become tickets with owners and dates before the launch goes ahead.
Common questions
What is a production readiness review?
It is a structured check, before a service takes real traffic or when a team takes it over, that it can be operated safely: it has an owner, SLOs, capacity headroom, alerts, a tested rollback, working backups and an on-call rotation. Google’s SRE teams use a launch coordination checklist for the same purpose.
When should we run this checklist?
Before a new service or major feature launches, when a team inherits a service, and again every year or after a big architecture change. Run it as a meeting with the people who will be on call, and turn every gap into a ticket with an owner and a date.
Which checks matter most?
Start with the musts: an owner and runbook, defined SLOs, no single point of failure, timeouts and bounded retries on every call, SLO-based alerts that reach on-call, automated deploys with tested rollback, and restored backups. Missing any of these tends to turn small failures into long outages.
How many incidents per on-call shift is too many?
The SRE book treats 2 incidents per 12-hour shift as the maximum a person can handle well, with the median ideally at 0. More than that means alerts need tuning or the service needs reliability work.
Does a backup count if we have never restored it?
No. Restores fail for ordinary reasons such as missing permissions, lost encryption keys or version mismatches. Only a tested restore, timed and repeated on a schedule, tells you whether you can meet your recovery targets.
Sources (8)
Checked against these, last on 13 October 2026.
- Launch Coordination Checklist, Google SRE Booksre.google/sre-book/launch-checklist/
- Addressing Cascading Failures, Google SRE Booksre.google/sre-book/addressing-cascading-failures/
- Being On-Call, Google SRE Booksre.google/sre-book/being-on-call/
- Postmortem Culture: Learning from Failure, Google SRE Booksre.google/sre-book/postmortem-culture/
- Implementing SLOs, Google SRE Workbooksre.google/workbook/implementing-slos/
- Alerting on SLOs, Google SRE Workbooksre.google/workbook/alerting-on-slos/
- Capabilities: Deployment automation, DORAdora.dev/capabilities/deployment-automation/
- Liveness, Readiness, and Startup Probes, Kubernetes docskubernetes.io/docs/concepts/configuration/liveness-readiness-startup-probes/
Related on Sefism
Picked from the other libraries by shared topics.
Roadmaps
See allCheat sheets
See allBest practices
See all- Kubernetes Best PracticesRun workloads on Kubernetes that schedule well, survive restarts and node drains, and stay locked down: resources, probes, PDBs, Pod Security and RBAC.
- Terraform Best PracticesWrite Terraform that teams can review and change safely: file layout, version pinning, remote state with locking, secrets, modules, refactoring and tests.
- Observability Best PracticesKnow when production is hurting users and why: SLOs, golden signals, metric naming and cardinality, structured logs, OpenTelemetry traces and burn-rate alerts.
Checklists
See all- Incident Response ChecklistPrepare for and handle production incidents: on-call, severity levels, declaring, roles, mitigation, security containment, status updates and blameless postmortems.
- Kubernetes Production ChecklistVerify a workload and its cluster before real traffic: requests and limits, probes, PDBs, spread, Pod Security, RBAC, network policies, secrets, images, autoscaling, upgrades and backups.
- Disaster Recovery ChecklistBackups and DR you can prove: RPO and RTO per system, backup coverage, off-site and immutable copies, restore tests, zone and region choices, runbooks, drills, dependencies and communication.
Project structures
See all- Terraform project structureAn infrastructure repository for a small app on AWS: reusable modules, one folder per environment with its own remote state, pinned providers, tests and security scans, with plan on every pull request and apply from CI. For students who have finished the Terraform tutorials and want to know how a real team lays out the files. The same layout works unchanged with OpenTofu.
- Kubernetes with Helm project structureA Helm chart repository for one app: the chart that
helm creategives you, grown into a tested, versioned package with per-environment values, unit tests, install tests in a kind cluster and releases to an OCI registry. For students who can write a Deployment by hand and want to know how a team organises charts. It is about the repo layout and what each file does, not about cluster design. - Spring Boot project structureA REST API in Java with Spring Boot 4, PostgreSQL, Flyway and Testcontainers, organised by feature the way the Spring docs suggest. It grows from the Initializr scaffold to a service with JWT security, problem-detail errors, MapStruct DTOs, slice and integration tests, CI, containers and observability, and finally Modulith boundaries, contract and load tests. For students who know some Java and want to see how a real service is organised.
Career questions
See all- Do I need Docker and Kubernetes as a junior developer?Docker, yes: learn the basics, because nearly every team uses containers and you will be expected to run the project locally and read a Dockerfile. Kubernetes, mostly no: understand what it does and a few core terms, but deep Kubernetes can wait until your job or a DevOps direction needs it.
- What is platform engineering, and how is it different from DevOps?DevOps is a culture and set of practices: developers and operations sharing responsibility for shipping and running software. Platform engineering is one way to put that into practice at scale: a team builds an internal platform, a paved road of tools and templates, so product teams can ship without becoming infrastructure experts.
- Can I become an SRE or platform engineer straight after graduating?Sometimes, but it is rare, because these roles expect you to have run production systems. The more reliable path is a first job in backend, DevOps or cloud support, where you learn production, then a move into SRE or platform work within a couple of years.
Stuck on something specific?
Writing only gets you so far. If you want an answer to your situation rather than the general case, book a session and we will work through it together. Sessions are free for approved Sefism members, and a few slots open each week.
- 1:1 Mentorship
- Fresh Graduate Mentorship
- Career Guidance
Brand deals, promos and partnerships: tauseeffayyaz@gmail.com