What Is an SLO?

A service level objective is a target value for a service level indicator over a window — for example, 99.9% of requests served successfully within 300ms, measured over 30 days. It sits between the raw measurement and any external promise.

SLI, SLO, SLA

• SLI — the indicator. What you actually measure: success rate, latency percentile, freshness.
• SLO — your internal target for that indicator. Chosen, not discovered.
• SLA — a contractual promise to a customer, usually looser than the SLO so that missing the objective is not immediately a breach.

The error budget is the useful part

A 99.9% objective over 30 days permits roughly 43 minutes of failure. That allowance is a budget, and it converts an unproductive argument into an operational rule:

• Budget remaining — ship features, take considered risks. Reliability work is not urgent.
• Budget exhausted — feature work pauses in favour of reliability until it recovers.
• Budget never consumed — the objective is too strict and is costing velocity for reliability nobody asked for.

Choosing the number

Set it from what users notice, not from how many nines sound impressive. Two questions get you most of the way: at what point does a user abandon the task, and what does the dependency chain make possible? A service built on a 99.9% dependency cannot credibly promise 99.99%.

Measure what users experience

• Measure as close to the user as practical — server-side success rates miss failures that never reached your server.
• Use percentiles, not averages. A mean latency of 200ms hides a p99 of eight seconds, and the p99 is somebody's every request.
• Define 'success' precisely: a 200 response containing an error message is a failure, whatever the status code says.
• Pick a window and hold it. Shifting between 7 and 30 days changes the number without changing reality.

Where SLOs meet AI features

Model-backed endpoints need indicators traditional ones do not cover. Availability and latency still apply, and neither captures whether the answer was right. Teams running LLM features generally end up with a correctness or groundedness indicator scored on sampled traffic alongside the conventional two — with the honest caveat that it is a sampled estimate, not a complete measurement.