An update just broke my website and customers can't order. How do I undo it right now?
Short answer: If your site is hosted on Netlify and built from a connected repository, go to the Deploys tab, find the last version that worked, and click Publish Deploy. The previous working version goes live again within seconds, with no rebuild needed, and there's no special cost or limit for doing this. The one thing to know: this restores the site's files, not any database or form data changes that happened since, and if your site auto-publishes from Git, the next code push can overwrite your rollback unless you lock the deploy first.
Every minute the broken version stays live is a minute customers hit it instead of a working site, so speed matters more than finding out what went wrong right now.
I'm Ranjit, and I run Blur Studio: 15+ years building software, 120 apps taken live, and clients who have gone on to raise $10M+. I build AI systems and processes that help businesses do a lot more with a lot less time. I also work differently from most of what else is out there, more on that further down this page. Say hello.
This page may contain affiliate links from which Blur Studio earns commissions.
When something breaks right after an update, the instinct is to start debugging immediately. Don't. The fastest fix for "it's broken and costing me orders" is almost never "find and fix the bug"; it's "put back the version that was working five minutes ago," and figure out the actual bug afterward with the pressure off.
How to roll back right now
- Go to your site's Deploys tab in Netlify. You'll see a list of every past deploy, each one a complete, saved version of your site.
- Find the most recent deploy you know was working, usually the one right before the broken update.
- Open that deploy's detail page and select "Publish Deploy." This instantly makes that version live again, with no rebuild step, which is why it's fast: you're not waiting for anything to compile or process, just switching which already-built version is currently live.
- Confirm the site is actually working again by checking it the same way a customer would, not just glancing at the homepage.
- Only then, with the pressure off, go figure out what actually broke in the update, ideally testing the fix on a Deploy Preview before trying again on the live site.
This whole process, from noticing the problem to the site working again, usually takes under a minute once you know where the button is. That speed is the entire point.
What a rollback does and doesn't fix
A rollback restores your site's files back to an earlier, working state. It does not undo anything that happened in a separate database, or any form submissions and data changes that occurred while the broken version was live. If your site is purely a front-end (no database, no server-side data), a rollback restores everything that matters. If it has a backend with its own data, the rollback fixes the broken display or behavior, but any orders, signups or data changes from the broken period are a separate thing you'll need to check and handle on their own terms.
The part that trips people up: auto-publish can undo your rollback
If your site is connected to a Git repository with auto-publishing turned on, here's the genuine gotcha: the next time any code gets pushed to your production branch, Netlify builds and publishes that new version automatically, which overwrites your rollback, even if that new push has nothing to do with the original problem. If you need the rolled-back version to stay live while you properly fix the underlying issue (rather than rushing a fix under pressure), use deploy locking: go to the Deploys tab and select "Lock to stop auto publishing." New deploys still build in the background, ready to go, but none of them go live until you unlock it. This buys you time to fix the real problem properly instead of rushing a second emergency fix on top of the first one.
What this actually costs
Rollbacks themselves don't have a published credit cost or special usage limit; they're treated as a standard part of deploy management on every plan. Deploy lock and unlock notifications (email, webhook, or Slack alerts when someone locks or unlocks a deploy) are available specifically on Pro and Enterprise plans, useful mainly for teams where more than one person could lock or unlock a deploy and everyone needs to know when that happens.
The alternatives, and when they fit better
Host backups (a cPanel backup or a WordPress backup plugin) serve a similar emergency-restore purpose on platforms without Netlify's deploy history, though they're typically slower to restore from and depend on backups having actually been taken recently and correctly.
Asking the developer to redo it works, but is strictly slower than an instant rollback, and shouldn't be your first move when a one-click restore is sitting right there in the dashboard.
When rollback alone is not enough
A rollback restores site files only. If the damage involves a database, lost orders, or corrupted data from while the broken version was live, those need their own separate fix; a rollback doesn't reach into a database to undo anything that happened there.
A worked example: a broken checkout on a Saturday
Say an online store pushes a routine update Saturday morning, a small visual tweak to the product gallery, and within an hour, the owner gets a message that checkout isn't working. Panic sets in; it's a Saturday, their developer is unreachable, and every minute means more visitors hitting a broken checkout instead of completing a purchase. The owner opens the Deploys tab, finds Friday's version listed clearly above today's, clicks Publish Deploy, and checkout works again within seconds, all without touching a line of code or waiting for anyone's help. The actual bug in the gallery update, whatever caused it, gets investigated calmly on Monday with the developer, on a Deploy Preview rather than the live site, with zero further customers affected in the meantime.
The detail worth sitting with here: the owner didn't need to understand what broke, or why, to fix the urgent part of the problem. Knowing where the rollback button lives and being willing to use it immediately, rather than waiting for a developer to diagnose the actual cause first, is what kept a Saturday morning bug from becoming a lost Saturday's worth of orders.
Common mistakes during a broken update
- Trying to debug live before rolling back. Every minute spent reading error messages on the broken live site is a minute customers are still seeing it. Roll back first, diagnose calmly after, in that order, every time.
- Not knowing where the rollback button is until the moment you need it. Find the Deploys tab and confirm you know how to use it on a calm day, not for the first time during an actual emergency.
- Forgetting to lock the deploy after an emergency rollback if more changes are coming. An unlocked rollback can quietly get undone by the very next unrelated push, turning one emergency into two.
How I'd approach this
For any client site I build or maintain, I make sure rollback is something they know how to do themselves, right now, without needing to call me first, specifically because every minute spent finding my phone number is a minute the broken version stays live. Where I actually come in afterward is the real fix: figuring out what caused the break and making sure the same category of mistake can't happen again, ideally testing it on a Deploy Preview rather than the live site next time. Get in touch if you want your update process set up so this becomes a non-event instead of an emergency.
Questions people ask
How fast does a rollback actually work?
Instantly, with no rebuild required. Clicking "Publish Deploy" on a previous version makes it live within seconds, since Netlify is switching which already-built version is currently live, not rebuilding anything from scratch.
Does a rollback cost anything or count against a limit?
Netlify doesn't publish a special credit cost or usage limit for rollbacks; it's treated as a standard part of managing deploys available on every plan.
Will a rollback undo orders or form submissions that came in while the site was broken?
No. A rollback restores your site's files only, not any database or data changes. Orders, signups or submissions from the broken period need to be checked and handled separately from the rollback itself.
Why did my rollback get undone a few hours later?
If your site auto-publishes from a connected Git repository, the next code push automatically builds and publishes, overwriting the rollback even if that push is unrelated. Use deploy locking if you need the rolled-back version to stay live while you work on a proper fix.
What does deploy locking actually do?
It pins your site to its currently published deploy, so new builds still happen in the background but don't automatically go live until you unlock it. This is the fix for a rollback getting overwritten by an unrelated auto-publish.
Who can see when a deploy gets locked or unlocked?
On Pro and Enterprise plans, lock and unlock events can trigger email, webhook or Slack notifications, useful for teams where more than one person might lock or unlock a deploy and everyone needs visibility into it.