The No-Deploy Window Policy That Actually Helps

Most no-deploy windows are theatre. The four rules that make them genuinely protective without becoming an excuse not to ship.

When freezes are warranted

Freezes only earn their cost when the risk profile genuinely changes for a finite period. Three classes meet that bar; everything else is theatre.

Major customer events. Black Friday, product launch, regulator filing day; the cost of a bad deploy spikes here.
Post-incident stabilisation. Right after a serious incident; the team needs time to absorb learnings before adding new risk.
Holiday weekends. Low-staffing windows; reduced response capacity makes new bugs disproportionately painful.
Compliance-driven. Some regulated workloads have audit-window freezes baked in; treat those as policy, not judgement.

Four discipline rules keep the freeze useful instead of corrosive. Skip any one and the policy becomes a weapon used against teams trying to ship.

Time-bounded. 24 to 72 hours, never weeks; longer freezes destroy delivery rate without proportionate safety gain.
Critical-fix exemption. Define 'critical' explicitly with examples; 'we want this in' is never critical.
Written bypass approval. Bypass needs written, logged approval from a named approver; no Slack-emoji-driven exceptions.
Post-freeze review. List what was bypassed and why; if bypass was frequent, the policy is wrong.

Three patterns turn a freeze policy into a liability. Each one looks reasonable in isolation; together they make the policy worse than no policy.

Permanent freezes. 'No deploys after Thursdays' compounds change debt; teams develop workarounds that are worse than the original risk.
Vague freezes. 'Be careful' produces inconsistent behaviour; the policy should be a hard rule or no rule.
Freezes without monitoring. Frozen deploys do not freeze incidents; staffing and observability must remain.
Hidden policy. Policy lives in a wiki nobody reads; new engineers ship at the wrong moment and learn the rule via incident.