By the Octri team · Updated
SLA vs SLO vs SLI: definitions, 99.9% uptime math and error budgets
The word reliable becomes difficult to use once an engineering team and a customer are asked to agree on what it means. One person may be thinking about uptime, another about requests completing under 300 milliseconds, and a third about the credits owed when a service misses its promise.
SLI, SLO, and SLA give those conversations separate terms. They describe a measurement, an engineering target, and a contractual commitment. The distinctions matter most when a service starts missing its target and somebody has to decide what to do next.
What is the difference between an SLA, an SLO and an SLI?
An SLI, or service level indicator, measures the user experience: the percentage of valid requests that succeed, or the share of calls completed under a latency threshold. An SLO, or service level objective, is the target for that indicator over a defined period. An SLA, or service level agreement, is a contractual commitment, often with remedies such as credits when specific promises are missed.
| Term | Example for an orders API | What follows if it's missed |
|---|---|---|
| SLI | 99.83% of eligible requests succeeded | It tells the team what happened |
| SLO | 99.9% succeed over a rolling 30 days | Engineering changes priorities |
| SLA | 99.5% monthly availability in the contract | A customer may qualify for service credits |
The exact definition of an eligible request matters. Do you count a customer sending invalid input as downtime? Do you count a response that arrives after the caller's deadline? Write those rules before showing percentages to anyone.
How much downtime does 99.9% allow?
For time-based availability, multiply the measurement window by the permitted failure fraction. A 99.9% target permits 0.1% of the time to be unavailable.
| Availability | Allowed downtime in 30 days |
|---|---|
| 99% | 7 hours, 12 minutes |
| 99.5% | 3 hours, 36 minutes |
| 99.9% | 43 minutes, 12 seconds |
| 99.95% | 21 minutes, 36 seconds |
| 99.99% | 4 minutes, 19 seconds |
For request-based availability, the same principle applies to eligible calls instead of minutes. At a million requests per month, a 99.9% success SLO gives you a budget of 1,000 bad requests. This is often a better representation of customer impact than simple uptime minutes, because the busiest hour affects more users than a quiet one.
One month of error budget
The error budget is the difference between perfection and your SLO. A service that makes 500,000 eligible requests at a 99.9% target can spend 500 failures during the month. If a release causes 800, the budget is exhausted even if the API never goes completely offline.
The consequences should be agreed on ahead of time. Google published a concrete example in an article about its escalation policy, written by Alex Bramley and Will Tipton. They shared a lightly edited policy from a Google SRE team supporting a group of high-traffic services.
In that policy, a service that remains out of SLO for at least a week after earlier escalation, with its 30-day error budget exhausted, can enter a period where only targeted fixes are released. Normal feature releases resume when reliability returns. At more severe thresholds, the policy allows escalation to leadership and even withdrawal of SRE support for an unsustainable SLO.
This was an operational policy from a real team, not a story about one named outage. It makes the reason for error budgets tangible: the number is a way for engineers and product teams to decide when reliability work takes precedence over shipping more features.
Burn rate: alerting on an SLO
Budget consumption becomes especially useful when you ask how quickly the service is spending it. A 99.9% success target permits a bad-request fraction of 0.001. If 2% of requests fail for five minutes, the system is burning budget at 20 times its sustainable rate.
burn rate = observed error rate / (1 - SLO)
= 0.02 / 0.001
= 20A fast-burn alert should page because it threatens the budget quickly. A slow-burn rule can create a ticket for a smaller regression that would otherwise remain unnoticed for days. The Google SRE Workbook describes multiwindow approaches to make these alerts both timely and less noisy.
How to choose your SLOs
Start with a user action, not a convenient infrastructure number. For a payments API, successful authorization and a bounded response time may matter more than whether one container is running. For a background export API, a job-completion SLI might be more meaningful than request latency.
Choose a target from observed performance and customer requirements. A 99.99% promise made without redundancy, appropriate dependencies, and tested recovery is likely to create a contract problem rather than a reliability strategy.
Keep targets few enough that teams understand them. A target nobody can explain during an incident won't guide a useful decision.
Writing an SLA
An SLA must define the service covered, the measurement period, how availability is calculated, exclusions, how to report a breach, and the remedy. It must also identify whether the promise covers every API operation or only a defined set of critical endpoints.
A public status page can support the record, but daily uptime bars alone may not provide the contractual evidence. Keep the underlying checks and request-success data so a dispute can be resolved with an agreed calculation.
Avoid copying an internal SLO directly into a contract. Many teams operate to an internal target stricter than the customer-facing minimum, giving them space to detect and repair a problem before a service-credit threshold is reached.
Checklist for SLAs, SLOs and SLIs
- Define the good event, bad event, and eligible population for each SLI.
- Choose a time window and a target justified by user needs.
- Calculate the request or time budget the target permits.
- Connect the budget to practical release and incident decisions.
- Alert on fast and slow budget consumption separately.
- Keep the contractual SLA precise about scope, exclusions, and remedies.
- Retain evidence behind published uptime and success figures.
SLAs, SLOs and SLIs with Octri
Octri Monitoring presents transaction-level error rates, throughput, and latency percentiles, and supports SLO targets such as a p95 ceiling and a maximum error rate. Uptime checks and a public status page provide an additional availability record. These measurements can inform an SLA, but the contract's definition and any remedies remain decisions for the service owner.
An error budget is useful only when it changes what the team does. The target should make it easier to prioritize a reliability fix over a risky release when the service is already failing its users.