30.4 What are SLI, SLO and SLA?

Targets and alerts

In the car: The car measures kilometres driven (what you measure). The manufacturer recommends a service every 10,000 km (your target). The warranty says they'll fix it free if it breaks within 3 years (the contract, with consequences).

In the system:

• SLI (Service Level Indicator): a measurement of how users experience the service, usually a ratio of good events to all events. "Fraction of checkouts that succeed within 2 seconds."
• SLO (Service Level Objective): the target for an SLI over a window. "99.9% of checkouts succeed within 2 seconds, measured over 30 days."
• SLA (Service Level Agreement): a contract with customers or partners, with consequences (credits, refunds) if missed. "99.5% monthly, or partners get credits." SLAs are usually looser than internal SLOs, so you notice and fix problems before you owe anyone money.

Figure: measure what users feel, set a target, and treat the gap as a budget.

Choosing good SLIs:

• Measure what users feel, ideally at the edge (load balancer or client), not internal CPU.
• Availability SLI: good requests ÷ valid requests (exclude 4xx caused by bad input).
• Latency SLI: requests faster than a threshold ÷ all requests ("99% under 2 s"), rather than "average latency".
• Per user journey: browse, search, add to cart, checkout. Not every endpoint needs one.

Don't aim for 100%: it's impossibly expensive, and users can't tell 99.99% from 100% through their own flaky Wi-Fi.

Memory code: "Measure the kilometres, promise the service interval, sign the warranty looser."

---