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 code freeze is not a development freeze. Engineers still write code. Branches still get merged to main. What changes is the release cadence: changes accumulate instead of shipping continuously. The freeze is a deployment gate, not a work stoppage.
The case against code freezes
The engineering objection is well-rehearsed and mostly correct:
When an urgent issue surfaces during the freeze, the team navigates an exception process instead of just fixing it. Every minute on process is a minute the bug is live.
Feature work queues up. 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.
Developers rush to land work before the deadline. The week before a freeze looks like the week before a launch: longer hours, shortcut reviews, higher defect rates.
Not every team knows every other team's freeze schedule. A dependent service 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.
The timeline isn’t a hypothetical. It’s a composite of real freezes I’ve been through. The feature was ready on December 23. It shipped on January 6 — not because the code was broken, but because the organization wasn’t staffed to support it.
The real reason: it’s a risk-based decision
Code freezes aren’t about distrusting engineers. They’re about accepting a trade-off between two competing risks:
- Incident during holidays when key responders are unavailable
- Multi-team coordination at reduced capacity
- Customer impact measured in days, not hours
- Regulatory and reputational cost in banking, healthcare, payments
- Changes accumulate; first post-freeze release carries higher blast radius
- Feature work delayed by the freeze window
- Pre-freeze crunch if teams rush to land work
- Accepted because the full workforce can respond when it breaks
In regulated industries, Risk A is almost never worth taking for the sake of shipping a feature. The cost of a holiday incident — regulatory notification, customer impact, reputational damage — dwarfs the cost of waiting two weeks. Risk B is 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 a code freeze. 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:
Your deploy is only as fast as the slowest dependency — DBA, security, compliance, infra — and they all thin out at the same time.
A holiday incident isn't a postmortem item. It's a regulatory notification and a board-level conversation.
Incident response will be slower. The freeze accounts for response time, not just deploy time.
If fixing production tonight means paging four teams — and three of them are at dinner — the bar for shipping should be higher.
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 any organization where “the site was down for six hours on Christmas” is a board-level conversation rather than a postmortem item, the freeze is there for a reason.
The one thing that makes freezes worse
The biggest failure mode of a code freeze isn’t the freeze itself — it’s bad communication around the exception process.
A well-run freeze has clear answers to these 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’s arbitrary.
The healthiest freezes I’ve seen treat the exception process as a conversation, not a gate. The question isn’t “does this meet the criticality threshold?” — it’s “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 are the ones that treat them as a risk management practice — not a vacation policy, not a trust issue, and not an excuse to stop thinking about what’s worth shipping.
If the answer makes you uncomfortable, the freeze is probably doing its job.