SLA vs SLO vs SLI: Reliability Metrics Explained

SLIs, SLOs, and SLAs are three layers of the same idea, stacked from measurement to promise. An SLI (service level indicator) is a number you measure, like request latency or error rate. An SLO (service level objective) is an internal target for that number, like “99.9% of requests succeed.” An SLA (service level agreement) is the external, often contractual, commitment built on top of an SLO — usually with consequences, like service credits, if it’s missed. Confusing the three is common, but they answer different questions: what are we measuring, what are we aiming for, and what have we promised someone else.

Service level indicator: the raw measurement

An SLI is a directly observable metric that reflects some aspect of service health from the user’s perspective. Common examples:

• Availability — the proportion of requests that succeed, however “success” is defined for that service.
• Latency — the proportion of requests served faster than a threshold, often expressed as a percentile like p99.
• Error rate — the proportion of requests that return an error.
• Throughput — requests handled per unit time, relevant for capacity-bound systems.

An SLI is just a fraction: good events divided by total valid events, tracked over a window of time. It has no target attached yet — it’s purely descriptive. Getting good SLIs depends on solid observability: you can’t set a meaningful target for something you can’t measure reliably.

Service level objective: the internal target

An SLO takes an SLI and attaches a goal: “99.95% of requests over a rolling 30-day window complete in under 300ms.” SLOs are internal — they’re how a team decides what “reliable enough” means for a given service, and they’re deliberately set below 100%, because chasing perfect reliability trades off directly against shipping velocity.

That tradeoff is usually made explicit through an error budget: if the SLO allows 0.05% of requests to fail, that 0.05% is a budget the team can spend on deploys, experiments, and planned maintenance. Burn through the budget too fast, and the team slows down releases to protect reliability; have budget to spare, and there’s room to move faster or take on riskier changes. This is the same reasoning behind chaos engineering and gradual rollout strategies like blue-green and canary deployments — both are ways of spending error budget deliberately instead of accidentally.

Service level agreement: the external promise

An SLA is what a provider promises a customer, usually in a contract, with defined consequences for missing it — commonly service credits or refunds. SLAs are typically looser than the internal SLO they’re backed by. If the internal SLO is 99.95% availability, the external SLA might promise 99.9%, giving the team a buffer between what they’re actually targeting and what they’re contractually on the hook for. That gap absorbs measurement differences, edge cases in how uptime is defined, and simple risk margin.

How the three compare

	SLI	SLO	SLA
What it is	A measurement	An internal target	An external promise
Audience	Engineering team	Engineering team	Customers/contract
Consequence for missing it	None inherently	Slower releases, more focus on reliability	Service credits, contractual penalties
Typical strictness	N/A	Tighter	Looser (buffer below the SLO)
Example	99.97% of requests succeed	Target: 99.95% success over 30 days	Promise: 99.9% success or credits issued

A common mistake: picking SLIs that don’t reflect the user experience

It’s easy to pick an SLI that’s convenient to measure rather than one that actually reflects what users experience. Server-side CPU usage or average latency are simple to graph, but a user doesn’t experience an average — they experience their own single request, which is why percentile-based latency SLIs (p95, p99) tend to be far more meaningful than a mean that a handful of fast requests can quietly flatter. Similarly, measuring availability at the load balancer misses failures that happen deeper in the stack, after a request has already been counted as “received.” The rule of thumb is to measure as close to the user’s actual experience as the system allows, even if it’s harder to instrument than the nearest convenient metric.

Why the layering matters

Setting an SLA without SLIs and SLOs behind it is a promise made in the dark — there’s no internal target to manage toward, so the team finds out it’s missing the SLA only after a customer complains or invokes the contract. Working the other direction — SLI first, then SLO, then SLA — means the reliability target is chosen deliberately, monitored continuously, and only then wrapped in a customer-facing commitment with margin built in.

This layered thinking shows up throughout infrastructure design: a load balancer or platform engineering setup exists partly to make SLOs achievable by distributing load and standardizing how services are deployed and monitored, so that reliability targets aren’t each team reinventing its own approach.

The takeaway

An SLI is a measurement, an SLO is the internal target set for that measurement, and an SLA is the external, often contractual, promise built on top with a margin of safety. Error budgets turn the gap between “target” and “perfect” into a resource teams can deliberately spend on velocity or save for stability. Get the SLI right first — accurate, meaningful measurement — and the SLO and SLA that follow will actually mean something.