How to Roll Back a Deployment in Vercel with Instant Rollback
Every team eventually ships a broken production deploy. The difference between a five-minute incident and an hour-long one is usually how quickly someone can get production back to the last good state. Vercel's Instant Rollback lets you point production back at a previous deployment without rebuilding, which is often the fastest fix available.
This guide covers when to roll back, how to do it from the dashboard or CLI, what happens to new deployments after a rollback, how to promote a fix, and what to put in place beforehand so a rollback is a routine action rather than a panic.
Have a feature in mind? Describe it and Vantage drafts the PRD.
A few sentences is enough: the problem, who has it and what you want to change. Vantage turns it into a structured PRD with requirements you can edit.
How this works
- We save what you typed. No AI runs on this page.
- You create a free account.
- Vantage builds a PRD from it inside your own workspace.
Why ask for an account? We’re a small team, and a full generation runs a multi-step AI pipeline that costs us real money. So we tie it to a free account instead of running it anonymously. You also get to keep the result and edit it.
Your text is only used to create your project, and it stays private to your account. If you don’t sign up, we delete it after 7 days. Privacy policy
Step-by-step guide
Decide quickly whether to roll back
If a production deploy causes errors, broken flows, or a major regression, and the cause is not obvious, roll back first and investigate second. Rolling back restores the previous state while the team diagnoses the problem without pressure. Agree on this rule before an incident so nobody hesitates.
- Confirm the problem started with the latest deployment
- Check whether the issue involves data or schema changes that a rollback will not undo
- Roll back if the cause is not immediately fixable
Roll back from the dashboard
Open the project in the Vercel dashboard and go to Deployments. Find a previous production deployment that was healthy, open its menu, and choose Instant Rollback. Vercel points your production domains at that deployment without a new build. Depending on your plan, you may be limited in which previous deployments you can roll back to.
- Open the project and go to Deployments
- Identify the last healthy production deployment
- Select Instant Rollback from that deployment's menu
- Confirm and verify production is serving the previous version
Roll back from the CLI
The Vercel CLI includes a rollback command, which is useful for scripts or when the dashboard is not convenient. Run it with the appropriate project context and, if needed, the deployment you want to roll back to. Make sure the people on call have the CLI installed and authenticated before they need it.
Understand what happens next
After a rollback, Vercel stops automatically assigning production domains to new deployments for that project, so a new push does not undo your rollback by accident. New commits still build, but they will not go live until you explicitly promote a deployment or undo the rollback. Make sure the team knows this, or someone will wonder why their merged fix is not live.
Fix forward and promote
Once the fix is merged and deployed, verify it on its deployment URL, then promote it to production. Promoting restores normal production assignment for subsequent deployments.
- Merge the fix and let Vercel build it
- Test the deployment on its unique URL
- Promote the deployment to production
- Confirm production domains point to the new deployment
Account for things a rollback does not undo
Instant Rollback changes which build serves traffic. It does not reverse database migrations, data written by the bad deploy, or changes in external services. Changes to environment variables may also need attention. Plan schema changes to be backward compatible so a rollback is always safe.
Write a short incident note
After the incident, record what broke, how long it took to detect, when the rollback happened, and what you changed to prevent a repeat. Detection time is usually the part with the most room for improvement.
Common mistakes
Debugging in production before rolling back
Spending twenty minutes investigating while users hit errors is usually the wrong trade. Roll back, then investigate.
Forgetting auto-assignment is paused
After a rollback, new deployments do not go live automatically. Teams that forget this think their fix failed.
Non-backward-compatible migrations
If the new code ran a migration the old code cannot handle, rolling back can make things worse. Design migrations so the previous version still works.
Tips
Document the rollback procedure in your incident runbook with screenshots.
Give on-call engineers the permissions needed to roll back.
Use preview deployments and checks to catch issues before they reach production.
Monitor error rates for the first minutes after every production deploy.
How Vantage helps
Rollbacks are easier when you know what each deploy was meant to change. Vantage keeps tickets linked to the requirements they implement and syncs status with Linear, so when a deploy goes wrong, PMs and engineers can trace which requirements were affected and what needs to be re-planned.