slo-and-error-budgetslisted

# SLOs and error budgets An SLO exists to answer one question: **is the service reliable enough that we should keep shipping features, or should we stop and fix reliability?** If a number cannot drive that decision, it is a dashboard metric, not an SLO. ## SLI: measure what the user experiences A good SLI is a ratio of **good events / valid events**, measured as close to the user as you can get. | Type | Good events | Where to measure | | --- | --- | --- | | Availability | requests without a 5xx | load balancer / gateway, not the app | | Latency | requests served faster than a threshold | same | | Quality | responses served without degradation (fallback, stale) | app, explicitly tagged | | Freshness | records processed within N minutes of arrival | pipeline output | | Correctness | records passing a validation check | reconciliation job | Rules that matter: - **Measure at the edge.** CPU, memory, and pod restarts are causes, not experience. A service can be 100% "up" by those and completely broken. - **Latency SLIs are thresholds, not averages.** "99% of requests < 300ms" is actionable; "p99 latency" as a raw number is a metric you can't budget against. Averages hide exactly the tail you care about. - **Define "valid".** Exclude what the user caused (4xx from bad input) and count what you caused. Be explicit — this line is where SLOs get gamed. - **Per user journey, not per service.** "Checkout completes" beats "payment-svc returns 200" — the user doesn't care