SLA vs SLO vs SLI: What Is the Difference?
Last verified on Nov 8, 2026.
Three acronyms get mixed up in every reliability meeting. They describe three different things: what you measure, what you aim for, and what you owe someone if you miss.
One Sentence Each
- SLI (service level indicator): the measurement. "99.93% of requests succeeded this month."
- SLO (service level objective): the target for that measurement. "At least 99.9% should succeed." Details are on the SLO and SLI pages.
- SLA (service level agreement): a contract that says what happens when the target is missed. "Below 99.9%, the customer gets a credit."
The numbers are related, but the audiences differ. SLIs and SLOs belong to the engineers running the service. The SLA belongs to the customer, the sales team, and the lawyers.
The Test That Separates Them
Google's SRE book gives a one-question test: ask "what happens if the SLOs aren't met?" With no explicit consequence, you are almost certainly looking at an SLO. The book describes an SLA as an explicit or implicit contract with users that includes consequences, most easily recognized when they are financial, such as a rebate or a penalty.
The NIST glossary lists a related definition: a commitment between a service provider and customers that sets out responsibilities and what the customer can expect.
What an SLA Looks Like in Practice
Public SLAs are short and specific. Amazon EC2's SLA promises a Region-Level Monthly Uptime Percentage of at least 99.99% for instances deployed across two or more Availability Zones. Missing it makes the customer eligible for a service credit:
Three things are worth noticing in that table:
- The remedy is a credit, calculated as a percentage of the monthly bill for the affected region. It is a limited consequence, defined in advance.
- The customer has to ask for it. AWS's terms require a claim through a support case, received by the end of the second billing cycle after the incident, so you need your own record of when the service was down.
- The promise is a floor, and the credit steps up as the shortfall grows.
Why the SLO Should Be Stricter
The SRE book recommends keeping a safety margin: an internal SLO tighter than the one you advertise. It gives you room to respond to chronic problems before users see them. It also lets you swap in a cheaper or simpler implementation without disappointing anyone.
A rough picture, for a service with a 99.9% SLA:
These values are examples, not a standard. The ordering is the point: you should be paged long before the contract is at risk. The alerting side is the subject of the error budget page.
Who Owns What
According to the SRE book, SRE does not usually write SLAs, because they are tied to business and product decisions. SRE does help define the SLIs, since there has to be an objective way to measure the objectives in an agreement or disagreements follow. SRE also works to avoid triggering the consequences.
That split is a good rule of thumb for your own team. Engineers choose indicators and targets. Business owners choose what to promise externally and what it costs when you break it.
Common Mix-Ups
- Calling a target an SLA. If nothing happens when it is missed, it is an SLO. Using the wrong word makes engineers sound like they are bound by a contract they have never read.
- Setting the SLA first. A promise made before you have measured anything commits you to numbers you may not be able to keep. Measure, then set an SLO, then decide what to promise.
- Measuring differently on each side. Customers and vendors should agree on the SLI. Server-side counts that exclude failed connections will not match a customer's experience.
When the outage looks like it comes from a supplier, see third-party failures for how it shows up in your own logs, which is the evidence you need for an SLA claim. For broader failures, Sazabi's reliability issue detection covers what is watched today.
Frequently Asked Questions
What is the difference between an SLA and an SLO?
An SLA is a contract that attaches consequences, usually credits or penalties, to missing a service level. An SLO is a target your team sets for itself. Google's test: ask what happens if it is missed. No explicit consequence means it is an SLO.
Should the SLA and SLO be the same number?
No. Set the internal SLO tighter than the SLA so you can fix chronic problems before they trigger a customer-facing consequence.
Where does the SLI fit in?
The SLI is the measurement both of them rely on. Without an agreed way to compute it from data, an SLA turns into a dispute about whose numbers are right.
Does every service need an SLA?
No. Google's SRE book names Google Search as an important service with no public SLA. Internal SLOs still apply to services that have no contract.
Sources
- SLAs are contracts with consequences for meeting or missing SLOs; the test is what happens if the SLOs are not met; SRE does not usually construct SLAs but helps define SLIs and avoid triggering consequences; tighter internal SLO as a safety margin (accessed Nov 8, 2026)
- Amazon EC2 Region-Level SLA of 99.99% Monthly Uptime Percentage; credits of 10%, 30%, or 100% of the monthly bill; credits must be claimed through a support case by the end of the second billing cycle (accessed Nov 8, 2026)
- NIST glossary definition of a service level agreement as a commitment between provider and customer that defines service responsibilities and expectations (accessed Nov 8, 2026)