A freeze that never actually triggers isn't a policy, it's decoration. We tracked ours for a year to see if it meant anything.

We wrote an error budget freeze policy a year ago and then quietly wondered whether it had ever actually stopped anyone from shipping anything.

Audit whether the freeze ever bites

We pulled every week in the last year where a service crossed its freeze threshold and checked whether any deploy to that service was actually blocked or delayed as a result. In four of eleven qualifying weeks, deploys went out anyway with no recorded exception — meaning the policy was being silently ignored, not overridden through the proper process.

from slo_burn
| where cumulative_burn_pct >= 100
| summarize freeze_weeks = count() by service
| join kind=leftouter (deploys | where approved_exception == false) on service and week
| where isnotnull(deploy_id)
| project service, week, deploy_id, deploy_owner

Make the freeze technically enforced, not just documented

A policy that depends on everyone remembering and choosing to comply will eventually get skipped under deadline pressure, exactly when it matters most. We wired the freeze state into the deploy pipeline itself — a frozen service requires an explicit, logged override flag to deploy at all, rather than trusting a Slack announcement to be read and honored.

Review freeze frequency, not just freeze compliance

A service that freezes every single month isn't disciplined, it's chronically over budget, which is a different problem than a policy-compliance problem. We now flag services with three or more freezes in a rolling six months for a deeper reliability investment conversation, separate from the weekly freeze-compliance check.

Give the override a real cost, not just a log entry

Logging an override is necessary but not sufficient — we found that once a service had overridden its freeze once, doing it a second time felt easier, and a third time felt routine. We added a rule that a second override within the same 30-day window requires sign-off from a director rather than a VP, which raised the friction just enough to make the second ask genuinely deliberate instead of a rubber stamp.

  • Audit whether your freeze policy has ever actually blocked a deploy — don't assume.
  • Wire the freeze into the deploy pipeline technically, not just as a documented rule.
  • Require a logged override flag for any deploy to a frozen service.
  • Escalate the approval bar for repeat overrides within the same window.
  • Flag chronically-freezing services for a reliability investment conversation, not just compliance.