Change-Freeze Calendar Template for Small Teams

One page. The windows when nobody ships to production, what still ships inside a freeze, and the exception loop that keeps the freeze honest.

Most change freezes are a mood, not a calendar. Someone says “no deploys until things calm down,” and then the freeze erodes one urgent afternoon at a time — until somebody ships a pricing change at 4pm on December 23 and spends the quietest week of the year on a billing outage. The fix is not a stricter mood. It is one table on the wall: the windows you declare in advance, what is frozen inside each one, what still ships, and who can say yes when something truly cannot wait.

The freeze calendar, one page

A row per window, declared weeks ahead. If a window is not on this table, it does not exist:

Three columns do the real work. “What’s frozen” is a scope, not the word “everything” — a vague freeze is an unenforceable one. “Still ships” is what keeps security clocks running during the freeze. “Break-glass approver” is one named human per window — never a committee, never “ask in the channel,” and never the person asking for the exception.

The four windows most small teams actually declare

Teams of 5–50 rarely need more than four windows a year. Declaring more than that means your regular process is broken — see the maintenance window policy instead, and fix the lanes:

• Peak-season blackout. Your revenue peak is not the time to find out what the new checkout code does. Freeze the whole production surface for the season your customers cannot afford an incident.
• Quarter-close. Finance systems only. The engineering calendar does not stop, but nothing touches billing while the books are closing.
• Migration week. One moving part at a time. Everything else waits until the migration has been stable for a week.
• Event week. Launch, demo, audit, conference. Whatever you would not explain to a customer while it is on fire, do not ship it that week.

The freeze rule, stated as one line

During a declared window, a production change needs one named approver’s yes — the calendar is the policy, the approver is the exception. That is the whole rule. No freeze means “nobody can ever ship”; it means “shipping now costs one conversation with the person whose name is on the row.” A freeze without a named approver becomes a freeze that is broken in the channel by whoever argues hardest.

The exception loop: ninety seconds per request

Exceptions will happen. The loop keeps them rare, fast and logged:

• Ask with three facts: what changes, why it cannot wait until the window ends, and the rollback if it goes wrong. A request without a rollback is a “no” by default.
• Check the calendar row: is the change inside the frozen scope for this window? A billing fix during peak season may be fine; the same fix during quarter-close is not.
• The named approver decides in ninety seconds. Yes, with a time-box (“ship it today, done by 5”), or no, with a slot (“first thing after Jan 3”). No third answer.
• Log it in the row: date, change, approver, outcome. The log is how you audit the freeze — and how you notice that one team asks every single time.

What still ships during a freeze

The “still ships” column exists because some things must not stop:

• Rank-1 security fixes. The severity clocks from the vulnerability remediation plan do not pause for a holiday. A critical patch ships inside a freeze; that is what the approver’s yes is for.
• Rollback-only fixes. If the fix is a revert, it ships. If the fix is a rewrite, it waits.
• Docs, runbooks, monitoring. Writing never took production down. The runbook you improve during the freeze is the one that saves the window after it.
• Patch-lane work that was already scheduled in the patch cadence calendar, if the window’s scope allows it — say so on the row instead of arguing each time.

Three metrics

Thirty seconds a month, in the same review as everything else:

• Exceptions requested vs granted. A healthy freeze grants one in five. Grant nine in ten and the freeze is decoration; grant zero and it is a wall people will route around.
• Incidents traced to a change made just before the window opened. This is the metric that justifies the freeze to skeptics — most peak-season incidents are pre-freeze changes detonating late.
• Windows held. A freeze that silently stops being true is worse than no freeze, because everyone still believes it. The row is updated when the window ends: held, or broken, and why.

Worked example: from a December 23 outage to eleven quiet days

A twelve-person B2B SaaS company. The year before: a founder shipped a pricing-schema change at 4pm on December 23 because “the freeze was just for the engineers.” It corrupted invoicing for one customer segment; nobody noticed until January 2; the billing team started the year with three days of manual repair and one very patient customer.

The next year they declared the window on November 20 — December 18 to January 3, full production scope, still-ships list exactly as above, the on-call lead as break-glass approver. Nine exceptions were requested across the window. Two were granted: both rank-1 security patches, both shipped same-day with the clock documented. Zero production incidents. The pricing change shipped January 6 with a rehearsed rollback, and the on-call rotation got eleven quiet days instead of a forensic accounting exercise. Total process cost: one table, one line in the weekly review, and ninety seconds per exception request.

Where this fits

The freeze calendar sits between the maintenance window policy (the regular lanes that make freezes rare) and the seasonal peak readiness checklist (everything else you do before your busiest weeks). Rollbacks for whatever slips through are rehearsed in the deployment rollback checklist; the incident itself, if it happens anyway, follows the first 30 minutes. If you would rather have the whole change-control loop — windows, lanes, rollback drills, the freeze audit — run by an outside pair, that is the Small-Team Ops Audit; and when a frozen week still manages to catch fire, the Custom Incident Runbook turns the post-mortem into a procedure your team can run without you. The Ops Starter Kit covers the incident half; Vol. 2 covers the on-call rotation that staffs the freeze.