How to automatically revert a failed deploy (and when not to)

A deploy fails after a merge. Every minute production runs the wrong version, or no version, costs you. Reverting quickly is usually the right first move; fixing the real cause can wait until morning.

What "revert" means

In git, a revert adds a new commit that undoes an earlier one. It does not rewrite history, so it is safe on a shared branch. On GitHub you open a pull request that reverts the merge commit, merge it, and your normal deploy runs again with the last good code.

The manual steps

Notice the deploy failed (alert, chat message, or someone looking).
Find the merge commit that triggered it.
Open a revert pull request from that commit.
Get it merged (waiting for checks if your rules require them).
Watch the redeploy and confirm it is healthy.
Tell the team what happened and why.

Two ways to roll back

Many platforms can roll back to the previous release without touching git. That is fast, but main still contains the bad change, so the next deploy will fail again. A git revert keeps your repository and production in step, which is why teams that deploy from main often prefer it.

Automating it

You can script the steps above with GitHub Actions: trigger on a failed deploy workflow, create the revert branch and pull request, and merge it. The hard parts are the edge cases: a failed deploy that is only a flaky test, a revert that itself fails to deploy, two merges close together, and making sure nobody gets surprised.

When automatic revert is a bad idea

A good tool warns you before you schedule such a change, so you can choose to watch it yourself.

Database migrations that have already run and cannot be undone by reverting code.
Infrastructure changes (for example Terraform) where a revert may not restore the previous state.
Releases that must go out in a fixed order across repositories.
Anything customer-facing that needs a human decision first.

How Merge Scheduler does it

After it merges a pull request, Merge Scheduler follows the deploy runs that the merge commit triggered in GitHub Actions. If one fails, it opens a revert pull request, merges it, and watches the redeploy. If the redeploy also fails, it stops and marks the release as needing attention instead of looping. Either way you get one email naming the failed workflow, job and step, with the error lines from the log.

It flags migrations and infrastructure changes that a revert cannot undo, before you schedule.
You can add a health URL per branch; a failing health check after a green deploy also triggers a revert.
Auto-revert can be switched off per release.