{
  "uid": "cogitave.learn.reliability-and-sre.slos-and-error-budgets",
  "kind": "moduleUnit",
  "href": "/modules/reliability-and-sre/slos-and-error-budgets/",
  "title": "SLOs and error budgets",
  "summary": "",
  "type": null,
  "products": [],
  "roles": [],
  "levels": [],
  "subjects": [],
  "headings": [
    "Set the SLO from the user's journey",
    "Compute the error budget and the burn rate",
    "Alert on the burn, page on the symptom"
  ],
  "source": "The [reliability standard](../../../../standards/docs/standards/reliability.md)\n(section 2) builds on the SLI menu that\n[observability](../../../../standards/docs/standards/observability.md) already\ndefines - latency, error rate, availability - and adds **how to set the SLO and\nhow to alert on it** so it is an operable contract, not a vanity number.\n\n## Set the SLO from the user's journey\n\nAn SLI measured on infrastructure (\"CPU < 80%\") tells you nothing about whether a\nuser succeeded. Each service **must** define its SLOs from **user-facing SLIs** -\nthe success of the **critical user journey**, the thing a customer would open a\nticket about - expressed as `good events / valid events` over a rolling 28- or\n30-day window. Every user journey needs at least one SLO with an owner and a\ntarget, reviewed **quarterly** and re-tuned to observed reality.\n\nA new service ships with three SLOs minimum - availability, latency (p99 of the\njourney), and correctness/error-rate - at one of three inherited tier targets:\n\n| Tier | Target | Monthly budget |\n|---|---|---|\n| Tier-1 (customer-facing, revenue-path) | 99.9% | ~43 min |\n| Tier-2 (important internal / async) | 99.5% | ~3.6 h |\n| Tier-3 (batch / best-effort) | 99.0% or an explicit no-SLO note | - |\n\n## Compute the error budget and the burn rate\n\nThe **error budget** is `(1 - SLO) x valid events in the window`, tracked as\nbudget remaining - a percentage and an absolute - and exposed as a queryable Core\nfact. Worked example: at **99.9% over 30 days**, the budget is 0.1%, or **~43\nminutes** of allowed downtime.\n\nThe **burn rate** is how fast that budget is spent: rate `1.0` spends the whole\nmonth's budget in exactly a month; rate `14.4` spends it in about 50 hours.\n\n## Alert on the burn, page on the symptom\n\nA single threshold either pages too late (a slow burn eats the month silently) or\ntoo often (every blip wakes someone). SLO alerts are therefore **burn-rate**\nalerts using **paired long+short windows** - the long window sets severity, and a\nshort window at the same threshold must **also** fire, so a recovered spike never\npages:\n\n| Long window | Burn rate | Budget spent | Action |\n|---|---|---|---|\n| 1 h | 14.4x | 2% in 1 h | page |\n| 6 h | 6x | 5% in 6 h | page |\n| 24 h | 3x | 10% in 1 day | ticket |\n| 72 h | 1x | 10% in 3 days | ticket |\n\nThe anti-fatigue rule is strict: a service **must not** page on a metric outside\na user's SLO - cause-based alerts (a disk filling, a pod restarting) are tickets\nor dashboards, never pages, unless they themselves burn an SLO.\n\n> [!NOTE]\n> Every default above is exactly that - a default. Shipping a different tier\n> target, window, or burn-rate ladder for a service is a **design-class\n> deviation** that needs an Accepted RFC recording the service, the dimension,\n> the chosen value, and the approver.\n",
  "partOf": "cogitave.learn.reliability-and-sre",
  "durationInMinutes": 8,
  "quiz": null
}