What Is The Difference Between SLI, SLO, And SLA, And Can You Give Simple Examples

SLI vs SLO vs SLA in one breath

These three terms tell the same reliability story at three altitudes. An SLI (Service Level Indicator) is a raw metric that measures how the service is actually behaving — uptime, latency, error rate. An SLO (Service Level Objective) is the internal target you set for that metric — for example, “99.9% uptime per calendar month.” An SLA (Service Level Agreement) is a formal, customer-facing contract that promises a level of service and spells out the consequences (usually service credits or refunds) if you miss it.

The one-line intuition: the SLI is what you measure, the SLO is what you aim for, and the SLA is what you promise. Crucially, the SLO is set stricter than the SLA on purpose, so your own alarms fire before you ever breach a contract.

The SLI: what you measure

An SLI is a carefully chosen, quantitative measure of one aspect of the service, almost always expressed as a ratio of good events to total events over a window. Typical SLIs are availability (“fraction of successful requests”), latency (“fraction of requests served under 300 ms”), error rate, throughput, or data freshness. Good SLIs are user-centric — they track something a customer would actually notice — and stable enough to trend over time. Example readings: “uptime this week = 99.97%” or “p95 latency = 250 ms.”

Time-based vs request-based SLIs

Uptime-as-time hides partial failure: an hour where 50% of requests error counts as fully “up” on a time-based SLI, yet half your users failed. The request-based form — good events ÷ total events — charges it correctly: at 1M requests/hour, a 50%-error hour spends 500,000 bad events against the budget, the same damage as 30 minutes of total downtime. Modern SRE practice states availability SLOs as request ratios over a rolling window for exactly this reason; keep time-based uptime only for externally-audited SLAs where the contract defines “down.”

How fast you are spending the budget — the burn rate — is what should page a human; see the error-budget page for the multi-window burn-rate policy (14.4×/6×/1×).

The SLO: what you aim for (and the error budget)

An SLO is a target value or range for an SLI, owned internally by product and SRE teams — for example, “99.9% of requests succeed over each calendar month.” Meeting it means you are healthy; missing it triggers alerts or a post-mortem but carries no external penalty. Because 100% is neither realistic nor cost-effective, the gap below your SLO is the error budget: at a 99.9% monthly uptime target you may be down roughly 43 minutes a month, and that budget is what you spend on deploys and maintenance. When the budget is nearly exhausted, teams slow risky changes and refocus on reliability.

The SLA: what you promise (and the penalty)

An SLA is a formal agreement with customers: “we promise this level of service; if we don’t deliver, here is what happens.” It names the committed metrics and thresholds and defines the remedy — typically service credits or refunds, and in extreme cases a right to terminate. Because breaching an SLA has real financial and legal cost, the promised level is deliberately set looser than the internal SLO. If the team’s SLO is 99.9% uptime, the SLA to customers might be 99.5%, so comfortably hitting the stricter internal goal always satisfies the contract. SLAs are the least flexible of the three: changing one usually means renegotiating the contract.

Side by side

Worked example 1: a web service

You run a web service and want to manage its reliability across all three layers.

• SLI (measurement): you track uptime — the percentage of time the service is available. After one month the measured uptime SLI is 99.2%.
• SLO (internal goal): your team targets 99.9% uptime per month — at most about 43 minutes of downtime. It is stricter than what you currently achieve, so it drives the roadmap; engineers are paged as uptime trends toward 99.9%.
• SLA (external promise): to customers you guarantee a looser 99.5% uptime per month; fall below it and they receive service credits.

Read the 99.2% month against these lines: you missed the 99.9% SLO (internal goal blown) and breached the 99.5% SLA (customers are owed credits). Now imagine a better month at 99.7%: you still miss the 99.9% SLO — a warning that you have burned most of your error budget — but you clear the 99.5% SLA, so customers are unaffected. That gap between SLO and SLA is exactly the buffer that lets you catch trouble before it becomes a contractual problem.

Worked example 2: a SaaS uptime SLA with a credit schedule

Your company sells a B2B API. The contract guarantees 99.5% monthly uptime (the SLA), while your team runs to a stricter internal 99.9% SLO. The contract attaches this service-credit schedule to the SLA:

Walk a bad month. The API was down for roughly 6 hours across a 30-day month. Thirty days is 43,200 minutes; 6 hours is 360 minutes down, so uptime = (43,200 − 360) / 43,200 = 99.167%. That 99.167% is the measured SLI. It sits below the 99.9% SLO (missed) and below the 99.5% SLA (breached), landing in the 99.0%-to-<99.5% tier — so the customer is owed a 10% credit.

Contrast a calmer month at 99.7% uptime: you still missed the 99.9% SLO (burning most of your error budget and triggering an internal review), but you stayed above the 99.5% SLA, so customers owe nothing. The internal target fired as an early warning well before the contract did — the customer-facing SLA credit only triggered once you fell under 99.5%.

Common pitfalls

• Setting the SLA tighter than or equal to the SLO. If you promise customers 99.9% while your internal target is also 99.9% (or looser), you have zero or negative buffer: the moment you miss your own goal you are already breaching a contract. Keep the SLA looser than the SLO — as in the examples above, 99.5% promised against a 99.9% target — so the SLO fires as a warning first.
• Confusing the SLI with the SLO. The SLI is the measured number; the SLO is the line you drew on it. “99.97% uptime” is an SLI reading; “at least 99.9%” is the SLO.
• Chasing 100%. 100% is neither achievable nor worth the cost. The gap below 100% is your error budget — spend it on releases and maintenance rather than trying to eliminate it.
• Averaging away pain. A monthly average can look healthy while hiding a bad afternoon. Prefer good-event ratios and percentiles over short windows, especially for latency SLIs.
• Tracking too many SLIs. Watch a few user-centric signals (availability, latency, error rate, correctness) rather than every metric you can scrape.

Key takeaways

• An SLI is a measurement — the actual number your monitoring reports (uptime, latency, error rate).
• An SLO is an internal target on an SLI (e.g. “≥ 99.9% uptime per month”); missing it is an engineering signal, not a legal event.
• An SLA is an external contract that promises a service level and attaches consequences (credits, refunds) when it is breached.
• Order of strictness: the SLI is reality, the SLO is stricter than the SLA, and the SLA is the loosest, customer-facing line — the gap between the SLO and the SLA is your safety buffer.
• Mnemonic: Indicator = what you measure, Objective = what you aim for, Agreement = what you promise.

Source

Definitions and the error-budget model follow Google’s Site Reliability Engineering, Chapter 4, “Service Level Objectives” (Beyer, Jones, Petoff & Murphy, eds., O’Reilly, 2016), the canonical reference distinguishing SLIs, SLOs and SLAs.