How Do I Undo a Launch That Went Wrong?
6 min read
You pushed an update, the app broke for everyone, and now the clock is running. The fastest fix is almost always the same: roll back to the previous deploy, the last version you know worked, instead of trying to debug the broken one live. On Vercel, Netlify, and most modern hosts this is one click and takes about thirty seconds. Fix forward later, once the pressure is off.
Why this happens
Every deploy is a snapshot of your code at a moment in time. Your host keeps the old snapshots, so "roll back" just means pointing your live URL at yesterday's snapshot instead of today's broken one. Nothing is rebuilt, nothing is recompiled, so it is fast and safe.
The reason founders panic is that nobody set this up as a plan. An AI agent that built your app will happily ship changes, but it does not hand you a runbook for "what to do when the change is bad." You asked it to build the feature, not to rehearse the failure. So the first time a deploy breaks, you are learning the rollback button under maximum stress, which is the worst time to learn anything.
How to check
Before you need it, find your rollback button so you are not hunting for it mid- incident:
- Vercel: open your project, click Deployments. Each past deploy has a ... menu with Promote to Production (older versions may say Rollback). That instantly makes the older build live.
- Netlify: Deploys tab, click any previous successful deploy, then Publish deploy. It goes live immediately.
- Anything Git-based (Cloudflare Pages, Render, Amplify, Railway): the same idea lives under a Deploys or History list. Look for "redeploy," "promote," or "roll back" next to each entry.
Confirm you can identify, right now, which deploy in that list was the last known good one. If you cannot tell them apart, start giving your deploys clear commit messages so the list is readable in an emergency.
The fix
When a deploy breaks production:
- Roll back first, diagnose second. Promote the last known good deploy using the steps above. Get real users back to a working app before you do anything else.
- Confirm it worked. Open the live site in a private browsing window (so you are not seeing a cached version) and check the thing that was broken.
- Now investigate on a copy. Reproduce the bug in a preview or local environment, not in production. Every host above builds a preview URL for each branch or pull request; use that.
- Re-deploy only when the preview is clean. Ship the fix forward once you have watched it work somewhere that is not your live app.
- Write down what happened. One line: what broke, how you knew, what you did. That is the runbook you wished you had five minutes ago.
The trap to avoid
The expensive mistake is trying to debug forward on the live site while users are staring at a broken app. You push a "quick fix," it does not work, you push another, and now you have three bad deploys stacked up and no clear known-good version to return to. Roll back first. A working old version beats a broken new one every single time.
The second trap: a rollback only reverts code, not data. If the bad deploy also wrote broken records, deleted rows, or ran a bad database migration, rolling the code back does not undo that. Data damage needs a database backup or a point-in-time restore, which is a separate thing you want in place before launch, not after.
Where this fits
Being able to undo a bad launch in under a minute is one of the quiet things that separates a beta that survives its first bad day from one that does not. It pairs directly with having somewhere safe to test first, covered in do I need a staging environment before I launch, and with knowing something broke at all, covered in how do I get alerted when my app goes down. The free Readiness Report checks whether your project actually has a reachable rollback path and backups before your first users arrive, and the Finishing Pass sets up the rollback and backup plan for you so the button is there, tested, the day you need it.