How to Roll Back a Bad Deploy Quickly

Get a broken release reverted in seconds by promoting the last good deploy instead of debugging in production.

7 minIntermediate

When a deploy breaks production, the right first move is not to debug, it is to restore service by rolling back to the last good release. Most hosts keep previous deploys, so promoting one is faster than diagnosing the failure under pressure. This guide does that, then sets you up to investigate calmly.

What you need

A host that keeps deploy history
Access to the deploy CLI or dashboard
About 6 minutes

Step 1: Confirm the deploy is the cause

Check that the break lines up with the latest release. If errors started at the exact deploy time, a rollback will fix it.

Dashboard - error spike

Deploys

v240 10:02 CURRENT 500s spiking since 10:02

v239 09:14 previous healthy

v238 08:01 previous healthy

Errors begin at the moment of the latest deploy.

Step 2: Promote the last good deploy

Roll back by making the previous healthy deploy current again. This serves already-built files, so it takes effect almost immediately with no rebuild.

zsh - rollback

$host rollback v239

Promoting v239 to production...

Live: v239 is now current.

Step 3: Verify service is restored

Confirm the site is healthy again before you exhale. Watch the error rate fall back to normal and check the page directly.

terminal

curl -I https://my-site.example.app
# expect: HTTP/2 200, errors returning to baseline

Now debug, off the clock

With production stable on the old version, reproduce the failure locally or on a preview deploy. Never debug a broken release in production while users are hitting it.

Result: service is back in seconds on a known-good build, and you can find the real cause without an outage running over your shoulder.