SLOs and error budgets
A target, a budget, and a burn rate that pages before the budget is gone.
Analytics → SLO / Budgets turns reliability from an opinion into a number.
The three terms
| Term | Is |
|---|---|
| SLI | The measurement — "the proportion of requests served in under 300 ms" |
| SLO | The target — "99.5% of them, over 30 days" |
| Error budget | What the target allows — 0.5%, which over 30 days is about 3.6 hours |
Why a budget
An error budget turns "how reliable should this be" into a spendable quantity.
- Budget remaining → you can take risks. Ship, experiment, run chaos.
- Budget exhausted → stop shipping features and spend the effort on reliability.
It is a policy both sides of that argument can agree to in advance, which is the only time such an argument can be settled.
Defining one
| Field | Notes |
|---|---|
| Service | |
| SLI | Availability, latency, error rate, or a custom metric |
| Target | 99.9% is three nines. Be honest about what you can hold |
| Window | Rolling 30 days is usual |
Set the target at what the service needs, not at the most impressive number. Every extra nine costs roughly an order of magnitude more effort, and a target you miss every month is not a target — it is a source of noise that everyone learns to ignore.
Burn rate
Burn rate is how fast the budget is being spent relative to the window.
| Burn rate | Meaning |
|---|---|
| 1× | On track to exactly exhaust the budget |
| 14.4× | The whole month's budget in about two hours |
Alerting on burn rate rather than on the raw error rate is the point: it fires when the trajectory matters, and stays quiet when a brief blip does not.
The endpoint guard can derive alert severity from burn rate for the same reason — an endpoint with budget to spare does not need to wake anybody.
Multi-window alerting
The standard arrangement:
| Window | Burn rate | Severity |
|---|---|---|
| 1 hour | 14.4× | Critical — page |
| 6 hours | 6× | High |
| 3 days | 1× | Warning — ticket |
Fast burns page; slow burns become work.
Reporting
SLO status belongs in a scheduled report to leadership. It is the number that makes reliability work legible to people who do not read alerts.
Where this behaviour lives: backend/internal/worker/slo_burn_worker.go, frontend/src/app/slo/. If the code and this page disagree, the code is right — please fix the page.
Part of Analytics and cost — Dashboards, SLOs, reports and what the infrastructure costs.