Skip to content

08. Change windows and freezes

Communication is per-release. Change windows and freezes are the broader operational discipline that governs when releases happen at all. The discipline avoids the Friday-afternoon catastrophe and respects organisational rhythm.

A platform engineer at a Bengaluru SaaS company ships a model migration at 17:30 IST on a Friday. The canary develops issues at 22:00; the on-call team is reduced (weekend staffing); rollback takes longer than expected; customer impact extends through Saturday morning. The postmortem identifies the timing: shipping on a Friday evening with reduced staffing was the contributing factor. The team adopts change windows: routine releases ship Monday-Thursday morning IST; non-routine releases require explicit approval; freeze windows protect critical periods (end of quarter, holidays, marketing campaigns).

This chapter is the change window discipline.

What change windows are

Change windows define the time periods during which releases are normally permitted; freezes define periods when non-critical changes do not ship.

The two together govern release timing. Routine releases respect the windows; emergencies override per chapter 10.

The standard window

A reasonable default:

  • Monday-Thursday, 10:00-15:00 local time. Full staffing; sufficient time for canary to mature within the workday; same-day rollback capacity.

Why these constraints:

  • Monday-Thursday: Friday changes that develop issues extend into weekend reduced-staffing.
  • 10:00-15:00: Morning slot allows the canary's first hours during full attention; afternoon allows promotion and post-promotion monitoring within the workday.
  • Local time: "Local" is where the on-call is; for global platforms, the window may be per-region.

Releases outside the window require explicit approval — a senior engineer or platform lead.

Freeze periods

Periods when non-critical changes do not ship:

  • Public holidays. Reduced staffing; customer fatigue with notifications.
  • End of quarter. Sales pressure; high customer attention; bad time for surprises.
  • Marketing campaigns. A major campaign is running; product changes risk distracting from or contradicting the campaign.
  • Major customer events. A large customer's launch, conference, or onboarding.
  • Provider deprecations approaching. A model retirement is imminent; the team is focused on the migration; other changes are deferred.

Freezes are announced in advance with clear start/end dates. Critical changes (security, compliance, urgent incident response) can still ship during freezes with approval.

What "critical" means for freeze override

The bar for shipping during a freeze:

  • A security vulnerability that warrants immediate fix.
  • A regulatory deadline that cannot be missed.
  • An incident in progress that requires the change to resolve.
  • A customer-blocking bug that customers cannot work around.

Routine improvements, optimisations, new features — these wait. The discipline prevents "this is small, let me just push it" creep that erodes the freeze.

Per-platform tuning

The standard window and freeze rules are starting points. Different platforms have different patterns:

  • Consumer platforms with weekend spikes may have a wider freeze around weekends.
  • Enterprise platforms with month-end batch processing may freeze around month-end.
  • Healthcare platforms during regulatory inspection periods may have specific freezes.
  • Multinational platforms across timezones may have multiple windows per region.

The platform's specific patterns determine the policy. The discipline is to have a policy, document it, and respect it.

How the discipline is enforced

Soft enforcement: documented policy, peer reminders, weekly release review.

Hard enforcement: CI checks that block release outside windows (with bypass for approval), automation that prevents merges during freezes (with bypass for emergencies).

Most platforms use soft enforcement initially; hard enforcement when the soft discipline has not been sufficient.

When the window is too narrow

A team that finds the window genuinely insufficient (changes pile up; releases bunched at the window start; staff working overtime to fit) should reconsider:

  • Is the window too narrow for the team's release cadence?
  • Are too many changes "material" that could be deferred?
  • Is the canary discipline too slow for the workday?
  • Is the team's release frequency too high for the platform's needs?

The window is a constraint that surfaces the question. The answer is platform-specific.

Common mistakes

No windows. Releases happen any time; some hit reduced staffing; weekend incidents.

Windows ignored. The discipline exists in documentation; the team ships when convenient.

Freezes for vague reasons. "Things are busy" freezes that drift; the discipline erodes.

Hard enforcement without bypass. Emergencies cannot ship; security fixes blocked.

Per-team windows without coordination. Multiple teams ship simultaneously, exhausting on-call capacity.

Interview Q&A

Q1. Why Monday-Thursday 10:00-15:00 as the default window? Friday changes that develop issues extend into weekend reduced-staffing. Morning slot allows the canary's first hours during full attention. Afternoon allows promotion and post-promotion monitoring within the workday. Same-day rollback capacity. The window is a structural defence against the chapter-opening Friday-evening pattern. Tune per platform; the principle is "ship when the team can respond." Wrong-answer notes: "any time is fine if the team is good" misses the systemic vulnerability.

Q2. The team has a freeze period for end-of-quarter. A small prompt change wants to ship. What is the discipline? Wait. The change is routine; the freeze protects critical organisational periods from unnecessary surprises. The change ships after the freeze ends. Critical changes (security, compliance, incident response) can override with approval; routine changes do not. The discipline prevents "this is small" creep that erodes the freeze entirely. The team's velocity is slightly lower during freezes; the organisational stability is the trade. Wrong-answer notes: "ship it; it's small" produces the creep that defeats the freeze.

Q3. The team feels the change window is too narrow. What questions do you raise? Is the volume of changes too high for the platform's blast tolerance? Are too many changes "material" when smaller bundles would be safer? Is the canary discipline too slow, forcing changes to start the window with no buffer? Is the team trying to ship too aggressively for the platform's maturity? The window is the constraint that surfaces the question; the answer informs whether to widen the window or rebalance the work. Wrong-answer notes: "widen the window because it's restrictive" misses the systemic question.

Q4. The team's CI hard-enforces the change window. An emergency security fix needs to ship at 16:00 on a Friday. What is the discipline? The bypass path: senior engineer approval; the bypass is documented; the on-call coverage for the weekend is verified; the change ships with the discipline still observed (canary, monitoring, etc.) compressed appropriately. The hard enforcement prevents routine creep; the bypass allows emergency. The post-release reflection asks: was this truly emergency, or could it have waited? Frequent bypasses suggest the enforcement is misaligned with the work. Wrong-answer notes: "no bypass possible" produces a security vulnerability staying open through the weekend.

What to do differently after reading this

  • Establish a change window appropriate to the platform.
  • Define freeze periods around critical organisational events.
  • Document the policy; enforce softly initially, hardly if discipline decays.
  • Have a documented bypass path for emergencies.
  • Reflect on bypass patterns; tune the policy if frequent bypasses occur.

Bridge. Change windows govern when individual changes ship. The next discipline is coordinating when several changes ship together. → 09-coordinated-multi-change.md