An SLI (service level indicator) is a measurement of how your service behaves, such as the share of successful requests. An SLO (service level objective) is the internal target for that measurement, such as 99.9% of checks succeeding over 30 days. An SLA (service level agreement) is the promise you make to customers, usually with a lower target than the SLO and a consequence, such as a service credit, if you miss it. The indicator is what you measure, the objective is what you aim for, and the agreement is what you sign.
This guide explains each term with examples, shows what uptime percentages mean in minutes, and walks through choosing indicators for a website or API, deciding what counts as downtime and writing an SLA customers can understand.
The three terms in plain language
SLI: the measurement
A service level indicator is a number you can calculate from real data. It is almost always a ratio: good events divided by all events. For a website, that could be the share of uptime checks that returned the expected response. For an API, it could be the share of requests that answered with a non-5xx status in under 500 milliseconds. An SLI has no target attached. It simply says what happened.
SLO: the target
A service level objective puts a target and a time window on an SLI. “99.9% of checks to the checkout succeed, measured over a rolling 30 days” is an SLO. It is an internal tool. It tells the team when reliability is good enough to keep shipping features and when it is time to slow down and fix things.
SLA: the contract
A service level agreement is the external promise, written into a contract or terms of service. It names the service, the target, how it is measured, what is excluded and what the customer gets if you miss it. Not every service needs an SLA, but every SLA needs an SLO behind it, or you have no early warning that you are about to break it.
How SLIs, SLOs and SLAs fit together
Think of them as layers. The SLI is the raw signal. The SLO is a stricter internal line drawn on that signal. The SLA is a looser external line drawn on the same signal. A common setup for a SaaS product looks like this (example values):
- SLI: share of one-minute checks to app.lumenanalytics.io that return status 200 and contain the dashboard title.
- SLO: 99.95% per calendar month.
- SLA: 99.9% per calendar month, with a service credit if missed.
The gap between 99.95% and 99.9% is the safety margin. If the team sees the SLO slipping in week two, it still has time to act before the contractual promise is at risk.
Uptime percentages in minutes
Uptime targets look close together on paper, but each extra nine cuts the allowed downtime by a factor of ten. The table below uses a 30-day month and a 365-day year.
| Uptime target | Allowed downtime per month | Allowed downtime per year |
|---|---|---|
| 99% | 7 h 12 min | 3 days 15 h 36 min |
| 99.5% | 3 h 36 min | 1 day 19 h 48 min |
| 99.9% | 43 min 12 s | 8 h 45 min 36 s |
| 99.95% | 21 min 36 s | 4 h 22 min 48 s |
| 99.99% | 4 min 19 s | 52 min 34 s |
| 99.999% | 26 s | 5 min 15 s |
Two practical consequences follow. First, your monitoring has to be able to see the downtime you promise. With five-minute checks you cannot honestly measure a 99.99% monthly target, because a single missed outage could use the whole budget. Second, every target above 99.9% leaves almost no room for manual response. At 99.99%, one slow night-time incident ends the month.
Error budgets: turning the SLO into decisions
An error budget is the amount of failure your SLO allows. With a 99.9% monthly SLO, the budget is 0.1% of the month, or 43 minutes and 12 seconds. Every incident spends part of it.
The budget makes reliability a shared decision instead of an argument. A simple policy many teams use:
- More than half the budget left: ship as normal.
- Less than half left: review risky deploys, add a second pair of eyes to database changes.
- Budget spent: pause feature releases for that service and work on the causes of the last incidents until the window resets.
An example: harborlabs.dev has a 99.9% monthly SLO for its public API. On the 9th, a bad deploy causes 18 minutes of errors. On the 20th, a certificate problem causes 9 more. That is 27 of 43 minutes spent, with ten days left. The team holds the next schema migration until the new month, because one more incident of the same size would break the objective.
Choosing SLIs for a website or API
Good SLIs describe what users experience, not what your servers feel. CPU at 90% is not an SLI. A checkout that fails is. Start with two or three indicators per service:
- Availability: the share of checks or requests that succeed. For a website, “succeed” should mean the right status code and the right content, not only a response.
- Latency: the share of requests that answer faster than a threshold, for example 95% under 800 ms. A share is easier to reason about than an average, which hides slow outliers.
- Correctness: for APIs, the share of responses that contain the expected fields. A 200 with an empty body is not a success.
Measure the paths that matter. For a shop like northwind.shop, that means the checkout and the product pages, not just the cached homepage. For an API, it means the endpoints customers integrate against, ideally through a health check endpoint that tests the database and other dependencies. An API monitor that validates the response body turns that endpoint into an SLI you can trust.
What counts toward uptime
Most disputes about SLAs are not about the number. They are about what counts. Decide these points before you publish a target:
- Planned maintenance. Many SLAs exclude scheduled maintenance announced in advance, for example with 72 hours’ notice and a cap of four hours per month. If you exclude it, say how it is announced and set a limit, or “maintenance” becomes a loophole.
- Partial outages. Is the service down if login works but checkout fails? Define the components covered and whether an outage of one counts as downtime for the whole.
- Degraded performance. Decide whether responses slower than a threshold count as failures. If a page takes 30 seconds, users consider it down.
- Causes outside your control. Customer-side network problems, misuse and force majeure are commonly excluded. Your own hosting provider usually is not; customers bought the service from you.
- Minimum duration. Some SLAs only count outages longer than a minute or confirmed by more than one check, which matches how monitoring confirms failures.
Internally, it is often wise to count planned maintenance in your SLO even if the SLA excludes it. Users still could not reach the service, and the SLO is meant to reflect their experience.
Writing a customer-facing SLA
A good SLA is short and specific. It should answer six questions: which service, what target, measured how, over which period, with which exclusions, and what happens if you miss it. Here is an example clause you can adapt:
Service: the Lumen Analytics web application at app.lumenanalytics.io
and the public API at api.lumenanalytics.io.
Target: 99.9% monthly availability.
Measurement: availability is measured by external checks every minute
from at least two locations. A minute counts as unavailable when the
service returns an error (5xx) or no response, confirmed from a second
location.
Exclusions: scheduled maintenance announced at least 72 hours in advance
on our status page (max. 4 hours per month); problems caused by the
customer's own network or systems.
Credits: below 99.9%: 10% of the monthly fee.
below 99.0%: 25% of the monthly fee.
Customers request credits within 30 days of the end of the month.Set the SLA below what you actually achieve. If your monitoring history shows 99.97% over the last year, promising 99.9% is realistic. Promising 99.99% because it sounds better turns every incident into a contractual problem.
Keep credits proportionate and the claim process simple. Customers rarely want the money. They want to see that you take the promise seriously and that you measure honestly.
Measuring with external monitoring
Your own logs cannot measure an outage in which your server never received the request. DNS failures, expired certificates, network problems and a crashed load balancer all leave internal metrics quiet. That is why SLA measurement should come from outside, the same way customers reach you. If you are new to the idea, start with what uptime monitoring is and how it works.
A sound setup for SLA reporting:
- Check every minute. The interval sets the resolution of your measurement.
- Confirm failures from a second location. This keeps a single bad network route out of your downtime numbers.
- Validate content. Check for a word or field that only appears when the service works.
- Keep the history. You need incident start and end times for every month you report on.
- Publish it. A status page with uptime history lets customers see the same numbers you do.
Uptimecheck covers this with uptime monitoring every minute from Europe, weekly and monthly email reports, and exports to CSV, JSON or PDF for the monthly SLA statement. A status page connected to the same monitors shows customers the uptime history behind your promise.
Uptime is only one side of reliability. How fast you detect and fix incidents decides how much of the budget each one spends; read MTTR, MTTA and MTBF explained for the response side.
Checklist: setting SLIs, SLOs and an SLA
- List the user journeys that matter: login, checkout, the main API.
- Define one availability SLI and, where it matters, one latency SLI per journey.
- Measure for a month or two before choosing targets.
- Set the SLO slightly below what you achieve today, and agree on an error budget policy.
- Set the SLA below the SLO, with clear exclusions and proportionate credits.
- Measure externally every minute and review the numbers monthly.
Measure the uptime you promise from where your customers stand. Try Uptimecheck free for 14 days, no credit card required.