The team that owns the service is on call for an auto-merged fix, exactly as for any other change to that service. The bot has no pager and the security team did not click merge. Decide this before you enable auto-merge, and write the answer where on-call staff will find it.
The ownership gap
Automation can create a gap. A person who merges a change feels responsible for it. When a bot merges, nobody does, and a failure at 3 a.m. turns into a question about whose problem it is. The fix is to settle the question in advance, not during the incident.
Make ownership explicit
Three records close the gap.
- A service owner field. Each repository or service names a team and an escalation contact. If your organisation keeps a service catalog or a CODEOWNERS file, use it. For bot PRs, see codeowners for bot opened pull requests.
- An auto-merge register. A short list of which categories may merge themselves in which repositories, who approved that policy and when.
- A runbook line. "If a bot merged the last change and the service is unhealthy, roll back to the previous build, then investigate."
What GitHub's auto-merge does and does not promise
GitHub's documentation says auto-merge merges a pull request automatically after all required reviews and status checks pass, and that it must be enabled for the repository first. It also says auto-merge is disabled if someone without write permissions pushes new changes to the head branch. So the safety in an auto-merge setup lives in what you configured as required, not in the feature itself. If the required checks are thin, the merge is lightly guarded, and the on-call person inherits that.
Roles in the incident
| Role | Job |
|---|---|
| Service owner on call | Decide to roll back, run the rollback |
| Update policy owner | Explain why this category was allowed to merge, review the policy afterwards |
| Security contact | Say whether the fix is urgent enough to try again quickly |
| Incident lead, if declared | Coordinate, keep the record |
Keeping the policy owner and the pager separate matters. The person who set the rule should hear about every failure caused by the rule, even if they are not the one fixing production.
Review the policy after every failure
An auto-merged change that breaks production is data about the policy. Ask what check would have caught it, whether the category should go back to manual, and whether the change should have been grouped differently. A short review, written down, does more for trust than a long argument about whether automation is safe. For related reading see limit the blast radius of automated fixes.
A fair default
Begin with every category on manual approval. Move one category to auto-merge only when it has a named owner, required checks you trust, a rollback you have practised, and a place in the register. If any of those is missing, keep a human in the loop.
Safeguard can open fix pull requests through autonomous remediation. It is off by default and every category starts on Manual, so a person approves each change. You can also run a free scan to see which dependencies have known fixes before you decide what to automate.
Quick check
Should the security team be paged for a broken auto-merged fix?
Usually the service owner is paged first. Inform the security contact, since they may need to find another path to the fix.
Can a bot be listed as the owner of a change?
The bot is the author. A team must still own the outcome, so name one in your register.
Sources
Last reviewed: 19 October 2026.
