Skip to main content
There is no one-click rollback today. Deploys on our current hosting do not keep a build that can be released again, so there is nothing to switch back to. To undo a deploy, put the code back to the last version that worked and deploy that. It is a full deploy, not an instant switch, so it takes as long as your normal deploys do: minutes, not seconds. Worth knowing before the moment you need it.

​
How to put the previous version back

The Deployments tab lists every deploy with its status and, for deploys from GitHub, the commit it built. That tells you which version to go back to.
Revert the commit that broke things and push:
With deploy on push turned on, the push is the deploy. git revert adds a new commit that undoes the old one, which is safer than rewriting history on a branch other people use.

​
What a failed deploy leaves running

This depends on where the deploy stopped, and it is the part most worth understanding in advance. The first row is the common case: a build error or a failed migration, and your app keeps running as it was. The other two happen after the new version has taken the old one’s place, because each app runs on a single instance and a release replaces it. The app stays down until a version that starts is deployed, which is either a fix or the previous code put back as above.

​
Undoing code does not undo a migration

Putting old code back does not reverse a database migration. If the deploy you are undoing added a column, dropped a table, or rewrote data, the old code now runs 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 the migration renamed.
Before putting code back past a migration, know what the migration did. Redeploying old application code is safe. Reverting a schema is not, and no platform can do it for you without risking your data. The pattern that avoids the problem is additive migrations that both the old and new code tolerate.

​
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, put it back first and diagnose after. A few minutes of redeploying the old code beats twenty minutes of debugging under pressure. Once you are no longer on fire, the deployment list gives you the commit each deploy built, so the difference between what worked and what did not is one comparison away.

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.