Decide before the freeze starts, and write it down. A sensible default is to keep opening and reviewing fix pull requests but hold routine merges until the freeze ends, with a defined exception path for exploited or critical issues. Silence in your policy means the bot decides by accident.
Why it matters
Automation does not observe holidays. A bot that opens pull requests on a Friday before a long weekend creates a queue nobody owns, and a merge on a thin staffed day lengthens the time to notice a regression. Freezes exist to reduce change risk, and an unattended fix path undermines them.
Three policy options
| Option | What happens | Good for |
|---|---|---|
| Hold all | No merges, proposals may queue | Short, high-stakes freezes |
| Hold routine, allow urgent | Only fixes meeting a severity and exposure test merge | Most teams |
| Pause the bot | No proposals, no merges | Long holidays or staffing gaps |
Hold routine, allow urgent is the usual choice, but it needs a definition of urgent that is not left to whoever is awake.
Defining the exception
Write it as criteria, not as a feeling:
- The vulnerability is exploited in the wild according to a source your policy names, or is reachable in an internet facing service.
- The fix is small, such as a patch level update.
- A named approver is on call and has agreed.
- A rollback plan exists and the person who can run it is available.
If any criterion is missing, the fix waits. Record every exception with who approved it.
Mechanics
- Calendar the window. Put freeze dates where the team already looks, and link the bot owner.
- Switch mode ahead of time. Move categories to manual at the start of a long freeze, and restore them after a review rather than automatically.
- Block merges for bot pull requests. Use repository rules so the freeze is enforced by the system, not by good intentions. See how to pause every fix PR during an incident for the mechanism.
- Cap the backlog. If proposals continue, limit open pull requests so you do not return to a pile of fifty.
- Plan the thaw. After the freeze, merge in small batches, lowest risk first, watching production between batches.
Holiday staffing
The worst case is not a quiet queue. It is a critical advisory landing while the one person who knows the system is away. Name a primary and backup for the exception path, and confirm they can merge and deploy. Keep contact details current.
Do not let the freeze become a backlog
Freezes that stretch lead to large batches of changes landing together, which raises risk again. Track how many security fixes are waiting and how long they have waited. Report it at the end of the window so leadership sees the cost of holding. The related post on what to tell leadership when you will miss a remediation SLA helps with that conversation.
Document the policy once
A half page is enough: scope, options chosen, the exception criteria, the owner, and the restart check. Review it before each major freeze.
Safeguard offers autonomous remediation with fix PRs, off by default with every category on Manual, which suits freeze periods since nothing merges unless people decide it should.
Quick check
Should critical fixes ever merge during a freeze?
Often yes, through a written exception path with a named approver and a ready rollback, so urgent risk is not left open.
Do we need to pause the bot or just block merges?
Blocking merges is the essential part. Pausing proposals as well avoids a large pile of open pull requests afterwards.
Last reviewed: 19 October 2026.
