Production Deployment Checklist

A production deployment checklist for risky prod deploys: change approval, backups, rollback criteria, staged rollout and close monitoring. Start it from CI.

Typical schedule per production deployment
The checklist 5 sections, 22 items
Variables {{service}} {{version}} {{change_ticket}}
Start from CI

Use this template Free, no credit card. Imports the checklist into your Runbook organization.

Use this checklist for production deployments that carry real risk: a schema change, a new infrastructure component, a change to payments or authentication, or the first deploy of a new service. For routine, low-risk deploys a shorter deployment checklist is enough. This one adds the steps that matter when production data and paying customers are involved: a named approver, a fresh backup, rollback criteria agreed in advance and a staged rollout.

Who owns it

The engineer running the deployment owns the run. A second person, often the tech lead or an on-call engineer, approves the change and watches the dashboards during the rollout. If your company has a change management process for audits such as SOC 2 or ISO 27001, the run gives you a record of who approved and who verified each step.

Common pitfalls

Rollback criteria decided under pressure. Agree before the deploy what "bad" means, such as error rate above the normal baseline or a failing checkout. Then the rollback decision is quick.
Backup taken but never restorable. A snapshot you have never restored is a hope, not a backup. Know how long a restore takes before you rely on it.
Config drift between staging and production. The code was tested, but a different environment variable or feature flag in production changes its behaviour. Diff the config.
Watching the wrong signal. CPU and health checks stay green while users get errors. Watch user-facing metrics such as error rate, latency and business events.

The checklist: Production deploy: {{service}} {{version}}

Approval and preparation

Change ticket {{change_ticket}} describes the change, risk, rollback and test evidence
Change is approved by someone other than the person deploying
The exact artifact or image for {{version}} was tested in staging
Deploy the same build, identified by digest or checksum, not a rebuild from the same commit.
Production configuration, secrets and feature flags are compared with staging
Deployment window is agreed and no other production changes are scheduled at the same time
On-call engineer knows about the deploy and is reachable

Safety net

Fresh database backup or snapshot is taken and its timestamp is noted in the run
Restore time for that backup is known and acceptable optional
Rollback criteria are written down, such as error rate, latency or a failing key flow
Rollback command and previous version number are written down and tested in staging

Rollout

Status page or customer notice is posted if downtime or degraded service is possible optional
Database migrations are applied and their output is checked
{{version}} is rolled out to a canary instance or a small share of traffic first
Skip this only if your platform cannot do partial rollouts.
Canary metrics are compared with the old version before the full rollout
Full rollout of {{version}} is completed and all instances report the new version

Verification

Smoke test of login and the main customer flow passes in production
Error rate, latency and saturation are within normal range for at least 30 minutes
Business signals look normal, such as sign-ups, orders or payments
Background jobs, queues and scheduled tasks are processing

Close out

Change ticket {{change_ticket}} is updated with the result and closed
Team and stakeholders are told the deploy is complete, or rolled back with the reason
Follow-ups are created for anything unexpected seen during the deploy

Checklist as Markdown

# Production deploy: {{service}} {{version}}

## Approval and preparation
- [ ] Change ticket {{change_ticket}} describes the change, risk, rollback and test evidence
- [ ] Change is approved by someone other than the person deploying
- [ ] The exact artifact or image for {{version}} was tested in staging
  Deploy the same build, identified by digest or checksum, not a rebuild from the same commit.
- [ ] Production configuration, secrets and feature flags are compared with staging
- [ ] Deployment window is agreed and no other production changes are scheduled at the same time
- [ ] On-call engineer knows about the deploy and is reachable

## Safety net
- [ ] Fresh database backup or snapshot is taken and its timestamp is noted in the run
- [ ] Restore time for that backup is known and acceptable (optional)
- [ ] Rollback criteria are written down, such as error rate, latency or a failing key flow
- [ ] Rollback command and previous version number are written down and tested in staging

## Rollout
- [ ] Status page or customer notice is posted if downtime or degraded service is possible (optional)
- [ ] Database migrations are applied and their output is checked
- [ ] {{version}} is rolled out to a canary instance or a small share of traffic first
  Skip this only if your platform cannot do partial rollouts.
- [ ] Canary metrics are compared with the old version before the full rollout
- [ ] Full rollout of {{version}} is completed and all instances report the new version

## Verification
- [ ] Smoke test of login and the main customer flow passes in production
- [ ] Error rate, latency and saturation are within normal range for at least 30 minutes
- [ ] Business signals look normal, such as sign-ups, orders or payments
- [ ] Background jobs, queues and scheduled tasks are processing

## Close out
- [ ] Change ticket {{change_ticket}} is updated with the result and closed
- [ ] Team and stakeholders are told the deploy is complete, or rolled back with the reason
- [ ] Follow-ups are created for anything unexpected seen during the deploy

Start this checklist from your pipeline

Before the production job runs, POST /api/v1/runs with template "Production deploy: {{service}} {{version}}" and the change_ticket ID.

curl -X POST https://runbook.metastic.ch/api/v1/runs \
  -H "Authorization: Bearer $RUNBOOK_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"template": "Production deploy: {{service}} {{version}}", "variables": {"service": "…", "version": "…", "change_ticket": "…"}}'

See the API and the GitHub Action

Frequently asked questions

What is the difference between a deployment checklist and a production deployment checklist?

A general deployment checklist works for any environment and routine changes. A production deployment checklist adds the controls for higher-risk changes: formal approval, a fresh backup, written rollback criteria, a canary step and a longer monitoring window. Many teams use the short one by default and this one for changes tagged as high risk.

Do I need change approval for every production deploy?

Not necessarily. Many teams pre-approve standard, low-risk changes that go through a reviewed pipeline, and require explicit approval only for risky ones. If you are preparing for an audit, write that policy down and make sure your records show it was followed.

How long should I monitor after a production deployment?

Long enough to see real traffic on the new version, including the flows that matter most. For a busy service that may be half an hour. For a low-traffic one, check again after the next peak or the next batch job. Write the window into the checklist so it is not cut short.

Updated 2026-11-04