Skip to content
Releasing

08.05 · Concept

Rollback Beats Forward-Fix

Argue from feedback-loop length why halving recovery time buys more availability than doubling uptime.

No video curated for this lesson yet

This lesson is written, ordered and part of the path - the video slot is the only thing still open. We are working through Deployment lesson by lesson; 29 of 56 have their video so far.

The written notes below cover this idea in full - you lose nothing by reading instead of watching.

Rollback improves availability by shortening the path from detection to restored service. A forward fix spends outage time on diagnosis, code changes, review, build and deploy, while rollback returns to a known-good release first. The key argument is feedback-loop length: faster recovery usually reduces user impact more reliably than hoping failures become rarer.

What this lesson answers

  • why rollback is better than forward fix
  • how recovery time affects service availability
  • when should teams avoid rolling back

Notes

Rollback Beats Forward-Fix — Rollback exists to shorten the incident feedback loop by restoring the last known-good version immediately; without it, teams spend user-facing outage minutes debugging, coding, reviewing, building, and redeploying an unproven fix.

Key Concepts: - Availability is dominated by recovery time: , so cutting from to minutes improves availability more directly than hoping the next release doubles .

Common questions

Why is rollback often better than a forward fix during an incident?
Rollback removes the broken change from production before the team fully understands it. A forward fix keeps users exposed while engineers diagnose, patch, test, build and redeploy under pressure. That longer loop also increases the chance of a second mistake. Rollback restores service first, then leaves investigation for calmer conditions.
How does recovery time affect availability?
Availability depends on both how often failures happen and how long they last. Shortening recovery time directly reduces the outage window every time something goes wrong. Making failures rarer is valuable, but it is harder to prove during an incident. A fast rollback gives a predictable way to reduce impact immediately.
When is rollback the wrong choice?
Rollback is unsafe when the previous version cannot run correctly against the current production state. Incompatible schema changes, changed cache formats, or data already corrupted by an older version can make reverting code worse. In those cases, a forward fix or a carefully planned data repair may be the safer recovery path.