SLO design cheatsheet

Write it down

Copy template

SLO: [service], [user journey]
SLI: good = [e.g. non-5xx in under 300 ms]
     valid = [e.g. all requests except auth failures]
     measured at [load balancer / probe / client]
Target: [99.9]% of valid events over a rolling [28] days
Why: [what users need; the data the target came from]
Alerts: multiwindow burn-rate rules; page [team]
Policy: [link to error budget policy]
Owners: [engineering lead], [product lead]
Review: [quarterly]; last reviewed [date]

SLI vs SLO vs SLA

Pick the SLI

SLI = good events ÷ valid events

• Express latency as the share of requests faster than X, not as a percentile.
• Combine instances by summing good and valid events, then dividing. Never average ratios or percentiles.
• Measure as close to users as you can afford: load balancer before application metrics, probes for critical journeys.
• Few events? One failure can page. Use a binomial-test threshold, a minimum request count, or synthetic traffic.

Latency percentiles

Set the target

• Never 100%. It is unachievable and leaves no budget for change.
• Start from history, then ask what users need. Round four weeks of data down; history is a starting point, not the target. Start loose and tighten.
• Check dependencies. 3 hard dependencies at 99.95% cap you at about 99.85% if they fail independently, before your own failures. Redundancy or graceful degradation raises it.
• Keep an SLA looser than the SLO, so the SLO warns you first.
• Just enough SLOs to cover what users care about; one to three per journey is a starting point. Drop any whose miss would change no decision.

Production readiness review

Budget per target

Times are full outage at steady traffic. “Per 1M” is failed requests allowed per million; a request-based SLO counts those, not minutes.

Availability table

Window and alerts

• Rolling four weeks (28 days) is a good default: rolling matches user experience; whole weeks keep weekends constant. Calendar months suit reporting.

burn rate = error rate ÷ (1 − SLO)

• Burn for 28 days; “30 d” is the Workbook’s 30-day figure. Fire when both windows exceed burn × (1 − SLO).
• For a latency SLO, use its own budget: at 99%, a 13.44× page fires at 13.44% slow requests, not 1.344%.
• Below 92.55%, the 13.44× page can never fire; rely on the slower alerts.

Burn-rate alerting Calculate for your SLO

Policy and review

• One incident spending over 20% of the budget gets a postmortem with at least one top-priority action item.
• Review regularly. SLO met but users unhappy: tighten it, or fix the SLI if it misses what users see. SLO missed but users happy: loosen it.

Error budget policy