When an automated fix breaks your build, stop further merges, revert the change to get back to a working state, find out why it broke, decide whether to retry with a smaller fix or a planned upgrade, and then add a test so the same problem cannot return unnoticed.
TL;DR: Undo first, investigate second. A revert gets you back to safety in minutes. After that, learn what broke, keep the security risk in view, and adjust the settings that allowed the surprise.
Definition: To revert a change is to create a new change that undoes an earlier one, leaving a clear record of both.
Why do automated fixes sometimes break things?
Fix pull requests are meant to be small and safe, but no change is risk free. A few common causes explain most breaks.
- Behavior changed in the new version. Libraries use semantic versioning to signal risk, and the official text says a patch number should go up when only backward compatible bug fixes are introduced. That is a promise, and promises are sometimes broken by accident. Your app may also depend on an old quirk the maintainers never meant to protect.
- A major upgrade slipped through. If your strategy allows large jumps, a fix may change how a library works.
- Tests did not cover the affected code. A green check only means the tests you wrote passed.
- A second package moved with it. A lockfile change can bring in other updates that interact in unexpected ways.
- The environment differs. A fix may behave differently in production than in a test setup.
None of these is a reason to give up on automation. They are reasons to have a recovery plan before you need one.
What are the eight steps, in order?
- Pause new merges. Tell the team to hold other changes for a few minutes. Mixed changes make the cause harder to find.
- Confirm the fix is the cause. Check the time of the first failure against the time of the merge. Look at the first failing test or error message.
- Revert the pull request. GitHub documents that reverting a merged pull request creates a new pull request that undoes the original merge commit, and that you need write permission. Merge the revert, and let your build run again.
- Check that you are healthy again. Confirm the build passes and that the app behaves normally in the places that broke.
- Tell people what happened. A short message is enough: what broke, what you did, what is next. Quiet fixes breed rumors.
- Find the real cause. Reproduce the failure on a branch using the fix. Read the library's release notes for the version you moved to.
- Choose the next move. The options are in the table below.
- Add a test and tune the settings. Make the failure impossible to miss next time, then decide whether your automation should be narrower for a while.
If the revert option is missing or causes conflicts, GitHub notes you may need to revert individual commits instead, or ask a repository administrator for write permission. Practice once on a test repository so the first time is not during an incident.
What are your options after the revert?
| Option | When it fits | Trade off |
|---|---|---|
| Retry with a smaller fix | A patch version exists that still repairs the flaw | Fast, low risk |
| Plan a proper upgrade | The available fix is a major version | Takes scheduled developer time |
| Apply a workaround | A configuration change blocks the attack path | Does not remove the flaw |
| Accept the risk for now | The flaw is not reachable and has low impact | Needs a written, dated decision |
| Fix forward | The cause is small and well understood | Riskier than a revert, so keep it short |
Reachability helps with this choice. Reachability analysis checks whether your code actually calls the flawed part of a library. If it does not, you may safely choose a planned upgrade over a rushed fix. If it does, speed matters more, so look first for a smaller fix or a workaround. For deeper background, read breaking change aware remediation.
What does a worked example look like?
This example is invented, including every number, to show the flow.
Worked example (invented numbers): At 10:05, a team merges a fix pull request that moves pretty-dates from 2.4.1 to 2.5.0. At 10:20, the checkout page begins to fail for some users. Automatic monitoring raises an alert.
| Time | Action |
|---|---|
| 10:20 | Alert fires. The on call engineer asks the team to pause merges. |
| 10:25 | The first error points to a date function. The merge at 10:05 is the one recent change. |
| 10:30 | Engineer opens the merged pull request and clicks revert. |
| 10:36 | The revert merges and the build runs. |
| 10:50 | Checkout is healthy again. A message goes to the team and to support. |
| 14:00 | The team reproduces the break on a branch. Release notes show that 2.5.0 changed the default date format. |
| 15:00 | Decision: use the patch fix 2.4.2 now, and schedule a planned change for 2.5.0. |
| 16:00 | A test for the date format is added, and the strategy is kept on Safest. |
Total time with the problem: 30 minutes from the alert to recovery. The security flaw was only exposed again for the afternoon, and the team closed the gap with a smaller fix the same day. That is a good result for a rough morning.
How do you stop it from happening again?
Take three small actions after every break.
- Add the missing test. The break showed a gap, so close it.
- Narrow the automation. If a strategy allowed a minor update that caused trouble, move to a more cautious one for the affected repository.
- Write a short note. One paragraph: what happened, what you changed, what you learned.
Also consider a staging step. Merge to a test environment and watch it for a day before production. For ideas on safe release patterns, see canary deployments and security monitoring.
Should you turn automated fixes off after a break?
Not automatically. One break among many successful fixes is a normal cost of change. But have a stop rule agreed in advance. For example, if two merged fixes cause incidents in a month, return the affected categories to Manual until you understand the cause. Either way the choice is yours, and returning to Manual is quick. For the thinking behind a careful start, read how to turn on automated fix pull requests safely.
How does Safeguard help?
Safeguard provides autonomous remediation with fix pull requests as a generally available capability. Its flow includes an impact assessment, breaking change detection, and validation, which are meant to surface problems before merge. It is off by default, and every category is set to Manual.
Safeguard also offers SBOM and dependency scanning, so you can rescan after a revert and see which flaw is exposed again, and policies, gates, and guardrails to set rules around what can ship. The Safeguard CLI can also write code, in addition to scanning. To see the current state of your own project, use the free scan at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how a project is watched after changes ship, since recovery depends on noticing problems quickly.
Quick check
What is the fastest safe way to undo a merged fix?
Revert the pull request. GitHub creates a new pull request that undoes the original merge, and you merge it like any other. It needs write permission on the repository.
Does reverting bring the security flaw back?
Yes. The vulnerable version returns until you apply a different fix. That is why the next step is to find a smaller fix or a workaround quickly.
Who should be told when a fix breaks something?
The team that owns the code, the people on call, and support if customers were affected. A short message is enough.
Should I go back to Manual after one break?
Not necessarily. Follow the stop rules you wrote in advance. One break among many good fixes is normal, but repeated breaks mean you should narrow the automation.
Sources
- Reverting a pull request, GitHub Docs, on how a revert works and who can do it.
- Semantic Versioning 2.0.0, on what patch numbers are meant to signal.
Last reviewed: 19 October 2026.
