The StatusCat blog

SLA vs SLO vs SLI, explained simply

SLA, SLO and SLI get used interchangeably, but they're three different things. Here's what each means, how they relate, and how to set targets you can actually keep.

StatusCat3 min read

SLA, SLO and SLI are three of the most mixed-up terms in reliability. They're related, but they mean different things, and getting them straight helps you set targets you can actually keep.

Here's the plain-English version.

SLI — the measurement

An SLI (Service Level Indicator) is a metric — a number that reflects how well your service is doing. Examples:

  • The percentage of successful requests (not 5xx) over a window.
  • The percentage of requests served faster than 300ms.
  • Uptime: the percentage of time the service was available.

An SLI is just the measurement. It doesn't say whether that number is good or bad — that's the SLO's job.

SLO — the internal target

An SLO (Service Level Objective) is the target you set for an SLI. For example:

  • "99.9% of requests succeed, measured monthly."
  • "99.95% uptime over 30 days."

The SLO is your internal line in the sand. It's what you steer by, what you alert on when you're at risk of missing it, and what informs decisions like "should we ship this risky change or protect the error budget?"

SLA — the external promise

An SLA (Service Level Agreement) is a contractual promise you make to customers, usually with consequences (credits, refunds) if you break it. For example:

  • "We guarantee 99.9% monthly uptime; if we miss it, you get a service credit."

The key rule: your SLA should be looser than your SLO. If your internal target and your customer promise are identical, any bad month breaches the contract. Give yourself a buffer — aim higher internally (SLO) than you promise externally (SLA).

How they fit together

  • SLI: "We measured 99.94% uptime this month."
  • SLO: "Our internal target is 99.95%." → we missed it, time to investigate.
  • SLA: "We promised customers 99.9%." → still met, no credits owed.

So one bad month can miss your SLO (a signal to act) without breaching your SLA (a contractual problem). That gap is the whole point of setting the SLA looser.

Setting targets you can keep

  1. Start by measuring (SLIs). You can't set a realistic target without knowing your current numbers.
  2. Set SLOs slightly above where you are — ambitious but achievable — and use them to prioritise reliability work.
  3. Only promise an SLA you can beat comfortably, with a buffer below your SLO.
  4. Don't over-promise nines. Each extra nine gets exponentially more expensive — see uptime percentages explained for what each level really costs.

Measuring it in practice

All of this starts with reliable measurement. To track uptime SLIs honestly you need frequent checks, re-checks before alerting, and uptime history to report against. StatusCat tracks all of that and can generate SLA reports from it — free for 50 monitors. New to the basics? Start with what uptime monitoring is, and use the uptime & SLA calculator to see what a target really allows.

Frequently asked questions

What's the difference between an SLA, SLO and SLI?
An SLI is the measurement (e.g. the percentage of successful requests). An SLO is your internal target for that measurement (e.g. 99.9%). An SLA is the external, contractual promise you make to customers — usually looser than your SLO — with consequences if you miss it.
Should my SLA be the same as my SLO?
No — your SLA should be looser than your SLO, so you have a buffer. If your internal target (SLO) is 99.95% and you promise customers exactly 99.95% (SLA), any bad month breaches the contract. A common pattern is to set the SLA a notch below the SLO.
Do I need all three?
You need SLIs (you can't manage what you don't measure) and usually SLOs (internal targets to steer by). SLAs only matter if you're making formal, contractual promises to customers — many products run on SLOs alone.

Keep reading

BlogWhat is uptime monitoring? A practical guideUptime monitoring explained in plain terms: how it works, why it matters, the check types you'll use, and how to set it up so you hear about outages before your customers do.BlogUptime percentages explained: how much downtime is 99.9%?What 99.9%, 99.95% and 99.99% uptime actually mean in minutes and hours of allowed downtime — per day, month and year — plus how to pick the right target for your service.BlogHow to set up an on-call rotation (without burning out your team)A practical guide to on-call rotations: schedules, escalation, acknowledgements, quiet hours and alert hygiene — so incidents reach the right person fast without exhausting your team.