SLO vs SLA: the difference, SLIs and error budgets
7 min read
An SLA (service level agreement) is a contract with a customer that says what happens when a service misses a promised level, usually a service credit. An SLO (service level objective) is the internal target a team runs the service against; the SRE book advises setting it stricter than the SLA so that problems get fixed before the contract is breached. An SLI (service level indicator) is the measurement both are written in, such as the share of requests that succeed.
| SLI | SLO | SLA | |
|---|---|---|---|
| What it is | A measurement | A target for an SLI | A contract built on SLOs |
| Set by | Engineering | Product owner and engineering | Business and legal teams |
| On a miss | Nothing by itself | Error budget spent | Service credits or penalties |
| Example | Checkout calls that succeed | 99.95% over four weeks | 99.9% monthly, or a credit |
The examples are illustrations; the sources are Google’s SRE book and workbook and the AWS compute SLA, checked on 1 November 2026.
What do SLI, SLO and SLA stand for?
Service level indicator, service level objective and service level agreement. The indicator is what you measure, the objective is the value you aim for, and the agreement is what you promise someone else, with consequences attached.
The SRE book chapter on Service Level Objectives defines an SLA as “an explicit or implicit contract with your users that includes consequences of meeting (or missing) the SLOs they contain”. The chapter’s test is one question: what happens if the SLOs are not met? With no explicit consequence, you are almost certainly looking at an SLO.
The chapter adds that most people mean SLO when they say SLA, and that a real SLA violation might end in a breach-of-contract case. So when a meeting turns into an SLA vs SLO argument, first ask whether a consequence, usually money, is written into a contract.
The SRE book advises keeping a safety margin: “a tighter internal SLO than the SLO advertised to users gives you room to respond to chronic problems before they become visible externally.” Its “Embracing Risk” chapter applies the same idea to a contract: a 99.9% external target backed by a stronger internal one.
What is an error budget?
It is 100% minus the SLO: the share of requests or time that may fail within the window. While budget remains, the team keeps shipping; once it is spent, reliability work comes first.
The SRE workbook chapter “Implementing SLOs” gives the arithmetic: with a 99.9% SLO, a service that receives 3 million requests over four weeks may fail 3,000 of them, so one outage with 1,500 errors spends half the budget. The book’s “Embracing Risk” chapter explains the purpose: product management sets the SLO, monitoring measures uptime, and the gap is the unreliability left for the quarter. When that budget runs out, releases are halted or slowed.
How much downtime does 99.9% allow?
About 43 minutes in a 30-day window. Each extra nine divides the allowance by ten, so 99.99% leaves just over 4 minutes.
| SLO | Error budget | Downtime per 30 days | Failures per million |
|---|---|---|---|
| 99% | 1% | 7 h 12 min | 10,000 |
| 99.5% | 0.5% | 3 h 36 min | 5,000 |
| 99.9% | 0.1% | 43 min 12 s | 1,000 |
| 99.95% | 0.05% | 21 min 36 s | 500 |
| 99.99% | 0.01% | 4 min 19 s | 100 |
Multiply the 43,200 minutes of a 30-day window by the error budget. Note the workbook’s warning that each extra nine costs more while its value to users approaches zero.
What does a real SLA look like?
It names a measured percentage, a billing period, a credit schedule and what does not count. The AWS compute SLA is a short public example.
The Amazon Compute Service Level Agreement (last updated 25 May 2022; checked on 1 November 2026) commits to a Monthly Uptime Percentage of at least 99.99% per region for EC2 instances spread over two or more Availability Zones, and 99.5% for a single instance. Uptime is 100% minus the share of minutes when EC2 was unavailable. Under the Region-Level SLA, below 99.99% the credit is 10% of that month’s EC2 bill in the region, below 99.0% it is 30%, and below 95.0% it is 100%; a single instance’s 10% tier starts below 99.5%. Credits are applied against future payments, must be claimed through AWS Support and are the “sole and exclusive” remedy unless the customer agreement says otherwise.
Read against the downtime table, the Region-Level SLA’s 10% tier spans roughly 4 minutes to 7 hours of unavailability in a 30-day month. An SLA caps what the provider owes; keeping outages from hurting your users is the job of your own objectives.
How do you choose SLIs for latency and availability?
Measure latency as a percentile and availability as good events divided by all events, as close to the user as you can. Averages and server-only numbers hide the requests people complain about.
Latency. The SRE book prefers percentiles to the mean, because an average can stay flat while a long tail gets much slower. The workbook writes latency SLIs as a ratio, such as calls completed in under 100 ms divided by all calls. So “99% of checkout calls under 400 ms” means “p99 of checkout under 400 ms” over the window, which carries straight into a test. Our tail latency article explains why p99 matters once a page calls several services.
Availability. Time-based availability counts minutes of uptime, as the AWS SLA does. Request-based availability counts successful requests: “Embracing Risk” describes a service with 2.5 million requests a day and a 99.99% daily target, which can return 250 errors and still meet it.
Where do SLOs go wrong?
Usually through too many objectives, 100% targets and indicators measured where users are not. Each one leaves a number nobody acts on, or one that looks fine while users suffer.
- Too many SLOs. The SRE book advises as few as possible: if quoting an SLO can never win a conversation about priorities, it is probably not worth having.
- 100% targets. The workbook calls 100% the wrong target: components fail, change is the main source of outages, and a 100% SLO leaves time only to react.
- Measuring at the server only. Server metrics miss problems users feel, such as a slow page script. The workbook suggests measuring at the load balancer or the client.
What does load testing have to do with SLOs?
An SLO gives a load test its pass/fail criteria, and a test at the expected peak shows whether the latency SLO holds before that traffic arrives. Production monitoring only tells you afterwards.
The SRE book notes that higher QPS often leads to larger latencies and that services commonly have a performance cliff beyond some load threshold. A load test can find that cliff if it runs at the expected peak with a realistic request mix and measures the SLI the SLO uses. Set each test limit a little tighter than the SLO, as our guide to load test pass/fail criteria describes. A run lasts minutes, so it cannot measure monthly availability.
LoadFocus, which publishes this site, grades load tests against pass/fail thresholds saved on the test: Max P95 and Max P99 response time, a maximum error rate and a minimum throughput, for cloud, JMeter and k6 tests. Its API monitoring has SLA / SLO reports that set an SLO target per monitor and show uptime, error budget consumed and an OK or Breached status.
FAQ
What does SLO stand for? Service level objective: a target value for a measured service level, such as 99.9% of requests succeeding over four weeks. It is set internally, by product and engineering, and carries no contractual penalty by itself.
Can you have an SLO without an SLA? Yes. The SRE book gives Google Search as an important service with no public SLA that is still managed with SLIs and SLOs.
Should an SLO ever be 100%? No. A 100% objective leaves no error budget, so every failure breaches it and no change is ever safe to release.
Related reading
- Load test pass/fail criteria: how to set them
- Tail latency: what it is and how to measure it
- Apdex score: what it is and how to calculate it
- Throughput vs latency: how they interact under load
The technical claims in this article have not been independently reviewed.