Change Freeze Theater. Meta Gated 16% And Halved Its Outages.

The email lands in the second week of November and the subject line has not changed in a decade: Production change freeze — November 18 through January 5. Then comes the part nobody writes down. For five working days everything anybody has been sitting on goes out the door, because after Tuesday it is not going anywhere until the new year.

That week is the most dangerous week of the quarter, and it exists because of a safety measure.

I have declared freezes, and enforced them where the alternative was a hard conversation with an auditor. What I had wrong was simpler than the policy. I thought a freeze was a decision about when to change things. It is a risk model, and a crude one.

The comfortable theory

Changes cause outages. A freeze removes changes. So a freeze removes outages — and the retail quarter, or the week your team is down to two people with a phone each, is exactly when you want them gone.

The hidden premise is that every change carries roughly the same risk, which makes blocking all of them the only honest way to block the bad ones. Said out loud, that sounds obviously false. Somebody measured how false.

What Meta found when it stopped freezing everything

Leveraging Risk Models to Improve Productivity for Effective Code Un-Freeze at Scale (Mockus et al., ACM Transactions on Software Engineering and Methodology, August 2025) documents replacing blanket freezes with risk-based gating at Meta. Rather than block every change over holidays and high-traffic periods, the policy gates the risky ones: a gated diff can still land, but only with a written rationale, sometimes an area expert's approval.

Three ways of choosing what to gate were compared at the same gating rate of 27.3%:

• ExpertPaths — file paths hand-picked by experts: caught 38.5% of SEVs, Meta's term for its production incidents
• FileModel — file-level logistic regression: 56%
• DiffModel — change-level logistic regression: 60.8%

Sit with the first line. Engineers who knew the system best, naming its dangerous parts from memory, lost to a logistic regression with a handful of inputs — at identical cost in blocked work.

Then the production numbers from the winter holiday freeze, with the change-level model running: "only 16% of diffs were gated, 5.7% were allowed to land after the developer provided landing rationale." Against the previous year's freeze, "we see a 42% increase in the number of landed diffs," and "instead of seeing a corresponding increase in SEVs, we see a 52% decrease in the number of SEVs compared to last year." Operating cost related to SEVs fell 47%.

Hold that at arm's length. It is a year-over-year comparison inside one company during a production rollout, not a controlled experiment — traffic, headcount and every other reliability programme moved too, and the paper cannot separate them. The mechanism underneath is what travels: "modifications to a very small fraction of the codebase are responsible for almost all SEVs." If that holds on your estate, a blanket freeze pays full price for a fraction of the protection.

A freeze that blocks everything is not caution. It is a risk model with one parameter, and the parameter is the calendar.

The batch you built on purpose

The second cost arrives in January.

DORA's 2019 Accelerate State of DevOps report tested the premise on change approval. Respondents whose organizations required sign-off from an external body were "2.6 times more likely to be low performers." On whether that formality bought lower change failure rates: "we found no evidence to support this hypothesis, consistent with earlier research."

The mechanism they name is the one a freeze industrialises: "introducing more approvals results in a slower process and the release of larger batches less frequently," carrying "higher levels of risk" and "thus higher change fail rates." That hypothesis, the report says, "was supported in the data." It is a self-reported survey, so take it as a strong prior rather than a law.

The January batch, though, is not a correlation. It is arithmetic. Seven weeks of held work ships in a fortnight, through a pipeline nobody has exercised since November, by people still finding their desks.

What the freeze never covered

Your vendors did not sign it. On December 7, 2021 — inside most freeze windows — AWS us-east-1 degraded from 7:30 AM PST, the affected networking devices not fully recovered until 2:22 PM PST. Amazon's own summary names the trigger as "an automated activity to scale capacity of one of the AWS services hosted in the main AWS network." Somebody's change took a bite out of your quarter. Not yours.

Nor did the vulnerabilities. Log4Shell went public in the second week of December 2021. CISA issued Emergency Directive 22-02 on December 17 and gave federal civilian agencies until 5 pm EST on December 23 to patch, mitigate or remove affected internet-facing assets. Every one of them was in a holiday posture. The freeze got no vote.

And the escape hatch is itself a hazard. The UK Ministry of Justice publishes technical guidance telling its teams to avoid code freezes because they "generally increase the risks to your service and those services around it." Among the named risks: mistakes made with an unfamiliar exception process under incident pressure, under-tested work rushed out ahead of the freeze, and large batches afterwards whose interactions are poorly understood. Guidance rather than measurement — but a government body writing down what it has watched happen.

Why it ended up this way

Because a freeze is almost free to declare, and because it is usually not about changes at all. The same guidance says a freeze is typically a symptom of low trust in the existing change process, or of a past traumatic event. Read that way, a freeze is not a control. It is the admission that you do not trust yours, and the email is cheaper than fixing them.

It also has no owner. The quiet December lands on whoever declared it. January lands on whoever is on call.

What I would do

Write down what the freeze protects. If the answer is revenue hours, freeze the revenue path. Freezing the internal wiki in sympathy costs a sprint and buys nothing.

Build the cheap version of Meta's model. You cannot fit a risk model across tens of thousands of developers. You can list the services behind your last twenty incidents. That list is your gate, and it beats a date range.

Keep the pipeline warm. If nothing deploys for seven weeks, the January release is also the first test of the pipeline in seven weeks. Ship something dull weekly — a dependency bump, a log line — proving the road is still open.

Rehearse the exception path in November, not at 2 a.m. on December 27. Whoever needs it should have used it once while the office was full.

Do the work a freeze cannot touch, before it starts. Certificate expiry dates through February. Capacity headroom at seasonal peak, not November's load. Whose status page you would open first.

Then count what it cost. The size of the January batch, and the change failure rate of the fortnight after the thaw. Measure neither and a freeze goes on looking free forever.

I would still freeze some things. The difference is that I no longer think I am removing risk. I am choosing where to put it, and January is a real place with real people in it.