On this page
What Are SLA, SLO, and SLI?
SLIs are the measurements, SLOs are your internal targets, and SLAs are contractual promises to customers. Learn the difference with a comparison table.
Quick answer
- An SLI (service level indicator) is the measurement, such as the percentage of requests that succeed.
- An SLO (service level objective) is the internal target for that measurement, such as 99.9%.
- An SLA (service level agreement) is the contractual promise to customers, usually looser than the SLO.
The three terms compared
| Term | What it is | Who sets it | Example |
|---|---|---|---|
| SLI | The actual measurement | Engineering | 99.95% of requests succeed this month |
| SLO | The internal target | Engineering + product | 99.9% success, with an error budget |
| SLA | The contractual promise | Legal + business | “99.5% uptime or service credits” |
What is an SLI?
A service level indicator is a concrete, quantitative measurement of a user-facing property: availability, latency, error rate, or throughput. “The fraction of HTTP requests that return a non-5xx status” is an SLI. SLIs must be things you can actually measure from your telemetry, which ties them to observability.
What is an SLO?
A service level objective is the reliability target you set for an SLI over a window: “99.9% of requests succeed per month.” The gap between the SLO and 100% is the error budget, which teams use to decide when to ship features versus fix reliability. SLOs are internal and deliberately tighter than what you promise customers.
What is an SLA?
A service level agreement is a contract with a customer that states the promised level of service and the remedy — usually credits — if you miss it. Because it has financial consequences, the SLA is looser than your SLO. Breaking an SLO triggers internal work; breaking an SLA triggers a customer conversation and possibly payment.
Why the distinction matters
Conflating the three causes teams to promise customers their internal targets, then pay credits every time they miss an ambitious goal. Keeping SLOs tighter than SLAs gives you a buffer: you notice and fix reliability problems internally long before a customer is owed anything.
Where this bites vibecoders
AI assistants often paste an “SLA” into a contract without any SLO or SLI behind it — a promise with no measurement. The fix order matters: measure first (SLI), target second (SLO), promise third (SLA). You cannot have a credible uptime promise if you have never measured your uptime.
Where AI coding assistants get this wrong
- Writing SLAs with numbers the team has never measured or tested.
- Confusing the three terms and using “SLA” for what is really an internal SLO.
- Setting SLOs as round guesses (99.99%) with no error budget or enforcement.
- Defining SLIs from internal metrics (CPU) instead of user-facing outcomes.
Checklist
- Define SLIs from user-visible signals: availability, latency, error rate.
- Set SLOs tighter than any customer SLA.
- Compute and track an error budget for each SLO.
- Alert when the error budget is burning fast, not just when it’s gone.
- Review SLOs quarterly against real customer impact.
FAQ
What is an error budget?
An error budget is the amount of failure an SLO allows: a 99.9% SLO has a 0.1% error budget. Teams spend it on releases and incidents, and pause feature work when it’s exhausted. It is the bridge between reliability and velocity in SRE.
Why should an SLO be tighter than an SLA?
If your internal target equals your customer promise, you get no warning before a breach — you learn about it from a customer complaint or a credit payment. A tighter SLO triggers internal action first, protecting the SLA.
Is an SLA always about uptime?
No. SLAs can cover latency, support response time, or data durability, with SLIs and SLOs for each. The principle is the same: a measurement, a target, and a contractual promise.