Skip to main content
OpsRoadmaps

Checklists / production-deployment

Production Deployment Checklist

Ship a change to production safely: verify, deploy, watch, and know how to get out.

9 steps · 9 required · last reviewed (next review 2027-03-19) · updated 2026-09-21

Related focus areas:DevOpsReleaseOpsSRE

Roadmaps covering the same ground:DevSecOps RolloutIncident Management MaturityObservability MaturityPlatform Engineering AdoptionProduction-Ready KubernetesResilience and DR ImprovementSRE Adoption

Sign in to run this checklist

Run this for every release that touches production, or at minimum for anything that changes schema, configuration, dependencies, or traffic patterns. The goal is not ceremony — it is making the two moments that decide outcomes (before you deploy, and right after) explicit and hard to skip.

Rollback is the item teams skip most and regret most. If you cannot answer "how do we get back to the last known-good state in under ten minutes", do not deploy yet.

  1. Change is reviewed and approved by someone other than the author

    required

    A second set of eyes catches the class of defect the author is structurally blind to — their own assumptions.

  2. CI is green on the exact commit being deployed

    required

    Deploying a commit that never passed the pipeline means production is now your test environment.

  3. Database migrations are additive and backwards-compatible with the old code

    required

    Expand/contract: the old version must keep working while the new one rolls out, or a failed deploy becomes a failed database.

  4. Rollback plan is written and tested for this change

    required

    A rollback you have never exercised is a hope, not a plan. Ten minutes to last-known-good is the bar.

  5. Feature flags or config allow the change to be disabled without a redeploy

    required

    Killing a bad feature with a flag is minutes; rolling back a deploy is longer and riskier.

  6. Deployment happens during staffed hours, not Friday evening

    required

    Deploying when the on-call rotation is thin converts your bad deploy into someone's 2 a.m. problem.

  7. Dashboards and alerts for the affected service are open before you deploy

    required

    You cannot watch what you have not opened; the five minutes after cutover is when partial failures whisper.

  8. Post-deploy smoke checks pass on production (login, critical path, payout, whatever your business does)

    required

    Synthetic checks catch the failure that only exists in production — missing env vars, cold caches, permissions.

  9. Owner is watching error rates and latency for 30 minutes after deploy

    required

    Most deploy-induced incidents surface in the first half hour; walking away immediately means users do your monitoring.

Run it against your real gaps

A checklist is most useful when you know which controls you are actually missing. A free OpsRoadmaps assessment scores your controls with explainable findings and builds a roadmap from the results.

Assess my stack

Checklists document self-reported practice. Items were last reviewed 2026-09-19 — adapt them to your own environment.