Code freeze is a security event, not just a release policy
Every retailer we work with freezes deploys somewhere between the first week of November and the second week of January. The reasoning is sound: peak season is when a bad release costs the most, so you stop releasing.
What almost nobody freezes is everything else.
Your freeze does not apply to your vendors
The tag manager still pushes. The analytics vendor still ships. The chat widget still auto-updates. The personalization tool your growth team turned on in October is still fetching new configuration every few hours. During the ten weeks when your own engineers are forbidden from touching the checkout, third-party code on that same page changes dozens of times.
And your ability to respond is at its annual low. Half the team is on holiday. The change-approval path is deliberately slow because that was the point of the freeze. The on-call engineer has been told, correctly, not to touch anything.
If you were choosing a window to modify someone's payment page, you would choose this one.
The asymmetry is the whole problem
A freeze reduces the rate of change you control and does nothing to the rate of change you do not. It simultaneously reduces your capacity to react. Risk goes up and response goes down, at the exact moment transaction volume peaks.
We are not arguing against freezes. They work, for the thing they are for. We are arguing that a freeze is incomplete if it only covers the repository.
What a complete freeze looks like
- Freeze the script inventory too. Take a baseline the day the freeze starts. Anything that deviates is an exception requiring the same approval a code change would.
- Name the exception path in advance. Someone will need to ship something in December. Decide in October who can approve that and how fast, rather than improvising it at 9pm on a Friday.
- Turn off auto-update on vendor tags where the vendor allows it. Many do, and almost nobody asks.
- Keep one person genuinely on call for the page itself, not just the infrastructure.
None of this requires a product. It requires treating the freeze as a security control with a gap in it, rather than as a release calendar.