SLIs, SLOs, and Error Budgets

SLIs, SLOs, and Error Budgets

Overview

Metrics without targets become noise. SLIs measure user-visible health; SLOs set goals; error budgets decide how fast you can ship vs stabilize.

Definitions

Term	Meaning	Example
SLI	Quantitative measure	% of requests < 300ms; success ratio
SLO	Target on an SLI	99.9% success over 30 days
SLA	Contractual promise	Often looser than internal SLO
Error budget	1 − SLO failures allowed	0.1% ≈ budget for risk

Good SLIs for HTTP APIs

availability  = successful requests / total  (exclude 4xx client errors carefully)
latency       = fraction of requests under threshold (p99 or histogram)
freshness     = data lag (async pipelines)

Prefer user journeys (login, checkout) over raw CPU.

Expressing latency as an SLI

With Prometheus histograms:

histogram_quantile(0.99, sum(rate(http_request_duration_seconds_bucket[5m])) by (le))

Or “good events” style:

count of requests with duration <= 0.3s  /  count of requests

Error budget policy (lightweight)

Budget remaining	Engineering posture
Healthy	Ship features, experiments OK
Burning fast	Freeze risky deploys; fix reliability
Exhausted	Reliability work only until recovery

Minimal Go: count success/fail

var (
    reqTotal   = expvar.NewInt("requests_total")
    reqFailed  = expvar.NewInt("requests_failed")
)

// in handler:
reqTotal.Add(1)
if status >= 500 {
    reqFailed.Add(1)
}

Graduate to Prometheus counters/histograms (chapter 162).

Rules of thumb

Do	Don’t
Few SLOs (1–3 per critical UX)	50 red dashboards, zero owners
Align alerts to budget burn	Alert on every CPU blip
Review SLOs quarterly	Set 99.99% with no measurement

Try next

1. Define SLIs for one service (availability + latency).
   
2. Compute monthly error budget from request volume.
   
3. Write a one-page policy: what happens when budget is empty.