Roll back a bad deployment

careful intermediate #rollback#production#broken#revert

When to use this: You deployed and the live site is broken. Restore a previous version fast.

Be careful with this one. A dashboard rollback fixes the live site only. Git still has the bad commit: follow up with a revert.

Before you start

Steps

  1. Roll back in the dashboard (fastest)

    Project, Deployments. Open the last good Production deployment, click the three dots, then 'Instant Rollback' (or 'Promote to Production'). Availability of Instant Rollback depends on your plan; promoting an older deployment always works.

  2. Or with the CLI

    terminal
    vercel rollback <deployment-url>

    Points Production back to that earlier deployment. Copy the URL of the last good deployment from the Deployments tab. Run vercel rollback --help if your CLI version behaves differently.

  3. Make Git match: revert the bad commit

    terminal
    git revert HEAD
    git push

    Without this, the next push to main would deploy the bad code again. For a merge commit use git revert -m 1 <id>.

How to verify it worked

  • The domain serves the earlier version, and the Deployments tab shows it as current Production.

How to undo it

Rolled back by mistake: in Deployments open the newer deployment and promote it again.

Common errors and fixes

A new push undid my rollback Rollback pins an older deployment. Auto-assignment resumes with the next production deploy. Revert the commit in Git as shown above, so new pushes are good.
Rollback did not fix the problem The issue may be an environment variable change or an external service. Compare Environment Variables history and check third-party status.

Q&A

Rollback vs git revert, which one?

Both, in order: rollback restores the site in seconds; revert fixes the source so the next deploy is also good.

Practice these as flashcards →

Terms in this scenario

Related scenarios

My notes

Saved in this browser only.