Deploying to Production — checklists.org

For shipping a change to a production web service with real users. Assumes you have CI, at least one pre-production environment, and dashboards for errors and latency.

Goes straight to the people who keep this checklist current. No account needed.

Describe your situation — plain language is perfect

Assembled only from these vetted items — every kept item traces back to the original.

Before you deploy

Confirm CI is green on the exact commit you are deployingThe commit, not the branch. A merge landed after your last CI run can ship code no test has ever seen.
Skim the full diff between production and the release candidateWhat's going out is often more than your change — everything merged since the last deploy rides along.
Write down the rollback planThe exact command, the version identifier you'd roll back to, who runs it, and how long it takes. If the plan is "redeploy the old image", verify that image still exists in the registry.
Verify the migration works with the currently running code if database migrationOld code and new schema run side by side during rollout. Use expand/contract: add columns as nullable now, backfill, and drop the old ones in a later deploy — never in the same one.
Rehearse the migration against a production-sized dataset if database migrationAn ALTER TABLE that is instant in staging can lock a 100-million-row table for minutes. Measure it before production does.
Put the new behavior behind a feature flag, deployed off if risky changeSeparates deploy from release. Flipping a flag back takes seconds; even a good rollback takes minutes.
Pick a deploy window when people can respondNot Friday afternoon, not ten minutes before you leave, not peak traffic. The best window is early in a workday with the author and on-call both around.
Announce the deploy in the team channelWhat's going out, a link to the diff, and who is driving. This is also what turns "is anyone deploying?" from a mystery into a scroll.
Post a maintenance window to the status page if expected downtimeCustomers forgive planned downtime and punish surprise downtime.

During the deploy

Run the migration before rolling out the new code if database migrationNew code that expects a schema that isn't there yet fails loudly and everywhere at once.
Roll out to a canary slice first5–10% of traffic, then compare error rate and latency against the rest of the fleet before going wide. Most bad deploys announce themselves within minutes at 5%.
Watch error and latency dashboards while instances cycleHave them open before the rollout starts so you can see the before/after edge, not just the after.
Verify the new version is actually servingHit the version or build-hash endpoint. "Deploy succeeded" sometimes means the orchestrator gave up and left old containers running.
Smoke-test the critical path by handLog in, perform the core action users pay for, log out. Two minutes, catches the class of failure health checks can't see.
Roll back at the first sign of user-facing errorsRoll back first, diagnose later. Debugging forward in production turns a five-minute incident into an hour-long one — the rollback plan you wrote costs nothing to use.

First hour after

Enable the flag for an internal or small cohort first if risky changeEmployees, then 1–5% of users, then everyone. Each step is a chance to catch what staging couldn't.
Keep watching for at least 30 minutesSome failures need a cache expiry, a cron run, or a traffic peak to surface. A deploy isn't done when the progress bar finishes.
Compare key business metrics against the same window yesterdayErrors can be silent: a signup flow that drops 30% of users throws no exceptions.
Check background jobs and queue depthsA worker crashing on the new code shows up as a growing queue, not an alert — a slow-motion outage.
Announce completion in the same channelInclude anything you noticed; the next deployer inherits your context.

Follow-up

Remove the feature flag once the change is fully rolled out if risky changeA stale flag is an untested code path and a config landmine. Put a removal ticket in the sprint the day you flip it to 100%.
Schedule the contract step of the migration if database migrationDrop the old columns and code paths after a safe soak period, or they'll still be there in five years.
Update the runbook with anything this deploy taught youIf a step surprised you, it will surprise the next person at 3 a.m.

Essential is a lens, not a shorter list — the file is identical, every hidden step is one tab away, and the marker travels with the item into forks, personalized copies, and the .json.