Roll back a bad deploy in minutes instead of hours

I just shipped something broken to production, and now I'm frantically trying to write a fix instead of doing the one thing that would actually help right now.

Intermediate to advancedRead 6 minDoing: usually under thirty minutes once the incident starts, most of it spent watching each step confirm itself before moving to the next7 steps

▶ Start

What you'll have at the end

The last working version back online within minutes, so nobody has to write a fix under pressure.

Before you start

You need

A web service on Render already deployed from a GitHub branch with automatic deploys turned on, and some way to notice when requests start failing, whether that's an error tracker, logs, or reports from real users.

Not covered

Working out the actual code fix for whatever the bad deploy broke; this only covers getting the last working version back online and keeping the bug from returning on its own.

Leans on

7 steps

Where to go next

Database migration just took the whole app down

go there instead if what actually broke was a schema change already applied against a live database, since rolling the application back alone cannot undo that.

Turn your green GitHub Actions run into an actual deploy

go there if you haven't wired up automatic deploys yet and want to see how a workflow's own deploy step is built in the first place.

Get error tracking running before your first crash in production goes unnoticed

go there first if the only reason you noticed this outage was a customer complaint rather than a tool telling you directly.

Checked 25 Aug 2026

Part of the Full-Stack Application Deployment cookbook