QUICK ANSWER
What should a production readiness checklist include?
A typical software-service production readiness review evaluates which ownership, SLO and observability, capacity, dependency, data, security and privacy, recovery, on-call, runbook, rollout, rollback, and post-release gates apply to one candidate and environment. Record current evidence, owners, state, and rationale for each applicable or not-applicable gate. The checklist does not execute deployment or replace specialist approval.
A production readiness checklist is the decision ledger for whether one software-service candidate has enough bounded evidence for a release decision in one target environment. It assembles inputs from reliability, security, data, quality, release, and support owners; exposes blockers and bounded exceptions; and gives a named human authority the inputs for a go, reduced-scope, or hold decision.
The downloadable pack includes a blank validator-clean template, a safe fictional completed review, editable Markdown, CSV evidence views, a closed JSON Schema, and dependency-free mutation tests. It records readiness and the decision boundary. It does not deploy software, run a migration, approve security or privacy, execute rollback, replace an incident plan or runbook, or prove that a service will be reliable.
Build the review around one service candidate
Make each readiness claim version-bound, evidence-backed, and owned. Keep specialist decisions and operational execution in their accountable systems.
Freeze the service, candidate, environment, and authority
Record one service ID, release or build reference, target environment, criticality, review revision, as-of time, service owner, release owner, decision authority, and in-scope and excluded change. Google SRE describes production readiness as service-specific and concerned with production responsibility; a generic checked box is not evidence for another candidate or environment.
Sources: [readiness-pack], [google-sre-prr], [aws-orr]
Connect SLOs, observability, capacity, and dependencies
Reference the service objectives and indicators, user-visible failure signals, dashboards, alerts, capacity basis, load or performance evidence, quotas, dependency owners, failure behavior, and current dependency versions. Keep observed facts, limits, dates, and expiry visible instead of turning one successful test into a universal readiness claim.
Sources: [readiness-pack], [google-sre-prr], [google-sre-launches], [aws-orr]
Route data, migration, security, and privacy evidence
Record organization- and specialist-defined data classification, schema or migration references, compatibility and reconciliation evidence, backup and restore observations, access boundaries, privacy review, and qualified owners where applicable. NIST SSDF and OWASP ASVS support secure-development practices and technical security verification; they do not establish migration correctness, privacy approval, or recoverability for a service.
Sources: [readiness-pack], [nist-ssdf], [owasp-asvs]
Review failure, recovery, on-call, and runbook coverage
Identify credible failure modes, detection signals, stop conditions, recovery and rollback references, on-call primary and backup roles, escalation, support handoff, and exercised runbook evidence. The review checks whether bounded evidence exists; the incident plan owns coordination and authority, while runbooks and recovery plans own executable procedures.
Sources: [readiness-pack], [google-sre-prr], [aws-orr], [azure-safe-deployments]
Derive blockers, exceptions, and the human decision
In this example pack, a required gate is ready only with current candidate-bound evidence and ready dependencies. A blocker needs a next action. A requested exception needs a risk owner, independent approver, finite expiry, compensating control, evidence, and named scope. This portable model deliberately keeps security, privacy, data integrity, and recovery gates non-waivable.
Sources: [readiness-pack]
Plan progressive exposure and post-release verification
Reference the rollout plan, health gates, pause and rollback triggers, last known good state, observation owner, verification window, signals, success condition, and failure action. Azure guidance emphasizes progressive exposure, health models, halt conditions, and recovery. The checklist records the human-approved boundary; the deployment system performs the change and the post-release record captures observed results.
Sources: [readiness-pack], [azure-safe-deployments], [google-sre-launches], [rfc-2606]
The production readiness owner boundary
Use this owner for a software-service pre-production evidence review tied to one candidate and environment. Adjacent records remain authoritative for their own jobs.
Included
- Service, candidate, target environment, criticality, revision, as-of date, decision authority, service owner, release owner, on-call primary and backup, and review scope
- Service ownership, SLO and observability, capacity and performance, dependencies, data and migrations, security and privacy, failure and recovery, on-call and runbooks, rollout and rollback, and post-release verification gates
- Candidate-bound evidence, authoritative references or expected and observed results as appropriate, checked and expiry times, gate dependencies, blockers, next actions, accepted risks, bounded exceptions, and derived decision consistency
- A validator-clean blank template, safe fictional completed review, editable Markdown, CSV projections, closed schema, mutation tests, and deterministic archive
Not included
- Audience, positioning, pricing, channels, customer-facing support enablement, market introduction, adoption, and commercial launch coordination owned by the product launch checklist
- Website content, URLs, DNS, redirects, consent, analytics, SEO, responsive behavior, and website production smoke owned by the website launch checklist
- Line-level change inspection, maintainability review, and reviewer findings owned by the code review checklist
- Test scope, environments, suites, cases, observations, defects, and production-smoke sequence owned by the technical test plan and test reports
- Deployment or cutover commands, migration execution, feature-flag changes, traffic shifts, provider writes, rollback execution, or a deployment checklist procedure
- Incident roles, severity, communications, activation, evidence handling, and recovery authority owned by the incident response plan
- Executable operational steps owned by runbooks, detailed recovery procedures owned by disaster recovery plans, or audience-facing shipped facts owned by release notes
- Manufacturing production review, facility or supply-chain readiness, generic go-live marketing, automatic approval, specialist certification, or guaranteed reliability and release outcomes
DOWNLOADABLE RESOURCE
Download the production readiness checklist pack
Start with the blank template, compare the completed fictional review, inspect the CSV evidence views, and run the dependency-free checks before adapting the gate policy to a real service.
Production readiness checklist pack
A candidate-bound service-readiness record with ten evidence categories, owners, blockers, exceptions, a human decision boundary, and post-release verification.
Format: Markdown, CSV, JSON, JSON Schema, validator, tests, and reproducible ZIP archive
Locally reproduced August 1, 2026. SHA-256: 4f7088e9909ba83fbe13f004ec14e86edaf159de3475e5d5cf9e0a32ba190f11
Included
- Validator-clean blank JSON template and editable Markdown checklist for all ten production-readiness categories
- Completed safe fictional service review with owners, evidence, gates, blockers, exceptions, decision state, and post-release checks
- Readiness-gate, evidence, exception, and post-release CSV projections generated from the canonical record
- Recursively closed Draft 2020-12 schema and dependency-free semantic validator with adversarial security and state mutations
- Page-owned source allowlist, exact public and archive byte parity, fixed timestamps, artifact lock, cross-time-zone rebuilds, and clean-extraction verification
Verification boundary
Validated the blank and fictional records, projections, references, evidence expiry, gate dependencies, exception rules, decision derivation, false boundaries, archive allowlist, source-to-public parity, clean extraction, and identical rebuild bytes across process time zones.
Three review shapes for different service risks
Keep the same candidate, evidence, ownership, and authority model while adapting check depth to the service, change, and blast radius.
New API service entering production
Use when: A new externally reachable service needs its first production ownership, dependency, observability, capacity, security, recovery, and support review.
Evaluate every category, justify every not-applicable decision, define distinct service, release, decision, and on-call responsibilities, and bind evidence to the exact build, configuration, and target environment.
Structure
- Architecture and operation: ownership, SLOs, user-visible signals, capacity, quotas, dependencies, on-call backup, escalation, and current runbook references
- Release safety: security and privacy evidence, failure modes, recovery exercise, progressive exposure, rollback triggers, decision authority, and scheduled post-release checks
Watch for: A completed review does not prove the service is secure, private, available, performant, supportable, or safe under every workload and failure mode.
Sources: [readiness-pack], [google-sre-prr], [aws-orr], [owasp-asvs]
Stateful release with a migration
Use when: A candidate changes stored data, schema, compatibility, or migration behavior and recovery may differ from ordinary code rollback.
Keep data integrity and recovery non-waivable, link rehearsal and reconciliation evidence, separate forward-fix from rollback assumptions, and hold the decision when restore or compatibility evidence is missing.
Structure
- Data boundary: source and destination versions, compatibility window, migration reference, reconciliation evidence, backup observation, restore observation, and owners
- Decision boundary: blocker, next action, no-go derivation, rollout hold, last known good state, recovery reference, and post-release verification window
Watch for: The checklist does not run a migration, authenticate a backup, prove restoration, establish data completeness, or authorize a destructive production change.
Sources: [readiness-pack], [azure-safe-deployments], [nist-ssdf], [aws-orr]
Bounded worker or dependency expansion
Use when: An existing service adds a worker, queue consumer, region, provider, or dependency with limited user-facing surface but new operational failure modes.
Focus on dependency contracts, retry and overload behavior, capacity, queue health, stop signals, on-call ownership, failure isolation, progressive exposure, and expiry-bound exception handling.
Structure
- Dependency and load evidence: version, owner, limits, retry behavior, saturation signal, alert, isolation, capacity basis, and expected failure response
- Controlled exposure: bounded scope, ready dependencies, approved finite exception where allowed, pause trigger, rollback reference, and observation owner
Watch for: A small code diff or background execution path can still create overload, duplicate work, data corruption, hidden coupling, or an incident outside the reviewed scope.
Sources: [readiness-pack], [google-sre-launches], [google-sre-prr], [json-schema-2020-12], [rfc-2606]
Derive the review state without automatic approval
The validator can reject contradictions and derive whether a record is ready for human decision. Only the named accountable authority can approve the represented release scope.
A required gate lacks current candidate-bound evidence, an owner, an expected and observed result, or a ready dependency.
Choose: Keep the review not ready, name the blocker and next action, and refresh the evidence for the exact candidate and environment. For observed checks, preserve expected and observed results; for other evidence kinds, preserve the authoritative reference and review result.
Tradeoff: The release waits or narrows, but a stale or unrelated artifact is not converted into a readiness fact.
Security, privacy, data integrity, migration recovery, or service recovery evidence is failed, expired, missing, or requested as an exception.
Choose: In this portable model, keep the gate blocked and route it to the qualified owner. Do not use the example exception mechanism to waive the deliberately non-waivable gate.
Tradeoff: The decision remains on hold, but specialist evidence and recovery boundaries stay accountable.
A waivable gate has a bounded residual risk with an independent owner and approver, compensating control, evidence, finite expiry, and review trigger.
Choose: Under this pack policy, record the approved exception against that gate and candidate, expose it in the decision, and schedule its closure or re-review.
Tradeoff: The release may proceed within a narrower risk boundary, but the exception remains visible and cannot silently become permanent policy.
Every required gate is ready or has a valid approved exception, but rollout health, rollback, on-call backup, or post-release verification is missing.
Choose: Keep the record ready for review but withhold a go-for-scope decision until the release observation and recovery boundary is complete.
Tradeoff: Preparation continues, but the team does not enter production without a way to detect, stop, recover, and verify the change.
From readiness contract to operational view
Build the internal review surface around accountable evidence
When candidate IDs, owners, gate states, evidence references, exceptions, and decision rules are approved, use Playcode to prototype the bounded workflow without moving credentials or production control into the checklist.
Explore internal toolsKeep deployment authority, provider access, sensitive evidence, incident control, migrations, and recovery execution in their accountable systems.
Coordinate the separate product launchProduction readiness owns the service evidence gate; product launch owns the market introduction.
What the checklist cannot prove
A closed record can expose missing evidence, inconsistent states, unsafe references, and ownership gaps. It cannot authenticate the inputs or operate the production system.
- The fictional example is a structural demonstration, not a universal gate policy, SLO, capacity target, exception standard, rollout pattern, regulated control set, or reliability benchmark.
- Evidence marked verified is still a recorded assertion. The validator cannot authenticate a dashboard, test, review, backup, restore, approval, provider response, runbook exercise, or production observation.
- The checklist does not deploy or roll back code, shift traffic, change configuration, execute a migration, contact providers, run commands, open incidents, or authorize another system to do so.
- OWASP ASVS and NIST SSDF can inform security requirements and verification coverage. Referencing them does not certify security, privacy, compliance, or fitness for a specific risk context.
- A go-for-named-scope decision is limited to the represented candidate, environment, evidence snapshot, exceptions, and authority. Any material change can invalidate affected gates.
- Post-release verification records bounded observations. A healthy window does not prove future reliability, complete detection, absence of latent defects, or success under every load and dependency state.
- This ordinary informational article does not grant AI signup credits. Linked product pages follow their own current eligibility rules.
Primary reliability, operations, and security sources
These sources support the review categories and boundaries. They do not endorse this template or make its fictional evidence authoritative.
[readiness-pack] Playcode:Production readiness fictional review
Checked August 1, 2026. Supports: The original page-owned record model, safe fictional review, gate categories, evidence states, exceptions, decision derivation, post-release checks, false boundaries, and deterministic tests. Public availability remains unverified until deployment.
[google-sre-prr] Google SRE:The Evolving SRE Engagement Model
Checked August 1, 2026. Supports: Production Readiness Reviews tied to service-specific reliability needs, production responsibility, architecture and dependencies, monitoring, capacity, change management, performance, operational controls, and service-owner preparation.
[google-sre-launches] Google SRE:Reliable Product Launches at Scale
Checked August 1, 2026. Supports: Curated concrete launch questions and actions, persistent-data and capacity checks, failure modes, verification needs, risk-scaled review, launch abort mechanisms, and continuous checklist maintenance. Google-specific processes are not universal requirements.
[aws-orr] Amazon Web Services:Operational Readiness Reviews
Checked August 1, 2026. Supports: A current operational-readiness review program based on curated questions, incident learning, workload-specific risks, self-assessment, action tracking, and repeated review across the service lifecycle.
[azure-safe-deployments] Microsoft Azure Well-Architected Framework:Architecture strategies for safe deployment practices
Checked August 1, 2026. Supports: Current guidance on progressive exposure, health models, issue detection, halt conditions, recovery, data-change caution, approval gates, and post-deployment learning. Provider-specific examples do not prescribe another workload.
[nist-ssdf] US National Institute of Standards and Technology:Secure Software Development Framework Version 1.1
Checked August 1, 2026. Supports: A high-level secure-development framework intended to integrate security practices into the software lifecycle and reduce released vulnerabilities. It does not certify a specific candidate.
[owasp-asvs] OWASP Foundation:Application Security Verification Standard
Checked August 1, 2026. Supports: An open standard providing a basis for web-application security requirements and technical-control verification. Select the current version and rigor appropriate to the real application and risk context.
[json-schema-2020-12] JSON Schema:JSON Schema Draft 2020-12
Checked August 1, 2026. Supports: The schema dialect declared by the downloadable closed JSON Schema.
[rfc-2606] RFC Editor:RFC 2606 Reserved Top Level DNS Names
Checked August 1, 2026. Supports: Use of reserved .test domains for fictional evidence and operational references.
Production readiness checklist questions
What is a production readiness checklist?
It is a candidate- and environment-bound review ledger for whether a software service has enough current, owned evidence for an accountable human to make a release decision. It covers operation, reliability, dependencies, data, security, recovery, support, rollout, exceptions, and post-release verification without executing the change.
Is production readiness the same as a product launch checklist?
No. Production readiness owns the evidence and decision record for whether one software-service candidate meets the organization’s named technical readiness criteria, including technical on-call and operational escalation. The product launch checklist owns audience, positioning, pricing, channels, customer-facing support enablement, and market introduction. A product launch may depend on a production-readiness decision without absorbing its evidence.
Is this the same as a deployment checklist?
No. A deployment checklist or runbook owns the ordered procedure, commands, environment changes, traffic shifts, validation steps, and rollback execution. This readiness record asks whether those procedures, owners, evidence, health gates, stop conditions, and recovery references are ready before execution.
How is this different from a test plan or code review checklist?
The test plan owns release-specific test scope, environments, cases, runs, observations, defects, and smoke sequence. Code review owns inspection of the change and its findings. Production readiness consumes bounded evidence from both, adds operational and specialist gates, and records the human release-decision boundary.
How is this different from a website launch checklist and release notes?
The website launch checklist owns site-specific content, URLs, DNS, redirects, consent, analytics, SEO, responsive checks, accessibility, and production smoke. Release notes own audience-facing facts about an already shipped version, including impact, compatibility, actions, and known limits. Production readiness consumes bounded evidence before the technical release decision.
Does a ready checklist replace an incident response plan or runbook?
No. The incident response plan owns activation, severity, roles, communications, evidence handling, and recovery authority. Runbooks own executable procedures with prerequisites, expected observations, stop conditions, escalation, and recovery. The readiness checklist records whether the required owners and reviewed references exist for the candidate.
Can a production-readiness exception approve a security or recovery gap?
Not in this portable model. Security, privacy, data integrity, migration recovery, and service recovery gates remain non-waivable. Other bounded exceptions require an independent owner and approver, compensating control, evidence, candidate scope, finite expiry, and review trigger. Real policy and qualified authorities remain accountable.
Who makes the final production decision?
The named human decision authority for the represented service, candidate, environment, and scope. The validator can derive blockers, expired evidence, invalid exceptions, and a ready-for-decision state, but it cannot authenticate evidence, grant authority, certify specialists’ work, or approve and execute a deployment.
Prototype the review workflow
Turn reviewed readiness fields into a working internal tool
Describe the evidence views, owner roles, gate dependencies, exception states, and decision audit trail you need, then inspect the generated implementation before connecting real systems.
Build an internal toolThis ordinary informational article does not grant AI signup credits. Current product eligibility and limits apply.