A dependency fix is only as safe as your ability to undo it. Set a rollback time budget for each service, such as "back on the previous version within 15 minutes", test it with a drill, and refuse to merge fixes to services that miss the budget until the path is improved.
Why a budget, not a plan
Most teams have a rollback plan on paper. Few know how long it really takes. The first time you learn it is usually during an incident, when every minute is expensive.
A time budget turns a vague promise into a number. It tells reviewers how much risk a change can carry, tells on call engineers what to expect, and shows leadership which services need investment.
How to choose the number
Tie it to the cost of being broken. Ask how long the service can be degraded before customers or revenue are affected, and set the rollback budget below that.
| Service type | Example budget | Reasoning |
|---|---|---|
| Customer facing checkout or login | Minutes | Every minute is visible and costly |
| Internal tool used in business hours | An hour | Users can wait briefly |
| Batch job that runs nightly | Before the next run | The failure only matters at run time |
| Mobile or desktop app released to users | Not a simple rollback | Plan staged releases and a forward fix instead |
Do not copy a number from another team. Pick one you can defend and test.
What a rollback includes
The budget has to cover the whole path, not just the button press.
- Detect the problem. Alerts, dashboards and a person who notices.
- Decide to roll back. Someone with authority must be reachable.
- Execute. Redeploy the previous artifact, revert the commit or flip a flag.
- Verify. Confirm the previous version is serving and the symptoms are gone.
- Handle data. If the new version wrote data the old one cannot read, rolling back code is not enough.
The slowest step is usually detection or the decision, not the redeploy. Time all of them in a drill.
Run a drill
Once a quarter, pick a low risk service and roll it back on purpose in a staging environment, or during a quiet window in production if you are confident. Time each step and write down what slowed you down: a missing permission, an artifact that had been deleted, a database migration with no way back, a runbook nobody could find.
Then fix the slowest thing and run it again. Our post on how rollback differs for OS patches and dependency updates is a useful companion.
Use the budget in merge decisions
Add one line to your fix pull request template: "Rollback tested within budget: yes or no, and how." If the answer is no, the reviewer should ask what makes this change safe to try, such as a canary release, a feature flag or a smaller step.
A service that cannot roll back inside its budget needs different handling: shipping behind a flag, rolling out to a small share of traffic first, or doing the expand then contract pattern for database changes so the old code still works.
Where tooling helps
Policies and gates can make the rollback requirement part of the merge conditions, and monitoring shortens detection. Safeguard provides policies, gates and guardrails, plus continuous monitoring, and you can run a free scan at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen.
Click through the monitoring view and consider which signal would tell you first that a change went wrong.
Quick check
What is a reasonable first budget?
Measure your current rollback time with one drill, then set a budget slightly better than that and improve it over time. A tested number beats an ambitious guess.
Does every service need one?
Start with the services where a bad deploy would hurt most. Add the rest as you go.
Last reviewed: 19 October 2026.
