A service level objective, or SLO, is a target value or range for a service level that you measure with a service level indicator (SLI). For example: 99.9 percent of requests succeed over 30 days. It is an internal reliability goal, and it is different from a service level agreement, which carries consequences if missed.
What are SLI, SLO and SLA?
Google's SRE book keeps the three terms apart.
- SLI: a carefully defined quantitative measure of some aspect of the service level provided. Common ones are request latency, error rate and throughput. Availability, the fraction of well-formed requests that succeed, is another.
- SLO: a target value or range of values for a service level measured by an SLI. The book writes it as an SLI at or below a target, or between a lower and upper bound.
- SLA: an explicit or implicit contract with users that includes consequences of meeting or missing the SLOs it contains. The easiest test the book gives: ask what happens if the SLO is not met. If there is no explicit consequence, you are almost certainly looking at an SLO.
OpenTelemetry's primer adds a useful note: a good SLI measures your service from the perspective of your users, and an SLO is how reliability is communicated to the rest of the organization by attaching SLIs to business value.
How do you pick the SLI?
Start from what users notice. For a checkout API, they notice whether the request works and how long it takes. So two SLIs: the fraction of well-formed requests that succeed, and the latency of successful requests. The SRE book recommends percentiles over averages for latency, because a high-order percentile such as the 99th shows a plausible worst case while the median shows the typical case. An average hides the tail that annoys real customers.
The book also admits that the ideal measure is sometimes unavailable. Client-side latency matters most to users, but you may only be able to measure it at the server. A proxy is fine if you know its limits.
What does a first SLO look like?
Constructed example. A team runs a payments API.
- SLI one: share of well-formed requests that return a non-error response.
- SLO one: 99.9 percent over a rolling 30 days. That allows about 43 minutes of full failure in 30 days, since 30 days is 43,200 minutes and 0.1 percent of that is 43.2.
- SLI two: latency of successful requests, 95th percentile.
- SLO two: 95th percentile under 300 milliseconds over the same window.
Then the team checks the numbers against reality. If it already runs at 99.99 percent, a 99.9 target is cheap to keep. If it runs at 99.5 percent, the target is a plan for improvement, and the plan should say who will do the work.
How strict should it be?
The SRE book notes that 100 percent is impossible and that choosing an SLO is complex. You do not always get to choose the value: incoming request volume is set by users, so you cannot put an SLO on it. It suggests two tactics:
- Keep a safety margin. Use a tighter internal SLO than the one you advertise, giving room to react to chronic problems before users see them.
- Do not overachieve. If you are far better than stated, users come to depend on the real performance. Google's Chubby service introduced planned outages in response to being overly available.
How do SLOs relate to security?
Reliability and security share a boundary: a denial-of-service attack is an availability event, and an incident response that takes a service offline spends your budget. Include the security-driven actions in your planning. A patch that needs a restart has a reliability cost, and an SLO helps you weigh that cost against the risk of waiting.
How to check or apply this
- Choose one user journey that matters.
- Define one or two SLIs that reflect what users feel, and use percentiles for latency.
- Set the SLO from observed data and user needs, not from a round number.
- Write down what happens when the SLO is missed, and who decides.
- Keep the SLA, if any, looser than the internal SLO.
- Review SLOs every quarter. Services and expectations change.
- Alert on trends against the SLO, not on every blip.
Quick check
Is an SLO the same as an SLA?
No. An SLO is a target. An SLA is a contract with consequences if the targets are missed.
Why not aim for 100 percent?
It is impossible in practice, and chasing it costs more than users value. Pick the level at which users stop noticing and keep a margin.
Sources
Last reviewed: 18 October 2026.
