The honest case against code freezes

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, because the version of it I usually hear is a slogan — “freezes are an anti-pattern” — and slogans are 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 want to describe the only kind of freeze I would defend.

The case against

The research points the other way. The DORA programme’s finding, repeated across years of data, is that deployment frequency and change failure rate move together, not against each other. Teams that ship small changes often fail less, not more. 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, executed 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, at the worst possible moment. 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 — you were simply 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. In The Pragmatic Engineer’s survey of code freeze practice, with over a hundred respondents, Spotify reported running no year-round freezes at all. Not a startup with three services. If this were load-bearing for reliability at that size, it would be very 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. E-commerce businesses commonly take 40 to 60 percent of annual revenue in November and December. The expected-value argument — small frequent changes fail less often — is correct and beside the point on the two days that pay for the year. What those businesses are buying is not a lower failure rate. It is a lower variance on a date where the downside is measured in 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 that sentence is not refuted by a deployment-frequency chart.

“Enabling genuine time off” was one of the most-cited reasons in that same survey. It 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. SOC 2’s change-management criterion wants evidence that changes were authorised and controlled, and auditors increasingly want system-generated evidence spanning the whole observation period rather than three screenshots taken the week before the audit. A documented, enforced, logged freeze window is remarkably cheap evidence of exactly that. This is the reason 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 survey describes Meta running alternating yellow and red periods across roughly two months, Amazon running Restricted and Blocked days tied to Prime Day and re:Invent, and Oracle running six-week freezes ahead of quarterly patch releases. 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 attributed to freezes comes from a specific, 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 actually justified.
• Time-boxed, with a published end that is visible to people who do not have GitHub access. “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 and Amazon both do this. 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 the freeze cannot be shown to have 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.