What is Rollback?
Also called revert, roll back.
A rollback is the act of returning a system to a previously known good version after a change causes problems. It is the primary mitigation during deployment related incidents because it restores service without requiring the cause to be understood first. Rollback is only genuinely available when every change in the release is reversible, which database migrations and irreversible side effects can prevent.
For stateless application code, rollback is straightforward: redeploy the prior artifact and traffic returns to old behavior. The value is speed and certainty. Rather than diagnosing under pressure and shipping a hurried fix that may introduce a second problem, responders return to a state that was demonstrably working, then investigate at normal pace.
Data is what makes rollback hard. A migration that drops a column, rewrites values, or changes the meaning of a field cannot simply be undone, because the old code may not understand data written by the new code, and information may be gone. The standard discipline is expand and contract: add new structures, deploy code that writes both shapes, migrate readers, and only remove the old structure in a later release once rollback is no longer needed.
Other changes escape rollback entirely because their effects have already left the system. Emails sent, webhooks delivered, payments captured, and files published to third parties do not revert when the code does. Releases touching these paths need forward fixes and compensating actions planned in advance, since reverting the deployment addresses only future behavior.
The most common failure is discovering during an incident that rollback does not work. A rollback path that is never exercised tends to be broken by drift in configuration, dependencies, or data assumptions. Teams that treat rollback as a real capability test it on a schedule and require every change to state, before it ships, how it would be reversed.
Key points
- Restores a known good version without diagnosing first.
- Straightforward for stateless code, hard once data changed.
- Use expand and contract so migrations stay reversible.
- External side effects never roll back with the code.
- An untested rollback path is usually a broken one.
In practice
A release changes how agent task results are stored and begins producing malformed records. Because the migration only added a column and the new code wrote both the old and new shapes, rolling back to the previous version is safe: old code reads the old column and behavior returns to normal within minutes. The malformed new column data is cleaned up separately, without customers waiting on the investigation.