Three acronyms, one letter apart, used interchangeably in most engineering conversations — and the confusion has a price tag. Teams commit to an SLA they've never measured, set an SLO identical to that SLA so they have no room to fail, and then pick an SLI so vague that nobody can tell whether they hit it. Six months later there's a contractual credit owed and an argument about whose dashboard is right.
The distinction is simple once you see the nesting: an SLI is a measurement, an SLO is your internal target for that measurement, and an SLA is what you promised a customer in writing. They stack in that order, and each layer should be looser than the one below it.
The short version
| What it is | Who it's for | What happens if you miss it | |
|---|---|---|---|
| SLI — Service Level Indicator | A number you measure. "99.94% of HTTP checks succeeded last month." | Engineering | Nothing. It's a fact, not a goal. |
| SLO — Service Level Objective | Your internal target for an SLI. "≥99.95% monthly availability." | Engineering + product | Internal consequence: pause releases, spend the sprint on reliability. |
| SLA — Service Level Agreement | A contractual promise to a customer, with a remedy attached. "≥99.9% or you get 10% credit." | Legal, sales, customers | Money. Service credits, escalation rights, sometimes termination. |
If you only take one thing away: your SLO must be stricter than your SLA. The gap between them is your margin for error, and teams that set them equal have built a system where the first bad month becomes a billing dispute.
What is an SLI?
A Service Level Indicator is a quantitative measure of some aspect of service quality. It's a ratio, almost always: good events divided by total events, expressed as a percentage.
SLI = (good events / valid events) × 100
The most common SLIs:
- Availability. Successful requests ÷ total requests. Or, for uptime monitoring, successful checks ÷ total checks.
- Latency. Requests served faster than a threshold ÷ total requests. Note the shape: "95% of requests under 400ms" is an SLI. "Average response time" is not a good SLI, because averages hide the tail where your unhappy users live.
- Error rate. The inverse of availability, usually scoped to a specific class of error (5xx yes, 404 no).
- Freshness. For data pipelines and caches: records updated within N minutes ÷ total records.
- Correctness. Responses that returned the right answer ÷ total responses. Harder to measure, and the reason "the API was up" and "the API was working" aren't the same claim.
What makes an SLI good or bad
A good SLI is measured from as close to the user as possible, has an unambiguous definition of "good," and moves when users are unhappy.
The classic failure is measuring the wrong side of the system. If your SLI is "the web server process was running," you'll report 100% through an outage where the database was down and every page returned a 500. The process was up. Nobody could check out. The SLI was technically true and operationally worthless.
This is why external, synthetic checks matter for availability SLIs specifically: a probe hitting your public endpoint from outside your network measures what a customer would experience, not what your own infrastructure believes about itself. Self-reported availability from inside the perimeter is the number nobody in procurement trusts — for good reason.
Define the exclusions up front, too. Does a 429 rate-limit response count as a failure? A 401 from a customer with a bad token? A request that failed because the client hung up? Write these down before you need them, because deciding mid-incident is how you end up with an SLI that quietly reports whatever makes the quarter look good.
What is an SLO?
A Service Level Objective is a target value or range for an SLI, over a stated window. It has three parts, and all three are load-bearing:
- The SLI — what you're measuring
- The target — the threshold
- The window — over what period
"99.95% availability" is not an SLO. It's missing the window, and the window changes the difficulty enormously. A 99.9% target over a rolling 30 days allows 43 minutes of downtime. The same target over a rolling 7 days allows 10 minutes. Same number, very different engineering problem.
A complete SLO looks like:
99.95% of HTTPS requests to
api.example.com/v1/*will return a non-5xx status within 800ms, measured over a rolling 28-day window from external probes in at least three regions.
That's specific enough to argue with, which is the point.
Rolling windows vs calendar months
Calendar months are easier to explain to customers and easier to bill against. Rolling windows are better for engineering, because a calendar month resets your budget at midnight on the 1st — which means a catastrophic outage on the 31st costs you almost nothing, and a team can learn to schedule risk accordingly.
Most mature setups use both: a rolling 28-day window for internal SLOs and error budgets, and calendar months for the customer-facing SLA. Reporting two windows is a small amount of extra work and it removes an entire category of gaming.
How to pick the target
Not by asking what sounds impressive. Two inputs:
- What you've actually been doing. Pull the last 6–12 months of measured availability. If your worst month was 99.87%, committing to a 99.99% SLO is a fantasy that will be quietly abandoned by Q2.
- What users actually notice. Above a certain point, reliability stops being perceptible and starts being expensive. If your customers' own systems have a 99.9% availability, your 99.999% is invisible to them — you're spending on multi-region failover to improve a number nobody experiences.
Pick a target slightly better than your recent worst month, and tighten it once you're consistently beating it.
What is an SLA?
A Service Level Agreement is a contract. It contains an SLO (or several), plus the part that makes it an SLA: a remedy. What the customer gets when you miss.
Typical remedies, in escalating order:
- Service credits. The standard. Miss 99.9%, get 10% of the monthly fee back; miss 99.0%, get 25%; miss 95%, get 100%. Credits, not refunds — they apply to future invoices.
- Escalation and reporting rights. The customer can demand a root-cause analysis within N business days.
- Termination rights. After repeated breaches, usually 3 consecutive months, the customer can exit without penalty. This is the clause that actually has teeth.
An SLA also needs its exclusions spelled out, and this is where most of the negotiation happens:
- Scheduled maintenance. Almost always excluded, but bounded — "up to 4 hours per month, announced 72 hours in advance." Unannounced maintenance is an outage. If you're publishing maintenance windows, wire them into the same system that measures uptime so the exclusion is automatic rather than a spreadsheet adjustment; maintenance management exists for exactly this.
- Customer-caused failures. They DDoS'd themselves, they misconfigured their DNS, they exceeded documented rate limits.
- Force majeure and upstream providers. Careful here. "Our cloud provider had an outage" is not something your customer accepts as an excuse, because you chose the provider. Blanket upstream exclusions get struck in enterprise negotiation.
- Beta and free tiers. Usually no SLA at all.
How the three nest together
Concretely, for a payments API:
- SLI: percentage of
POST /v1/chargesrequests returning non-5xx within 1000ms, measured by external probes every 60 seconds from 5 regions. - SLO: ≥99.95% over a rolling 28 days. Internal. Breaching it triggers a release freeze.
- SLA: ≥99.9% per calendar month, excluding announced maintenance. Breaching it costs 10% of monthly fees in credits.
The 0.05% gap between SLO and SLA is deliberate. Over 30 days that's the difference between a 21-minute budget and a 43-minute budget — roughly 22 minutes of cushion between "engineering has a problem" and "finance has a problem." You want to find out you're in trouble while it's still an engineering matter.
That cushion is also where error budgets come from: the allowed unreliability under your SLO, treated as a resource you spend on purpose rather than a failure you apologise for.
Four mistakes that cost real money
Setting SLO = SLA. No margin. The first bad month is a contractual event. Always leave a gap.
Too many SLOs. A team with 40 SLOs has zero, because nobody can act on 40 numbers. Pick the two or three journeys that would generate support tickets if they broke — login, checkout, the main API write path — and start there.
Measuring from inside. Your load balancer's view of availability excludes every failure between your edge and the user: DNS, TLS, BGP, the CDN. External probes catch these. Internal metrics don't.
No consequence attached to the SLO. An objective with no policy behind it is a wish. Decide in advance what changes when you're burning through budget too fast — that decision is worthless if it's made during the incident.
Measuring this without an SRE platform
You don't need a full observability suite to run SLIs, SLOs, and an honest SLA. What you need is availability and latency measured from outside your infrastructure, retained long enough to report on a month, and published somewhere the customer can see it.
That's the shape of what Xitoring does: 60-second multi-protocol checks from 15+ global probing nodes, response-time history alongside availability, alert routing so a breach pages someone instead of showing up in a monthly review, and a public status page that publishes the same uptime data your SLA is measured against — so your customer-facing page and your internal numbers can't drift apart.
The free plan covers 8 uptime checks with no credit card, which is enough to instrument the two or three user journeys that matter and start building the history you'll need before you commit to any number in writing.
Related reading
- What Is Uptime Monitoring? The 2026 Guide — the measurement layer underneath all of this
- How to Achieve 99.99% Uptime — the architecture work behind a four-nines target
Frequently Asked Questions
Is an SLA the same as an SLO?
No. An SLO is an internal target with no contractual force; an SLA is a customer-facing promise with a remedy — usually service credits — attached to missing it. Every SLA contains an SLO, but most SLOs are never written into a contract. Keep your SLO stricter than your SLA so you have room to miss internally without triggering a billing event.
Which comes first, the SLI or the SLO?
The SLI. You can't set a credible target for something you aren't measuring. Instrument the indicator, collect at least a few months of history, look at your actual worst month, and then set the objective slightly above it. Setting an SLO before you have measurement is how teams end up committing to numbers they've never hit.
What's a reasonable uptime SLA for a B2B SaaS?
99.9% per calendar month — about 43 minutes of allowed downtime — is the table-stakes commitment, and it's what most mid-market contracts assume. Enterprise buyers typically push for 99.95% or 99.99%. Don't commit above what your measured history supports; a 99.9% SLA you always beat is worth far more in renewals than a 99.99% SLA you breach twice a year.
Should scheduled maintenance count against the SLA?
Conventionally it's excluded, but only when it's bounded and announced — a typical clause allows up to 4 hours per month with 72 hours' notice. Unannounced maintenance counts as downtime. Whatever you agree, make the exclusion automatic in your monitoring by declaring maintenance windows in the same tool that measures uptime, so nobody is hand-adjusting a spreadsheet at the end of the month.
How many SLOs should a team have?
Two or three per service. The test is whether someone can act on the number: a team tracking dozens of objectives ignores all of them. Pick the user journeys whose failure generates support tickets — authentication, checkout, the primary API write path — and cover those first.
Can I measure SLIs with just uptime monitoring?
For availability and latency SLIs, yes — and external synthetic checks are arguably the better source, because they measure the path your users actually traverse, including DNS, TLS, and CDN. What uptime monitoring can't give you is correctness or freshness SLIs, which need application-level instrumentation. Most teams start with availability from external probes and add application SLIs later.