Returning to the previous working version when a release breaks something, the fastest way to stop the bleeding.
Why it exists
Even well-tested changes sometimes break production, and when they do the fastest safe fix is to return to the version that worked, not to debug live under pressure. Rollback exists to go back to the previous known-good version quickly, so a bad release is a minute of downtime instead of an hour of panic.
How it actually works
When a new release causes problems, the quickest fix usually isn't to debug live, it's to roll back: redeploy the last known-good version, restoring service, then investigate calmly afterward.
Because Git keeps every version, rollback can be near-instant. Fast, safe rollback is a hallmark of a mature team; it turns a scary incident into a minor blip.
A senior PM walks you through it
A junior PM, stuck
Error alerts started flooding the channel a couple of minutes after Friday's checkout release, and the lead typed "rolling back now, debug after" and went quiet. Ten minutes later he said it was handled. In standup I have to say what actually happened, and right now all I have is "there was a deploy, then it was fine." I do not want to stand there guessing at the timeline.
The deploy log has the whole timeline, and it is shorter than the standup you are dreading. This is the release pipeline plus the error-rate monitor for the same window, so you can see the bad version land, the errors climb, the rollback fire, and the numbers come back to normal. The one thing to watch for is the difference between when the rollback was decided and when it finished, because that gap is the real story. Here are the lines from that window. Read the timestamps down the left, then take the steps with me.
Deploy and monitor log, Friday afternoon checkout release
2026-03-06T13:04:09ZINFOdeploy release v2.4.1 rolled out to production
Reporting "fixed at 13:07" because that is when the lead spoke up. The log says recovery landed at 13:19, and the twelve-minute gap is exactly the fact a standup needs to hear.
Pushing to debug the 500s live instead of supporting the rollback. Going back to v2.4.0 stops the bleeding in one move, and the investigation is calmer and safer once customers are off the broken version.
Reading error_rate=9.0% as "nine out of ten checkouts failed forever." It was a three-minute ramp that the rollback reversed, so the blast radius is a window, not a permanent state.
Treating rollback as free and instant when scoping a launch. This one took twelve minutes to complete, and asking "how fast can we roll back?" before shipping is a real risk question, not a nicety.
Writing the postmortem without the version numbers. "A deploy broke checkout" is unsearchable, while "v2.4.1 at 13:04, rolled back to v2.4.0 by 13:19" ties the incident to an exact change anyone can pull up.
Say in standup: "v2.4.1 shipped at 13:04 and checkout errors ramped from 0.2% to 9% over three minutes. Rollback to v2.4.0 was called at 13:07 but completed at 13:19, and the error rate was back to baseline by 13:20. So we were degraded for about fifteen minutes, and the twelve-minute rollback time is the thing to speed up." You read the timeline off the log instead of guessing it.
Where a PM meets this
"Just roll it back" is often the right first move in an incident; understanding it lets you support that call instead of pushing to debug live.
If rollback is hard or slow, that's a real risk; asking "how fast can we roll back?" before a big launch is smart.
Hear it in a meeting
"Errors spiked after the deploy, rolling back now, we'll debug after."