A service level objective, or SLO, is a target you set for how reliable a service should be, expressed as a specific number over a specific time window — for example, 99.9% of requests should return successfully within a rolling 30-day period. It sounds simple, but the value of an SLO comes entirely from the discipline around it: picking a metric that reflects what users actually experience, setting a target that is realistic, and treating the resulting error budget as a tool for decision-making rather than a scoreboard.
What changed in 2026
- SLO tooling consolidated into existing observability platforms. Most major monitoring vendors now ship SLO tracking, burn-rate alerting, and error budget dashboards as a standard feature rather than a separate product.
- Burn-rate alerting became the default alerting pattern, replacing static threshold alerts in more mature SRE practices, because it catches both fast and slow degradations against the budget.
- User-journey SLOs gained traction over pure infrastructure metrics, with more teams tracking objectives tied to specific critical flows (checkout, login) rather than only service-wide uptime.
SLI, SLO, and SLA: how they relate
These three terms get used interchangeably, which causes real confusion. An SLI (service level indicator) is the actual measurement — request success rate, latency at a percentile, and so on. An SLO is the target you set for that SLI. An SLA (service level agreement) is a contractual promise, often to a customer, usually set looser than your internal SLO so you have room to notice and fix problems before you breach a contract.
SLI: 99.95% of requests succeeded in the last 30 days (the measurement)
SLO: 99.9% of requests should succeed in a 30-day window (the internal target)
SLA: 99.5% uptime guaranteed to customers (the external promise)
How to choose a good SLI
A good SLI reflects what the user actually experiences, is measurable with reasonable engineering effort, and is stable enough that changes to it reflect real reliability shifts rather than noise. Request success rate, latency at p95 or p99, and availability of a critical user journey (like checkout completing end to end) are common choices. Avoid picking metrics just because they are easy to collect if they do not track user pain.
Setting the target and the error budget
| Element |
What it is |
Example |
| SLI |
The raw measurement |
99.94% success rate this month |
| SLO |
The target for that SLI |
99.9% success rate, 30-day window |
| Error budget |
100% minus the SLO |
0.1%, roughly 43 minutes of downtime per month |
| Burn rate |
How fast the budget is being consumed |
10x burn rate = budget exhausted in 3 days |
The error budget is the useful part. If you are within budget, ship features and take risks. If you are burning through it fast, that is the signal to pause and stabilize, without anyone needing to have an opinion — the number makes the call.
Common pitfalls
Setting an SLO too aggressively (99.99% for a service that has never approached that) creates a permanent state of "failure" that nobody trusts. Setting too many SLOs spreads attention thin and makes burn-rate alerts noisy. And measuring an SLI that does not reflect real user pain — like server-side uptime when the actual failures are in a third-party dependency — produces green dashboards during real outages.
FAQ
How is an SLO different from an SLA?
An SLO is an internal target used for engineering decisions. An SLA is an external, often contractual, commitment — typically set looser than the internal SLO to leave a safety margin.
How many SLOs should a service have?
Most teams do better with three to five that map to real user journeys than a long list covering every metric available. Fewer, well-chosen SLOs get more attention.
What happens when you exceed your error budget?
Convention varies by team, but a common pattern is to freeze new feature releases and prioritize reliability work until the burn rate drops and budget recovers.
Do SLOs replace on-call alerting?
No — they complement it. Burn-rate alerts derived from SLOs are often used alongside more traditional alerting for acute incidents.
Where to go next