Definition
An SLO (Service Level Objective) is an internal reliability target for a service, expressed as a percentage of successful outcomes over a defined time window. It answers the question: "What does good enough look like for this service?"
Example: "99.9% of API requests will return a successful response within 500ms, measured over a rolling 30-day window."
SLOs are internal engineering commitments — they are not contracts with customers (those are SLAs). Their purpose is to give teams a shared, quantitative definition of reliability that can inform engineering decisions.
SLO vs SLA vs SLI
The three terms are related but distinct. An SLI (Service Level Indicator) is the measurement — request success rate, latency, availability. An SLO is the target for that measurement. An SLA is a contractual commitment to customers, typically set more conservatively than the internal SLO.
In practice: SLIs measure, SLOs target, SLAs contract. See SLO vs SLA vs SLI for the full comparison.
Anatomy of a good SLO
A well-formed SLO has four components:
- SLI: The specific metric being measured (e.g. request success rate)
- Target: The threshold that defines success (e.g. 99.9%)
- Time window: The period over which it is measured (e.g. rolling 30 days)
- User journey: The specific service or path the SLO applies to
Vague SLOs ("the service should be fast") are not actionable. Precise SLOs ("p99 latency below 200ms for checkout requests, measured over 28 days") are.
How to set an SLO target
SLO targets should reflect what users actually need — not the maximum reliability you can achieve. Setting an SLO too high wastes engineering resources on reliability improvements users do not notice. Setting it too low trains users to expect poor service and makes SLA negotiations impossible.
Three approaches to calibrate an SLO target: analyze historical performance and set the target slightly below your current best, survey users to understand their pain threshold, or start with an industry benchmark (99.9% for most consumer services) and adjust based on feedback.
SLOs and error budgets
Every SLO implies an error budget — the maximum amount of unreliability permitted within the window. A 99.9% SLO has an error budget of 0.1%, or 43.8 minutes of downtime per 30 days.
Error budgets convert abstract reliability targets into operational policy: when the budget is healthy, teams can move fast. When it is low, reliability work takes priority. When it is exhausted, feature work stops until the budget recovers.
Use the SLO Calculator to compute your error budget from an SLO target, and the Error Budget Calculator to track burn rate in real time.
Common SLO mistakes
Too many SLOs. More SLOs mean more noise and more cognitive load. Most services need 2–4 SLOs that directly reflect user experience — not one for every internal metric.
No policy for SLO breaches. An SLO without a defined response is just a number on a dashboard. Define what happens at 50%, 10%, and 0% budget before the crunch happens.
SLO equals SLA. If your internal SLO matches your external SLA, any engineering slip immediately becomes a contractual violation. Always leave a buffer.
Measuring uptime instead of user experience. A service can be "up" while returning errors on every request. Measure what users experience — successful requests, latency, correct results — not whether the process is running.
SLOs across multiple services
When a user journey spans multiple services, each service SLO contributes to the end-to-end experience. If three services each have 99.9% SLOs, the composite reliability is approximately 99.7%. This is why setting SLOs at the user-journey level — not just the service level — gives a more accurate picture of user experience. See Composite Availability Calculator for the calculation.