I build a code freeze tool. Here is the strongest case I know that you shouldn’t need one, and I think about half of it is right.
I want to make that case properly. The version I usually hear is a slogan, “freezes are an anti-pattern,” and a slogan is easy to wave off. Then I want to say where I think it stops working, which is not where most vendors say it does. And then I will describe the only kind of freeze I would defend.
The case against
The research points the other way. DORA’s own summary of its metrics says it plainly: “speed and stability are not tradeoffs. In fact, we see that the metrics are correlated for most teams”. Throughput and stability move together; top performers do well across all of them and low performers do badly across all of them. A freeze is, definitionally, batching. If you accept the research, a freeze is a deliberate move toward the failure mode it is meant to prevent.
A freeze does not stop change; it queues it. Nothing that would have merged in December stops existing. It sits in a branch, drifting from main, growing conflicts, waiting. The January thaw is then the largest, least-reviewed, most-conflicted deploy of the year, run by a team that just got back from two weeks off. You did not remove risk. You moved it to a single day and picked the day when your people are least sharp.
Freezes atrophy the thing you will need. Three weeks without deploying means three weeks without exercising the deploy path. The first time anyone runs it again is under pressure, for a hotfix. Deploy pipelines rot quietly; a freeze is an excellent way to find out how quietly.
A freeze is a confidence substitute. This is the argument I find hardest to answer. If you cannot deploy safely on 23 December, you cannot deploy safely on 3 February either. On 3 February you are just not watching as closely. The freeze converts a capability problem into a calendar problem, and calendar problems get solved every year without anyone fixing the capability. Progressive rollout, real feature flags, a tested rollback path, and enough observability to notice within minutes are all strictly better than a freeze, and a freeze lets you postpone all four.
Serious organisations do without it. The Pragmatic Engineer’s survey of code freeze practice reports that Spotify runs no code freezes at all, asking only for extra caution when staff availability is low. Not a startup with three services. If a freeze were load-bearing for reliability at that size, it would be hard to skip.
And the tooling has moved. A feature flag is a kill switch that is faster, more granular, and reversible in seconds by the person who noticed the problem. A merge freeze is a blunt instrument in a world that has scalpels. If your reason for freezing is “we are afraid of what might go out,” the flag is a better answer, and it is a better answer all year.
Where the case breaks
Nobody is optimising the average. The National Retail Federation puts November–December at “about 19% of total retail sales over the last five years, but the figure can be higher for some retailers”. And it is the “higher for some retailers” half that runs freezes. If a fifth or more of your year lands in two months, and a meaningful slice of that in two days, the expected-value argument is correct and beside the point. What those businesses are buying is not a lower failure rate. It is a lower variance on a date where the downside is a quarter’s revenue. Those are different objectives, and the research answers the first one.
On-call capacity is the real constraint. Between 24 December and 2 January, half your team is away and the other half is in a different timezone with family in the room. A freeze in that window is a staffing decision wearing an engineering costume. The honest version of “we freeze in December” is usually “we do not have the people to respond in December,” and no deployment-frequency chart refutes that sentence.
Enabling genuine time off is one of the most-cited reasons for freezing. In the same survey’s write-up of 185 responses, one principal engineer’s answer is “we encourage people to just take time off and rest, and we freeze code so nobody is forced to work.” That is a humane argument rather than a technical one, and technical arguments do not get to overrule it. A team that ships all year and takes one protected fortnight is not immature.
Some freezes are inherited. Your payment processor freezes. Your largest customer freezes and writes it into the contract. You can believe whatever you like about freezes and still be inside someone else’s.
Auditors ask a specific question. The change-management criterion in the AICPA Trust Services Criteria (CC8.1) is about an entity authorising, testing, approving and implementing changes to meet its objectives. In other words, evidence that changes were controlled rather than merely intended. A documented, enforced, logged freeze window with an actor on every override is cheap evidence of exactly that, and it is system-generated rather than screenshotted. This is why freezes survive in organisations that know the DORA findings perfectly well.
The research is also answering a different question. Deployment-frequency findings compare steady states: teams that habitually ship small changes against teams that habitually ship large ones. A two-day freeze around a revenue event is not a habit, it is an exception, and nobody has published the counterfactual: the same organisation, the same Black Friday, one year frozen and one year not. That measurement does not exist, which is awkward for both sides of this argument and especially for the side selling you a tool. The most I will claim is that if you are going to do it anyway, the shape of the freeze changes the cost by a lot.
And the “only immature teams freeze” claim is empirically false. The same series describes Meta running alternating yellow and red periods from November through December, Amazon running Restricted and Blocked days around Prime Day, Black Friday, Christmas and re:Invent, and Oracle core product teams freezing six weeks ahead of a quarterly release. You can think all three are wrong. You cannot claim the practice belongs only to teams who have not read the research.
What a defensible freeze looks like
Most of the damage people blame on freezes comes from one avoidable shape: global, open-ended, no exception path, announced in a channel topic. Here is the version I would defend.
- Scoped, not global. Freeze checkout, not the docs site. A global freeze is what makes people hate freezes, and it is almost never what the risk analysis justified.
- Time-boxed, with a published end. Put the end time where people without GitHub access can read it. “Until further notice” is how a freeze becomes a month.
- An exception path measured in minutes. This is the one that matters most. If the override is slow or social, people route around the freeze, and you have replaced a safety control with a policy that manufactures lies.
- Graduated. Advisory, then restricted, then blocked. Meta’s yellow-and-red periods and Amazon’s Restricted-and-Blocked days are both shaped this way. Most teams jump straight to blocked, and then resent the whole idea.
- Auditable. Who froze it, why, for how long, who overrode it, and why. If you cannot answer those in six months, the freeze bought you nothing you can show anyone.
- Measured. Count what it cost: queued pull requests, thaw-day incident rate, time to land a hotfix during the window. Publish it internally. If you cannot show the freeze bought anything, stop doing it. I mean that literally. This is the discipline the practice is usually missing.
- The thaw plan is the plan. Everything hard about a freeze happens on the day it ends. Stagger the thaw, order the queue by risk, and have people at desks.
What I would tell you not to buy
If you have three repositories and one admin, use GitHub rulesets. Turn on a required check or restrict updates for the window, turn it off after, and spend the money on something else. Tooling for this is not interesting at three repositories.
If you deploy fifty times a day behind flags with progressive rollout and you can halt a rollout in seconds, use the kill switch you already have. A merge freeze is a worse version of the control you built.
Where a tool starts earning its place is narrower than any vendor will admit: somewhere around ten repositories, when “turn it on everywhere” stops being a thing one person can do reliably; or the first 2am incident where the only person who could freeze main was asleep; or the first time an auditor asked for a list of changes made during your freeze window and you produced screenshots.
I build the tool for those three situations, and I would rather say so plainly than pretend the argument at the top of this post is silly. If you are in the first two categories, the honest recommendation is rulesets, and here is how to set them up properly.
Every statistic above links to the primary source it came from, and I read each one on 30 July 2026. Where I could not find a source I could stand behind, the claim is not in the essay. An earlier draft asserted that e-commerce businesses take 40–60% of annual revenue in November and December, and that number went in the bin when the retail-industry figure turned out to be about 19%.