Production Deployment & Rollback Checklist Template

Phase 1: Change, Artefact & Window

The deploy strategy on the first task shows the matching tasks in Phase 4. The approver is named here for Phase 3.

• Record the service, version, deployer, approver and deploy strategy — Rolling, Blue-green, Canary or All-at-once
• Deploy the exact artefact that passed CI and staging — identified by version or image digest; never rebuild for production
• Link the change record and confirm its status — a standard change may be pre-approved; a normal change needs its approval first
• Check the window against freezes and other changes — peak trading, month-end and deploys to shared dependencies
• Confirm the deployer and on-call engineer are available for the deploy and the watch period — nobody deploys and then leaves
• Tell support and dependent teams when it starts — and update the status page if users will see downtime

Phase 2: Migrations, Flags & Rollback Plan

• Check every migration is backward compatible — the old version must run against the new schema, or rollback stops being an option
• Split breaking schema changes into expand, migrate and contract — add the new column now; drop the old one in a later release
• Check locking on large tables — in PostgreSQL, CREATE INDEX CONCURRENTLY avoids blocking writes but cannot run inside a transaction
• Put risky behaviour behind a feature flag, off by default — turning a flag off is faster than any redeploy
• Write the rollback steps and what they cannot undo — previous artefact, flag off or traffic switch; sent emails and data written in a new format stay
• Set rollback triggers and the decision time-box — for example error rate, p95 latency or SLO burn rate above an agreed level, decided within 30 minutes

Phase 3: Go/No-Go

The approver named on the first task records Approved or Not approved on the last task. The checklist halts there, and nothing is deployed until they decide.

• Confirm CI, staging tests and security scans passed for this build — not for an earlier one with the same version number
• Confirm dashboards and alerts for the service work — and note the current error rate and latency as the baseline
• Confirm the rollback plan is attached and its operator is present — a plan only one absent person can run is not a plan
• Confirm dependent teams are ready — database, platform, support and any team whose service you call
• Record the go/no-go decision — Approved or Not approved, with the reason

Phase 4: Strategy Steps

Only the tasks for the strategy chosen on the first task appear.

• Rolling: set surge and unavailability limits and readiness checks — Kubernetes defaults to 25% for both; a stalled rollout is reported after 600 seconds but not rolled back
• Blue-green: deploy to the idle environment, warm it up and test it directly — before any production traffic reaches it
• Blue-green: switch traffic and keep the old environment running — until the watch period ends, so going back is one switch
• Canary: send a small share of traffic to the new version — and compare it with a control group running the old version at the same time
• Canary: promote in steps only while the canary matches the control — each step recorded with its result
• All-at-once: take a backup or snapshot and post a maintenance notice — reserve it for services that can tolerate a short outage

Phase 5: Execute & Verify

The verification result is a required Pass or Fail. Fail shows Phase 6.

• Run the expand migrations and confirm they finished — before the new code that depends on them
• Start the deploy and record the time — the rollback time-box counts from here
• Run production smoke tests on the critical user journeys — sign-in, the main transaction and anything this change touched
• Check health and readiness across every instance — a partial rollout can look healthy in the average
• Compare error rate, latency and saturation with the baseline and the SLO — on the dashboard noted at go/no-go
• Record the verification result — Pass, or Fail with what breached

Phase 6: Rollback Decision

Tasks appear only when verification is recorded as Fail.

• Decide within the time-box: roll back or fix forward — default to rollback when the cause is not yet understood
• Roll back by the fastest safe route — flag off, traffic switch, kubectl rollout undo or redeploy of the previous artefact
• Leave expand migrations in place — the old code was built to run against them; reverse schema only if the plan says so
• Confirm recovery with the same checks used to verify — and record the time; it is your failed deployment recovery time
• Open an incident if users were affected — and tell support what they will hear about
• Schedule the postmortem — blameless, within a few working days, while logs and memories are fresh