1 open incident
Checkout API — SLO “Checkout Latency” is RED
View details

Freeze windows (Black Friday, month-end, tax season)

Protect key business periods by automatically blocking or tightening deployments during high-risk dates like Black Friday, product launches, month-end, or tax season.

Hard freeze

Completely block non-emergency deployments during a freeze window. Ideal for Black Friday or big marketing events where stability is more important than shipping new features.

  • Safe-to-Deploy returns blocked due to freeze.
  • CI/CD jobs fail fast with a clear reason.
  • Only emergency break-glass paths can override.
Soft freeze

Allow deployments, but with stricter risk rules and human approval. Great for “sensitive but not totally blocked” periods.

  • Higher bar for risk score and SLO health.
  • May require an explicit approver before rollout.
  • Still logs decisions for audit & post-mortems.
How your team configures freeze windows

Freeze windows are managed through the web UI by organisation admins or risk policy managers. You define the calendar, and the platform enforces it in Safe-to-Deploy decisions.

  1. Open the Deployment Risk Policy / Change Freezes section in the settings area of the platform.
  2. Click “Add freeze window” and choose:
    • Start date & time
    • End date & time
    • Scope (service, environment, or organisation-wide)
    • Freeze type: Hard freeze or Soft freeze
  3. Optionally add a business label (e.g. “Black Friday 2025”, “Q4 tax week”) so reports and dashboards stay readable.
  4. Save the window. From that point on, any Safe-to-Deploy check that falls inside the freeze window will take the freeze rules into account.
Who can change freezes?
Only organisation admins or users with the Risk Policy Manager permission should create or edit change freezes. Engineers and on-call responders will see the results in their deployment logs without needing access to the settings.
What Safe-to-Deploy returns during a freeze

Once a freeze window is active, Safe-to-Deploy decisions automatically reflect it so CI/CD can react without custom logic in each pipeline.

  • For a hard freeze:
    • safe = false
    • reason = "Blocked due to active change freeze"
    • Risk level is reported as blocked.
  • For a soft freeze:
    • Higher risk sensitivity (SLO burn, error rate, etc.).
    • May return “allowed with warning” and expect approval.
  • Emergency / P1 paths can be configured to bypass or require a special approval flag, depending on your policy.

From the CI/CD side, teams simply call the Safe-to-Deploy API as usual. The response already includes whether a freeze is in effect and why a deployment is blocked or restricted.

Typical examples
  • Black Friday: Hard freeze on all production deployments from Friday 00:00 to Monday 08:00, except emergency fixes.
  • End-of-month billing: Soft freeze on billing services; deployments allowed only if risk is low and approval is granted.
  • Regulatory reporting week: Hard freeze on data-critical systems, soft freeze on supporting internal tools.
← Back to Safe-to-Deploy cockpit