All insights
EngineeringProcess5 min read
When to revert (and how to do it cleanly)
The fastest fix for many production issues is to revert the change that caused them. Most teams have cultural friction against this, which costs them recovery time.
When something breaks shortly after a deploy, the right move is almost always to revert. The team that's good at this recovers in minutes. The team that tries to forward-fix during the incident recovers in hours, sometimes days.
Why teams resist reverting
- The PR author feels embarrassed — even though they shouldn't.
- There's a sense that reverting is admitting failure.
- Forward-fixing feels more proactive, even when it's slower.
- Reverting often involves resolving conflicts with later commits.
The clean revert
Revert quickly. Don't argue about it during the incident. Roll back the deploy, separately revert the commit, then take time to diagnose. The author can re-land the change once they've fixed the underlying issue. The revert is not a judgment; it's a tool.
The faster you revert, the faster you understand what broke. Forward-fixing during an outage is choosing to debug under pressure.