SLO, SLI, and SLA
SLIs measure service behavior, SLOs set an internal reliability target, and SLAs define the contractual consequences of missing it.
Definition
A service level indicator (SLI) is a quantitative measure of service behavior, such as the proportion of requests that succeed within a latency threshold. A service level objective (SLO) is an internal target for an SLI over a window, such as 99.9% of requests succeeding over 30 days. A service level agreement (SLA) is a contract with customers that defines commitments and remedies. SLOs should be stricter than SLAs so the team has room to react before a contractual breach.
Context and scope
SLIs, SLOs, and SLAs align engineering work with user experience and business commitments. They are used to prioritize reliability work, define error budgets, and decide when to slow feature delivery to fix stability.
Common misconceptions
- An SLO is a guarantee — it is an internal target, not a promise to customers
- Uptime alone is enough — users experience latency, correctness, and freshness, not only whether the process is running
- A 100% SLO is a good goal — it leaves no room for change and is not economically meaningful
Anti-patterns
- Measuring only server availability while users see errors or slow responses
- Setting an SLO without a measurement source or an owner
- Treating an SLA breach as the first signal of reliability problems
Related concepts
Related examples
Authoritative source
Measure what users experience
An SLI should be defined from the user’s point of view. For an API, a good SLI is the proportion of requests that return a successful response within 300 milliseconds, measured at the edge. Server CPU or process uptime may explain the SLI, but they are not the SLI. A service can be “up” while every request times out.
SLI: successful requests / valid requests, measured over 5-minute windows
SLO: 99.9% over 30 days
SLA: 99.5% monthly, with service creditsThe SLI must have a clear numerator, denominator, and measurement point. “Successful” needs a definition: which status codes, which endpoints, and which client errors are excluded. Changing the definition changes the objective and the error budget.
Set targets that leave room
A 99.9% monthly SLO allows about 43 minutes of full outage, or a larger amount of partial failure, depending on how the SLI is aggregated. A 100% target is not realistic and encourages hiding failures. Choose a target from user tolerance and the cost of reliability, then keep the SLA looser than the SLO.
Review and evolve
SLOs are not permanent. Traffic patterns, dependencies, and product expectations change. Review the SLI definition, the target, and the measurement pipeline regularly. If the team consistently misses the SLO, either reliability work or the target is wrong; investigate before silently lowering it.
When to use it
Use SLIs and SLOs for every user-facing service with a reliability commitment. The advantage is a shared, measurable definition of “healthy”; the drawback is the work of instrumenting and maintaining the measurement. Compared to raw uptime monitoring, an SLO reflects the user experience but requires careful denominator and window design.