Skip to main content
Pick a previous deployment and release it. It takes about forty seconds, because nothing is rebuilt. The image already exists.

​
Why it is fast

Every deployment keeps the image it produced. Rolling back points the service back at one of those images, so the work is a release rather than a build. The difference matters at the moment you need it. Reverting a commit and waiting for a full build is the same three minutes you did not have when you noticed the problem.
1

Open the application's deployments

Every deploy is listed with its status, when it ran, and, when it came from GitHub, the commit it built.
2

Choose the one that worked

Usually the one before the one you just shipped.
3

Release it

The service is pointed back at that image. No rebuild, no queue.

​
What rolls back, and what does not

This is the part worth understanding before you need it. A rollback is not a migration rollback. If the deploy you are reverting added a column, dropped a table, or rewrote data, the old code is now running against the new schema. Sometimes that is fine, because the old code simply does not know about the new column. Sometimes it is not, because the old code selects a column your migration renamed.
Before rolling back past a migration, know what the migration did. Reverting application code is instant and safe. Reverting a schema is neither, and no platform can do it for you without risking your data.

​
A failed deploy does not need a rollback

Worth saying, because it is the more common case. If a deploy fails, the previous version stays up. The new version is not released and then reverted; it never takes traffic at all. Migrations run before the release, so a failed migration fails the deploy with your old version still serving. You only need a rollback when a deploy succeeded and the result is wrong. That is a different situation from a build error, and it is the one to plan for.

​
Deciding quickly

When something is wrong in production, the useful question is not what broke, it is whether the previous version was fine. If it was, roll back first and diagnose after. Forty seconds of stale code beats twenty minutes of debugging under pressure. The deployment list gives you the commit each image was built from, so the diff between what works and what does not is one comparison away once you are no longer on fire.

Health and alerts

Health checks run every few minutes, and you are emailed when an application changes state rather than on every check. That is usually how you find out you need this page.