Every December, the same argument plays out in engineering Slack channels. Someone wants to ship a small change: a bug fix, a copy tweak, a “low-risk” config update. The response comes back: code freeze. Wait until January.
Cue the eyerolls. We have CI/CD. We have automated tests. We have feature flags. We have monitors. What is this, 2005?
I used to be that engineer. Then I became the person who had to decide whether to wake up a DBA at 2am on Christmas Eve.
What a code freeze actually is
A code freeze is a defined period when no new code reaches production. It typically covers the holiday season, late December through early January, though some organizations extend it around major product launches or quarter-end closes.
The mechanics are simple. The deployment pipeline stays open for hotfixes, but feature work, refactors, and non-critical changes wait. The bar for what counts as “critical” rises sharply.
A freeze doesn’t stop development. Engineers still write code, branches still get merged to main. What changes is the release cadence: changes accumulate instead of shipping continuously. It’s a deployment gate, not a work stoppage.
The case against code freezes
The engineering objection is well-rehearsed and mostly correct.
Freezes reduce flexibility. When an urgent issue surfaces mid-freeze, the team navigates an exception process instead of just fixing it, and every minute on process is a minute the bug is live. They delay progress: a two-week freeze means two weeks of accumulated, unreleased changes landing in the first post-freeze deploy, often the riskiest release of the year. They create a pre-freeze crunch, where the week before the deadline looks like the week before a launch, with longer hours, shortcut reviews, and higher defect rates. And they surface communication gaps, because not every team knows every other team’s freeze schedule. A dependent service usually discovers the freeze when their deploy fails, not when it was announced.
All of these are real. So why do companies, especially in regulated industries, keep doing it?
The bottleneck you don’t see
Here’s the thing: your team might have automated tests, feature flags, and a 15-minute CI/CD pipeline. But your team doesn’t operate in isolation.
Suppose your change needs a database migration. The DBA team reviews every schema change, and during the holidays that team is running at 30% capacity. Your migration is now in a queue behind three others, each requiring the same person who’s currently on a ski slope with patchy reception.
Now multiply that across every dependency: the security review for your new auth flow, the infrastructure change your service relies on, the compliance sign-off your feature requires because it touches customer funds. Each dependency chain is only as available as its most understaffed link.
That timeline isn’t a hypothetical. It’s a composite of real freezes I’ve been through. The feature was ready on December 23 and shipped on January 6, not because the code was broken, but because the organization wasn’t staffed to support it.
It’s a risk-based decision
Code freezes aren’t about distrusting engineers. They’re about accepting a trade-off between two competing risks.
Shipping during the freeze risks an incident when your key responders are unavailable, multi-team coordination at reduced capacity, and customer impact measured in days rather than hours. In banking, healthcare, or payments, that also means regulatory notification and reputational cost. Waiting until full staffing returns has its own price: changes accumulate so the first post-freeze release carries a larger blast radius, feature work slips by the length of the window, and teams rush to land work beforehand.
In regulated industries the first risk is almost never worth taking for the sake of shipping a feature. The cost of a holiday incident dwarfs the cost of waiting two weeks. The second risk gets accepted because when it materializes, the full workforce is back to handle it.
This is the part most engineers miss. The freeze isn’t about your team’s ability to ship safely. It’s about the organization’s ability to respond when something goes wrong, and something always goes wrong eventually, no matter how good your tests are.
When code freezes make sense
Not every organization needs one. A small startup with one team, a simple architecture, and no regulatory obligations can probably ship through the holidays without much risk.
The calculus changes when teams are interdependent and their availability drops at the same time, so your deploy is only as fast as the slowest of DBA, security, compliance, and infra. It changes in a regulated environment, where a holiday incident isn’t a postmortem item but a regulatory notification and a board-level conversation. It changes when the on-call rotation is thinned, because the freeze accounts for response time and not just deploy time. And it changes when fixing production tonight means paging four teams and three of them are at dinner.
If none of these apply to you, congratulations. You might not need a freeze. But if you’re at a bank, a healthcare company, a payment processor, or anywhere “the site was down for six hours on Christmas” reaches the board, the freeze is there for a reason.
The one thing that makes freezes worse
The biggest failure mode of a code freeze is bad communication around the exception process. A well-run freeze has clear answers to four questions.
Named role, not a committee. Available during the freeze window.
Pager, phone tree, or explicit backup — documented before Dec 20.
A disagreement shouldn't become a Slack thread at 11pm.
Date, time, timezone, and the process for the first post-freeze release.
A badly-run freeze has none of these answers, and every urgent-but-not-critical fix becomes a political negotiation instead of a process. That’s when engineers start resenting the freeze, not because it exists, but because it feels arbitrary.
The healthiest freezes I’ve seen treat the exception process as a conversation rather than a gate. The question isn’t “does this meet the criticality threshold?” but “is the risk of not shipping this higher than the risk of shipping it?” That framing puts the engineer and the decision-maker on the same side of the table, evaluating the same trade-off.
If this change broke production tonight, who would have to fix it — and are they at a dinner table right now?
Code freezes aren’t going away in regulated industries, and they shouldn’t. The organizations that run them well treat them as a risk management practice rather than a vacation policy, a trust issue, or an excuse to stop thinking about what’s worth shipping.
If the answer to that question makes you uncomfortable, the freeze is probably doing its job.
Questions
What is a code freeze?
A defined period when no new code reaches production, typically late December through early January. Development continues and branches still merge to main; what changes is the release cadence. The deployment pipeline stays open for hotfixes while feature work, refactors, and non-critical changes wait.
Why do companies still do code freezes if they have CI/CD?
Because a freeze protects incident response, not deployment safety. Your pipeline may run in fifteen minutes, but DBA review, security review, compliance sign-off, and on-call rotations all thin out at the same time over the holidays. A deploy is only as available as its most understaffed dependency.
How long can a holiday deploy actually take?
In one composite of real freezes: code ready on December 23, in production on January 6. The DBA team was at 30% capacity, security review took 48 hours on holiday rotation, and the compliance officer was offline until January 4.
What makes a code freeze go badly?
A missing exception process. A freeze needs a named decision-maker available during the window, a documented way to reach them offline, an escalation path when the first answer is no, and an exact end date with a plan for the first post-freeze release. Without those, every urgent fix becomes a political negotiation.