Picture the meeting. Sales has just promised a big new customer "99.99% uptime, guaranteed." Everyone around the table nods along — it sounds reassuringly close to perfect.
Across the room, the on-call engineer has gone very quiet. They're doing arithmetic on the back of a napkin: 99.99% means we're allowed to be down for about four minutes a month. Four. Minutes. This morning's deploy took longer than that.
That gap — between a number that sounds great in a sales deck and what it actually costs to deliver — is exactly what SLAs, SLOs and SLIs exist to close. They're three of the most useful ideas in running software, and three of the most reliably muddled. Let's untangle them, with as little jargon as possible.
Meet the three letters
Here's the whole thing in one breath: you measure something (SLI), you set yourself a target for it (SLO), and you make a promise to customers about it (SLA).
It's easier with something physical. Imagine a coffee shop, Daybreak, that prides itself on speed.
| Term | At Daybreak Coffee | In your software |
|---|---|---|
| SLI — the measurement | "This latte took 3m 12s." | "99.93% of requests succeeded last week." |
| SLO — the internal target | "We aim to serve every latte in under 4 minutes." | "We aim for 99.9% success over 30 days." |
| SLA — the customer promise | "Latte in 5 minutes or it's free." | "99.5% uptime or we credit your bill." |
Notice the pattern already: the measurement is reality, the target is stricter than the promise, and the promise has a consequence attached. Hold that thought — it's the single most important idea in this whole post.
SLI — the thing you actually measure
An SLI (Service Level Indicator) is just a number that reflects how well your service is doing, right now and over time. No targets, no promises — only honest measurement.
The trick is choosing an SLI that reflects what users actually feel. "The server is on" is a weak SLI; a server can be very much on and still serving errors. Better SLIs measure the experience:
| What you're running | A meaningful SLI |
|---|---|
| Website or API | % of requests that return a success (not a 5xx) within 300ms |
| Checkout / signup flow | % of attempts that complete without an error |
| Background jobs | % of jobs that finish before their deadline |
| Data pipeline | % of records that are fresh within, say, 5 minutes |
| Video or audio | % of streams that start playing within 2 seconds |
Rule of thumb: a good SLI is something a user would nod at. If your latency SLI is green but customers are complaining the app feels slow, your SLI is measuring the wrong thing.
Most SLIs end up phrased as "the proportion of good events over total events" — good requests over all requests, on-time jobs over all jobs. That framing makes them easy to turn into a target, which is the next step.
SLO — the target you hold yourself to
An SLO (Service Level Objective) is the line you draw on your SLI. "99.9% of requests succeed over 30 days" is an SLO. It's internal — a goal your team owns — and it's where the famous "nines" show up.
People love stacking nines because each one sounds barely different from the last. They are not. Every nine you add is roughly ten times harder to achieve. Here's what those innocent-looking percentages actually buy you in allowed downtime:
| Availability | Downtime per day | Downtime per month | Downtime per year |
|---|---|---|---|
| 99% ("two nines") | ~14m | ~7h 18m | ~3.65 days |
| 99.9% ("three nines") | ~1m 26s | ~43m | ~8h 46m |
| 99.95% | ~43s | ~22m | ~4h 23m |
| 99.99% ("four nines") | ~8.6s | ~4m 23s | ~52m |
| 99.999% ("five nines") | ~0.9s | ~26s | ~5m 15s |
Look at that jump from three nines to five. Going from 99.9% to 99.999% shrinks your yearly budget from nearly nine hours to five minutes. Five minutes a year — for everything: deploys, database hiccups, a cloud region wobbling, a certificate you forgot to renew. That's not a config change; that's a small fortune in redundancy and engineering time.
The uncomfortable truth: the right SLO is almost never "as high as possible." It's "as high as our users genuinely need, and no higher." A marketing site does not need the same nines as a payments processor, and pretending otherwise just burns money and morale.
So how do you pick? Start from the user, not the dashboard:
- Find the journeys that matter — checkout, login, the core API call. Ignore the vanity pages.
- Ask what "good" feels like — fast enough that nobody notices, reliable enough that nobody complains.
- Look at what you already deliver — pull a few weeks of real data. If you're naturally hitting 99.95%, don't promise 99.999%.
- Set the SLO a notch below your real performance, so normal life doesn't constantly breach it.
SLA — the promise with consequences
An SLA (Service Level Agreement) is the SLO's grown-up sibling: a contractual promise to your customers, usually with money attached. Miss it and you owe service credits, refunds, or an awkward call with your biggest account.
Because an SLA has teeth, there's one golden rule:
Your SLA should always be looser than your SLO. Aim internally for 99.9% (the SLO) but only promise 99.5% (the SLA). That gap is your safety margin — the buffer that absorbs a bad week before it becomes a billing dispute.
If your SLO and SLA are the same number, you've left yourself no room. The first rough month and you're handing out credits. Teams that confuse the two usually find out the hard way, in a quarter-end finance review.
Here's the trio side by side:
| SLI | SLO | SLA | |
|---|---|---|---|
| What it is | A measurement | A target | A promise |
| Who it's for | Engineers | Engineering & product | Customers & legal |
| Example | "99.93% succeeded" | "99.9% over 30 days" | "99.5%, or credits apply" |
| If you miss it | Nothing — it's just data | You slow down and invest in reliability | You owe the customer something |
| Who sweats | Nobody | Your team | Your finance and legal teams |
A handy way to remember the relationship: SLA ≥ promise, SLO > SLA, SLI = the truth that decides both.
Error budgets — the idea that changes how you work
Here's where it gets genuinely clever. Flip an SLO around and you get an error budget.
If your SLO is 99.9% over 30 days, then you're allowed to be bad 0.1% of the time — about 43 minutes of failure that month. That 43 minutes isn't a failure to avoid at all costs. It's a budget to spend.
Let's walk through a month:
- Budget for the month: ~43 minutes (your 0.1% of 99.9%).
- Day 10: a botched deploy causes 30 minutes of errors. You've now spent most of the month's budget with 20 days to go.
- The decision: with only ~13 minutes left, this is not the week for a risky migration. Slow down, ship safer, protect what's left.
- Plenty of budget left instead? Then go ahead — ship the bold feature, run the experiment. Reliability isn't free, and an unspent error budget means you're probably moving too cautiously.
This reframes the eternal fight between "ship fast" and "keep it stable" into a number both sides can see. Product and engineering stop arguing about feelings and start looking at the same gauge.
The pros even watch the burn rate — how fast the budget is being eaten. Spending it ten times faster than sustainable? That's worth an alert, long before the SLO itself is blown.
Myths and traps to sidestep
| The myth | The reality |
|---|---|
| "More nines is always better." | Each nine costs ~10× more. Match nines to user need, not ego. |
| "Our SLA and SLO should be the same." | The SLA should be looser — that gap is your safety margin. |
| "We should aim for 100%." | 100% is the wrong target: impossible, and the last fraction costs more than it's ever worth. |
| "Uptime is the only thing to measure." | Latency, correctness and freshness often matter more than raw up/down. |
| "Set the SLOs once and move on." | Usage changes, expectations rise — revisit SLOs every few months. |
| "An incident means we failed our SLO." | Not necessarily. That's what the error budget is for. |
Where monitoring comes in
All of this is theory until something is actually measuring your SLIs, minute after minute, from where your users are. That's the unglamorous foundation the whole pyramid sits on:
- SLIs come from monitoring — checks recording whether each request succeeded and how long it took, ideally from several locations so a local blip doesn't pollute your numbers.
- SLOs are those SLIs measured against your target over a window — and a good alerting setup pages you on the trend (you're burning budget fast), not just a single failed check.
- SLAs are what you report back to customers — which is far less stressful when you can point at real uptime history and a clean SLA report instead of a shrug.
This is exactly the loop WatchFor is built around: check your services continuously, turn the results into clear up/down and latency signals, confirm real problems before alerting, and keep the history you'll need when someone asks "so, did we actually hit our SLA last quarter?" If you want the underlying vocabulary, our glossary has the full reliability dictionary.
TL;DR
If you remember nothing else, remember this:
| Term | In one line |
|---|---|
| SLI | What you measure — the honest number. |
| SLO | The target you hold yourself to, internally. |
| SLA | The promise you make to customers, with consequences. |
| Error budget | How much failure you're allowed before the SLO breaks — a thing to spend, not just fear. |
Set your SLOs from what users genuinely need. Keep your SLAs comfortably looser than your SLOs. Measure everything with real SLIs. And the next time someone promises "99.99%" in a meeting — you'll know to ask the only question that matters: measured how, and are we sure we can pay for it?