Production operations
Roll back a deployment
Move production traffic to a known-good immutable deployment quickly, verify recovery, and reconcile the repository afterward.
8 minute lesson
A rollback reassigns production traffic to an earlier deployment. It is useful when the current release causes immediate user harm.
Choose a deployment you previously verified, use the current dashboard or CLI rollback workflow, and smoke-test the production domain after the alias moves. A rollback does not undo a database migration or external side effect automatically. Revert or fix the source and redeploy so repository history and the next production build agree with the recovered state.
# inspect current CLI syntax before an incident
npx vercel@latest rollback --helpSelect the target from evidence: deployment ID, commit, environment, age, previous smoke result, and compatibility with current data and credentials. An old deployment can contain a revoked secret or code that cannot read the current schema. “The one before this” is not always a safe target.
After traffic moves, test the production domain rather than only the old deployment URL, watch error and latency signals, and record the time to recovery. The database, environment configuration, scheduled effects, and third-party calls remain as they were. Compensate or roll those back separately where possible, then revert or fix the production branch so the next automatic deployment preserves the recovered behavior.
Write and rehearse a rollback drill using harmless visible changes. Record the trigger, chosen deployment, verification, and source follow-up.
Lesson completed