Content freeze process
Purpose: Run a content freeze for high-stakes windows (launches, peak trading, audits) without stopping the business.
Who this page is for
| Audience | Why it matters to you |
|---|---|
| Tech leads / content ops | Freeze owners |
| All engineers | What freeze means for deploys |
What a freeze is (and isn't)
A defined window where publication to production is restricted to protect a critical period — annual premium change go-live for PHI, peak campaign, compliance audit. Authors keep working (author tier is unaffected); what changes is what may go live.
Freeze levels
| Level | Allowed to publish | Typical trigger |
|---|---|---|
| Soft | Normal content, no structural/template changes | Pre-launch fortnight |
| Hard | Emergency fixes only, incident-manager approved | Launch week, audit window |
| Total | Nothing (platform change freeze too — no deploys) | Go-live day, peak hour events |
Mechanics
- Announce with dates, level, exception process, and a named freeze owner — before, not during.
- Enforce, don't just request: temporarily withdraw replicate permission from general reviewer groups (a group-membership change, reversible in minutes) — leaving enforcement to memory guarantees a violation.
- Exception path: request → freeze owner + incident-manager style approval → time-boxed permission grant → publish → revoke. Log every exception.
- Launches/scheduled activations already in flight: audit BEFORE the freeze starts (
on/off timesand workflow queues) — the classic freeze-breaker is a scheduled activation nobody remembered. - Engineering side: deploy freeze usually accompanies hard freezes (deployment runbook pre-flight checks for freeze windows).
Exit
Freeze end is an event too: restore permissions, release the queued publications in a controlled order (not a 100-page stampede — dispatcher invalidation storms are self-inflicted), and review exceptions for process holes.