sigmashake-docs — Error budget policy
This page describes how the SLO budget would guide changes to the docs site.
SLOs themselves live in docs/slo.toml.
Note 2026-10-11: an earlier version of this page described automated burn-rate
alerting, a chat-channel notification, a response team, a sprint allocation and a
postmortem duty. None of these exist. The docs site is a static Pages site with no
runtime Worker. No code emits the metrics named in slo.toml. The text is rewritten
to match the paging policy.
Status
- No automated burn-rate alerting exists.
- The SLOs in
slo.tomlare aspirations. Nothing measures them today. - One role, the ISMS owner, responds. See
docs/paging-policy.md. No paging vendor, no escalation path, no acknowledgement time and no 24/7 coverage exist.
Definitions
- Budget =
(1 - target) × window_seconds. For the headline availability SLO (target 99.9%, 28-day window), that is about 40 minutes of error time per window. - Burn rate =
actual_error_rate / budget_error_rate. A burn rate of 14.4 consumes a 28-day budget in two days.
Burn-rate response matrix (reference, applies only if a measurement is added)
This matrix shows what the ISMS owner would do if a burn rate were measured. No system computes a burn rate today.
| Burn rate (1h avg) | Burn rate (6h avg) | Severity | Response |
|---|---|---|---|
| ≥ 14.4 | ≥ 6 | P1 | The ISMS owner investigates as soon as possible (best effort; see the paging policy). Deploys that touch the affected surface wait until burn returns < 1. |
| ≥ 6 | ≥ 3 | P2 | The ISMS owner reviews in normal working time. Risky changes wait. |
| ≥ 3 | ≥ 1.5 | P3 | The ISMS owner reviews the trend in normal working time. |
| < 3 | < 1.5 | Healthy | Normal operations. |
The two-window rule (1h + 6h) is the Google SRE practice. It avoids false positives from a single spike.
Deploy hold
When the ISMS owner sees a P1 condition:
- The current deploy is allowed to finish.
- The ISMS owner approves each new deploy to the affected surface.
- The ISMS owner holds migrations, if any exist.
Budget exhaustion
If a budget is fully consumed in the 28-day window, the ISMS owner holds the affected surface, except for a fix to the burning SLO. The ISMS owner records the cause in the incident record.
Manual override
The ISMS owner may declare a budget waiver for a specific deploy when:
- The deploy is a fix for an actively burning SLO, OR
- The deploy is a customer-blocking security patch.
This static Pages site has no audit log of its own. State the waiver and its reason in the commit message of the deploy. Git history is the record.