Reliability

SLA vs SLO vs SLI, Explained with Examples

By the Opsentry team · June 10, 2026 · 7 min read

These three acronyms get used interchangeably in meetings, and they shouldn't be — they're three different layers of the same system: what you measure, what you aim for, and what you promise. Get the layering right and reliability conversations with customers, engineers, and leadership all get easier.

SLI: what you measure

A Service Level Indicator is a metric that reflects user experience. Not CPU utilization or memory pressure — those are causes, not experiences. Good SLIs are ratios of good events to total events:

Availability: successful requests ÷ total requests (or successful external checks ÷ total checks)
Latency: requests served under 300ms ÷ total requests
Quality: checkout flows completed without error ÷ flows started

The test for a good SLI: if it degrades, are users actually unhappy? If your CPU hits 95% but every request still returns in 80ms, users are fine and your SLI should say so. External uptime checks make excellent availability SLIs precisely because they measure from where the user stands — see our monitoring best-practices guide for why that vantage point matters.

SLO: what you aim for

A Service Level Objective is an internal target for an SLI over a window: "99.9% of external checks succeed, measured over 30 days." SLOs are engineering tools, not contracts. They answer the question every team argues about eventually: how reliable is reliable enough? The honest answer is "less than 100%" — each extra nine roughly multiplies cost, and past a point users can't perceive the difference anyway.

Here's what the nines actually allow per 30-day month:

Target	Allowed downtime / month	Realistic for
99%	~7.3 hours	Internal tools
99.9%	~43 minutes	Most SaaS products
99.95%	~22 minutes	Payment and auth paths
99.99%	~4.3 minutes	Infrastructure platforms

Note what 99.99% implies: four minutes a month means no human-in-the-loop recovery — detection, diagnosis, and failover must all be automatic. Don't set targets your operational maturity can't cash.

SLA: what you promise

A Service Level Agreement is an SLO with a penalty attached — a contract clause that pays service credits when you miss. Because breaching an SLA costs money and trust, the universal practice is to keep the SLA looser than the SLO: promise 99.5% externally, target 99.9% internally. The gap is your safety margin; the SLO breach is your early-warning alarm that fires long before the contract is at risk.

Error budgets: where this becomes useful

The most practical product of an SLO is the error budget — the unreliability you're allowed. A 99.9% monthly SLO is a budget of about 43 minutes of downtime. That number converts reliability from a philosophical debate into a resource you spend:

Budget mostly intact? Ship faster, run the risky migration, deploy on Friday if you like. Reliability effort beyond the target is effort taken from features.
Budget nearly spent? Slow releases, prioritize stability work, postpone the risky change. The budget says no — nobody has to win an argument.

This only works if the SLI driving it is trustworthy, which is why teams anchor error budgets to externally measured uptime rather than self-reported internal metrics.

How the three fit together

	SLI	SLO	SLA
What	A measurement	An internal target	A contractual promise
Example	% of checks succeeding	99.9% over 30 days	99.5% or service credits
Audience	Engineers	Engineering + product	Customers + legal
On a miss	—	Stability work takes priority	Credits owed

Getting started without a platform team

Pick one user-facing service and one SLI — externally checked availability is the simplest defensible start.
Measure for a month before setting any target. You can't pick a sane SLO without knowing your baseline.
Set the SLO slightly above what you already achieve, then tighten deliberately.
Only sign SLAs looser than SLOs you've consistently hit.
Publish your availability. A public status page with real uptime history is the cheapest credibility you'll ever buy.

Opsentry handles the measurement layer: external uptime checks as your availability SLI, per-service SLA targets, uptime over 24h/7d/30d/90d windows, and a public status page that shows the history. Free while in early access.