TOPIC 01 — MEASUREMENT
SLIs, SLOs & SLAs
Reliability starts with a question: what do users actually experience? The SLI/SLO/SLA framework turns that question into numbers you can engineer against.
The three terms, untangled
SLI
Indicator. A carefully chosen measurement of service behaviour. Usually a ratio: good events ÷ total events.
SLO
Objective. A target value for an SLI over a time window. Your internal promise: “99.9% of requests succeed, measured over 30 days.”
SLA
Agreement. An external, contractual promise with penalties (refunds, credits) if broken. Set by business + legal, not just engineering.
The relationship is a chain: SLIs feed SLOs, and SLOs sit safely inside SLAs. If your SLA promises 99.5%, your internal SLO might be 99.9% — the gap is your safety margin. You want to notice trouble long before lawyers do.
What makes a good SLI?
A good SLI rises and falls with user happiness. “CPU utilisation is 80%” tells a user nothing; “0.2% of checkout requests failed in the last hour” tells them everything. Most good SLIs are expressed as a percentage:
SLI = (good events / valid events) × 100% — define “good” and “valid” precisely, and the rest of the framework falls into place.
Different service types call for different indicators:
| Service type | Typical SLIs | Example |
|---|---|---|
| Request / response (APIs, websites) | Availability, latency, quality | “99% of home-page requests return in < 300 ms” |
| Data pipeline | Freshness, correctness, coverage | “95% of records processed within 10 minutes of arrival” |
| Storage | Durability, availability, latency | “99.999999999% of objects survive a year” (the famous 11 nines) |
| Batch / scheduled jobs | Throughput, completion time | “Nightly billing run completes before 06:00 in 99% of runs” |
Measure at the user, not the server
Where you measure matters. Server-side logs miss requests that never arrived; load-balancer metrics are a good middle ground; client-side telemetry is closest to the truth but noisiest. Start with the load balancer and refine from there.
Setting SLO targets that don't hurt you
- Start from reality, not aspiration. Measure current performance for a month — your first SLO should be roughly what you already achieve.
- Don't chase 100%. Users can't tell 99.999% from 100%, but your team absolutely can. Every extra nine roughly 10×'s the cost.
- Use a rolling window. 28 or 30 rolling days beats calendar months — no “budget reset” cliff at month end.
- Fewer is better. Two or three SLOs per user journey. If everything is an SLO, nothing is.
- Revisit quarterly. SLOs are living targets: tighten them when you consistently beat them, loosen them when they cause pointless pages.
Your users' experience is bounded by their own ISP, device, and Wi-Fi. If your users reach you through infrastructure that's 99.9% reliable, a 99.999% backend buys them nothing.
A worked example
Say you run a checkout API. A complete SLO definition looks like this:
SLI (availability): proportion of HTTP requests returning non-5xx, measured at the load balancer
SLI (latency): proportion of requests served in < 400 ms
SLO: 99.9% availability AND 95% of requests < 400 ms, over rolling 30 days
Error budget: 0.1% ≈ 43 min of full downtime per month
Notice the two-part SLO: fast and available. A service that returns errors instantly is not “fast”, and a service that answers correctly after 30 seconds is not “available” in any way users care about.
Common pitfalls
- Averaging latency instead of using percentiles — one slow tail hides behind a healthy mean. Track p95/p99.
- Setting SLOs on causes (CPU, memory, queue depth) instead of symptoms users feel.
- Copying another company's targets — their users, architecture, and money are not yours.
- Treating the SLO as a floor to be beaten forever — over-delivering trains users to expect reliability you never promised.
- Writing an SLA tighter than your SLO. That's signing up to pay refunds before your own alarm goes off.