Production-ready guide covering production readiness review checklist design with implementation patterns, code examples, and anti-patterns for enterprise engineering teams.
A production readiness review checklist is a structured set of criteria and verification steps used to evaluate whether a system or change is ready for deployment to production. This process applies when introducing new services, modifying existing systems, or promoting changes through release gates. The checklist ensures that all necessary safety, reliability, and operational considerations are addressed before code reaches production.
The checklist serves as a decision matrix for stakeholders to assess whether a system meets minimum requirements for operational stability. It is not a quality gate but a tool to surface potential failure points early in the deployment lifecycle.
Checklists should be defined at the beginning of a project or change, and they must include both technical and operational criteria. They are most effective when tied directly to specific observable behaviors rather than abstract concepts.
A checklist must have clearly specified acceptance criteria for each item. For example, instead of "monitoring is sufficient," use "all critical paths must have at least one alert with a 5-minute resolution time."
Each checklist item should specify:
Verification can include:
For example, a checklist item might be: "Verify that all critical services have health checks exposed on port 8080 and return HTTP 200 within 100ms." The verification would involve running curl -f http://localhost:8080/health and checking response time.
Ensure that all required dependencies are declared and available. For services using Kubernetes, verify the deployment manifest includes correct image references and resource limits.
apiVersion: apps/v1
kind: Deployment
metadata:
name: example-app
spec:
replicas: 3
selector:
matchLabels:
app: example-app
template:
metadata:
labels:
app: example-app
spec:
containers:
- name: app
image: myregistry.com/example-app:v1.2.3
ports:
- containerPort: 8080
resources:
requests:
memory: "64Mi"
cpu: "250m"
limits:
memory: "128Mi"
cpu: "500m"Every container must define memory and CPU requests and limits. Omitting these can lead to pod evictions or resource starvation.
Services must expose liveness and readiness probes. The readiness probe should ensure the service is not accepting traffic until it has fully initialized.
livenessProbe:
httpGet:
path: /healthz
port: 8080
initialDelaySeconds: 30
periodSeconds: 10
readinessProbe:
httpGet:
path: /ready
port: 8080
initialDelaySeconds: 5
periodSeconds: 5All services must log to stdout/stderr. Logs should include timestamps, request IDs, and structured fields for correlation.
Check that metrics are exposed on a standard port (e.g., 9090) and are compatible with Prometheus scraping.
curl http://localhost:9090/metricsEach service must define rollback procedures. This includes how to revert to a previous version, how to restore data, and who has authority to execute rollbacks.
Services must return appropriate HTTP status codes for errors. A 500 error should be logged with a detailed error message.
A checklist should be built iteratively, starting with a core set of items and expanding based on the specific system being reviewed.
Begin by identifying all relevant stakeholders: developers, SREs, platform engineers, and operations teams. Each stakeholder group contributes items that reflect their domain expertise.
Items must be written in a way that allows verification without ambiguity. For example, instead of "configuration is correct," use "all configuration values are validated against the schema defined in the repository."
Each checklist item should include:
Checklists should be stored in version-controlled repositories, ideally as markdown files with clear section headings.
Each item should be numbered or tagged for easy reference and tracking.
A checklist is not static. It must evolve with the system and team experience.
Changes to a checklist should be tracked in version control with clear commit messages explaining why an item was added or modified.
Checklists should be reviewed quarterly or after significant incidents.
Items that do not clearly specify verification steps can silently pass. For example, "service is scalable" might pass without verifying that the service actually scales in response to load.
A checklist item like "code quality is good" can pass even if there are no tests or linters running. This leads to production issues that could have been caught during review.
Teams may verify a few items but skip others, especially under time pressure. This creates false confidence in readiness.
Ownership of checklist items should be explicitly assigned. This includes both who verifies each item and who approves the overall readiness.
Checklist completion should be part of the deployment workflow. It is not sufficient to just document the checklist; it must be enforced through automation or manual sign-off.
Checklists are most effective when integrated into deployment processes. A system can be configured to require a checklist approval before promoting changes to production environments.
Automated checks can be written to verify items like:
Checklists must be well-documented and easily accessible. They should be linked from relevant project documentation and shared with all teams involved in the deployment process.
They should include examples of what a pass or fail looks like, along with common failure scenarios and how to fix them.
After deployment, each checklist item should be reviewed for accuracy and completeness. This includes:
This feedback loop improves the checklist over time.
Validation should occur both before and after deployment. Before deployment, all items must be verified. After deployment, the checklist should be used to verify that the system behaves as expected in production.
Tools like kubectl get pods -o wide or curl -f http://service:port/health can validate that systems are running correctly. Monitoring dashboards should show that metrics are flowing properly.
Checklists must be updated regularly to reflect new tools, practices, and system changes. This includes adding new items for new technologies and removing obsolete ones.
Version control of checklists ensures that changes are tracked and can be reverted if needed.
A production readiness review checklist is a structured approach to ensuring systems are ready for deployment. It requires clear definitions, specific verification steps, and explicit ownership. By avoiding vague criteria and focusing on concrete actions, teams can reduce the risk of production issues while maintaining agility in their deployment processes.
This page was rewritten on 16 October 2026. It replaced a templated version that was not specific to its own title. How these pages are written and checked. If anything here is wrong, tell us at [email protected] and we will correct it.
We use cookies for analytics (Google Analytics) and advertising (Google AdSense) to improve your experience and support free content. Privacy Policy