When the right answer is no

A change freeze window policy is one page that says when the team stops shipping — and, just as important, what still ships anyway. Most small teams run freezes by vibes: someone declares “no deploys before Black Friday,” three exceptions get argued verbally, one of them breaks checkout, and nobody can say afterwards which rule was real. The fix is the same fix as everything else on this site: write it down before you need it, next to the change management checklist it plugs into.

1. Freeze what actually needs freezing

• A freeze is a scope, not a mood. “No changes” is unenforceable and false — the day a freeze starts, an on-call engineer will still need to rotate an expiring API key (that is what the rotation checklist is for). The policy names three lanes: frozen (feature deploys, schema changes, infrastructure upgrades), allowed (security patches, secret rotation, backups, monitoring changes), and emergency (anything that stops money or data loss, with the escape hatch in section 4). One line per lane, no debate at 5PM on the day before the freeze.
• Freeze the pipeline, not the people. The point of a freeze is that the people carrying the pager are defending a known-good system, not reviewing a feature branch at midnight. Say it that way in the policy: during the freeze, engineering time shifts from shipping to watching — the handoff gets shorter, the alerts get quieter, and the backlog waits.
• Marketing launches are not engineering changes — until they are. The classic freeze violation is a landing-page copy change that ships with a tag-manager update and silently rewrites checkout. The policy rule: during a freeze, anything that touches the production domain goes through the same review as code, even if it “is just text.” That sentence alone prevents most freeze-season incidents.

2. Put the freeze calendar in the policy, not in someone’s memory

• Name the recurring windows. For most small teams that is: the holiday window (mid-December to early January), major sales days (Black Friday, product launches), the payroll close, and the final week of any fiscal quarter if finance systems run on your stack. Write the exact dates each year in a five-minute ritual — a recurring calendar invite titled “publish freeze windows” is the whole system.
• Announce at T-minus-14 and T-minus-2. Two weeks of warning lets teams merge and release what is ready; a 48-hour reminder with the lane rules attached catches the “wait, does this count?” questions before the freeze starts, not inside it. Post it where the incident comms go — same channel, same audience.
• Every freeze has an owner and an end time. “The freeze is over when someone feels like deploying again” is how a two-week freeze becomes six. The policy line: the freeze ends on its stated date unless the owner extends it in writing, with a reason, at least 24 hours before it was due to end. Extensions are expensive by design.

3. Score every exception — the freeze request card

• Exceptions are requests with a score, not favors. The policy includes a five-line card: what changes, what it touches (from the asset inventory), what breaks if it is wrong, what breaks if it waits, and who is around to fix it during the freeze. If “what breaks if it waits” is smaller than “what breaks if it is wrong,” the answer is no — and the policy made the answer predictable, which is the entire value.
• The reversal test decides borderline cases. A change may ship during a freeze only if it can be undone fast: feature-flagged, behind a toggle, or reversible with the rollback runbook in under the response SLA your severity matrix assumes. Schema migrations and data backfills almost never pass this test. That is why they almost never ship in a freeze.
• Log the exceptions where the postmortems live. Every approved exception goes into the same log the incident plan uses. After the freeze, one line per exception: did it hold? The teams with the calmest freezes are the ones that can show, with data, that their exception bar works — and the ones that tighten it after a single bad exception.

4. The emergency escape hatch — write it before you need it

• A freeze that cannot bend will break. A genuine production fire during a freeze must not require anyone to consciously “break policy” at 3AM — that hesitation is exactly what the first 30 minutes runbook exists to prevent. The hatch is one sentence: stopping active data loss or revenue loss overrides the freeze; declare it in the incident channel, fix it, and file the exception card after. Retroactive, not blocked.
• The hatch has a ceiling. The escape covers restoring the pre-freeze state — a rollback, a key rotation, disabling a broken integration. It does not cover “and while we are in there, let’s also ship the fix we’ve been meaning to do.” Scope discipline during emergencies is a rehearsed skill; the postmortem of every freeze-season incident asks one question: did the emergency change stay in scope?
• Test the hatch before the freeze starts. Once per freeze season, run the same rehearsal you use for backup restores: pick a service, walk the emergency path end-to-end in staging — declare, decide, roll back, file. Twenty minutes. The freeze that has been rehearsed is the one where the 2AM decision is boring.

5. End the freeze on purpose — the thaw checklist

• The thaw is a scheduled event, not an absence of freeze. On the end date, the policy runs a 30-minute review: exceptions filed and their outcomes, incidents during the window (there should be near zero — if there were many, the freeze was protecting the wrong thing and the uptime budget needs a look), and the change backlog ranked by risk, not by who shouted first.
• Unfreeze in waves, not all at once. The lowest-risk changes ship first (config, copy, flags), watched for a day; then the queued feature deploys, one per day with a normal maintenance window and rollback plan. The thaw stampede — everyone shipping their two weeks of work on the same afternoon — causes more incidents than the freeze itself.
• Feed the lessons back into the next freeze. One paragraph, appended to the policy itself: what the exception bar got wrong, which lane leaked, whether the windows matched reality. This is the weekly review habit applied seasonally — the policy gets sharper every cycle instead of fossilizing, which is what separates a policy from a document.

6. The one-page template

• Header: freeze windows for this year (dated), the freeze owner, and the channel where freeze notices are posted.
• Lanes: frozen / allowed / emergency — with three named examples each, so nobody has to interpret during the window.
• Exception card: the five lines from section 3, plus the reversal test, plus the single approver.
• Escape hatch: the override sentence from section 4, verbatim, including the retroactive filing rule and the scope ceiling.
• Thaw: the end date, the wave plan, and the owner of the 30-minute review.

Small-team honesty note: a freeze policy is not bureaucracy — it is a pre-agreed “no” that protects the system your customers actually see. If your team is one person, this page still applies; it is just a note in your calendar that says what you refuse to touch in launch week, and why future-you should believe it.

Related: change management checklist · deployment rollback · incident communication templates · on-call compensation policy · severity matrix · maintenance windows When the freeze ends, the DORA delivery metrics will show you exactly what the freeze cost in lead time.

The strongest reason for a freeze is not a date but arithmetic: the error budget policy’s BLOWN state freezes the affected service automatically, and ends it on design evidence.

A freeze and a window are different tools: the maintenance window announcement schedules downtime you chose, the freeze policy blocks changes on dates you chose, and the two stack cleanly around a release.

Flags are the freeze’s quiet loophole and its quiet debt: a behind-a-flag change can ship during a freeze without users seeing it, and the feature flag cleanup checklist keeps the flag list from becoming its own reason for a freeze.

A freeze stops all change; a review filters the risky ones. The change-freeze window policy covers the exceptional windows when nothing ships, while the change advisory board template handles the ordinary weeks when everything ships — reviewed, classed, and logged.

Related: the hotfix process checklist covers the emergency end of the same pipeline — the eight checks that keep a Friday-night deploy fast but not reckless.