Deploy Freezes vs Deploy Windows: Pick the Right Tool

Freezes prevent deploys; windows time them. The decision rule for picking, and the case where teams use the wrong one.

When to freeze

Freezes are blunt. Use them when the cost of a bad deploy spikes for a finite period and any deploy is unwise.

Major customer event. Big launch, peak shopping window, regulator filing day; any deploy risk concentrates here.
Post-incident stabilisation. 24 to 72 hours after a serious incident while the patch settles and analysis runs.
Holiday weekend. Skeleton on-call, slow customer response; the cost of a bad deploy multiplies.
Time-bounded. Always 24 to 72 hours; longer freezes erode delivery rate without proportionate safety gain.

Windows are the steady-state tool. They time deploys without preventing them, matching deploy rhythm to staffing reality.

Normal operations. Predictable risk patterns; staffing, not absolute risk, is the constraint.
Business hours. Deploy between 9 AM and 4 PM when the team is awake; the on-call has backup.
Permanent. The window is a daily rhythm, not an exception; engineers plan around it.
Region-aware. Distributed teams need windows that overlap with at least one full team's working hours.

Picking the wrong tool is more common than picking neither. Three mismatches recur and each has a measurable consequence.

Permanent freezes that should be windows. Change debt accumulates; the eventual deploy is huge and risky.
Windows where freezes belong. Permissive window during a real-risk period; deploys go through that should not.
Overlapping policies. Multiple freezes and windows in effect; confusion about what is current; deploys happen on gut feel.
Unwritten policy. The rule lives in someone's head; new engineers ship at the wrong time and discover the policy via incident.