SLIs, SLOs, and SLAs — The Reliability Contract

Why these three acronyms change everything

Before SRE introduced this framework, reliability was described in vague terms: "the system should be fast", "we aim for high availability", "we want users to have a good experience." These statements are not wrong they are just not engineering. You cannot measure them. You cannot alert on them. You cannot tell whether you have achieved them. And when something goes wrong, you cannot have a principled conversation about whether it was acceptable.

SLIs, SLOs, and SLAs replace that vagueness with precision. They turn "the system should be fast" into "99% of API requests must complete in under 200 milliseconds, measured over a 28-day rolling window." That sentence is measurable, alertable, falsifiable, and arguable. It is the difference between an aspiration and an engineering target.

The three concepts explained simply

The one-sentence relationship: an SLI tells you what is happening, an SLO tells you what should happen, and an SLA tells you what happens to the business if you consistently fail to hit the SLO. SLI → SLO → SLA, in that order. You must have each before the next makes sense.

SLI — what you actually measure

A Service Level Indicator is a carefully chosen metric that tells you something meaningful about how well your service is serving its users. The key word is "carefully chosen." Not every metric is a good SLI most internal system metrics (CPU usage, memory pressure, garbage collection pauses) measure system health from the inside. SLIs measure service quality from the outside from the user's perspective.

An SLI is always a ratio: good events divided by total events. This normalises for scale — whether you handle 100 requests or 100 million, the ratio tells you the same story. A raw count of errors is useless without context; an error rate (errors divided by total requests) is actionable.

Two important subtleties: first, you must define what counts as a "good" event. "Successful" is ambiguous does a 200 OK response that returns incorrect data count? Usually not. A good event is one that served the user correctly, which means you must define correctness. Second, you must define the measurement window. An SLI measured over the last minute behaves very differently from one measured over 28 days.

The four SLI categories

Most services can be characterised by four types of SLIs, originally defined in the SRE Book:

SLO — the target that governs everything

A Service Level Objective is a target value for an SLI over a defined time window. It is the internal engineering commitment the threshold below which the team declares itself to be failing its users. SLOs are not aspirations; they are commitments that should change team behaviour when they are violated.

An SLO has three components: the SLI it is based on, the target value, and the time window. All three are required. "We want 99.9% availability" is incomplete 99.9% over what period? Over the last hour? The last year? A 99.9% monthly SLO allows 43 minutes of downtime per month. A 99.9% annual SLO allows 8.7 hours. These are very different commitments.

The time window question

The most common time window choices are rolling 28 days (or 30 days), rolling 7 days, or calendar month. Rolling windows are preferred for SLOs because they provide a continuous, always-current view of reliability you always know whether you are within budget right now. Calendar months create a reset effect: you could have a terrible last week of the month and then reset to a clean slate on the first.

Rolling 28 days is the most widely used window in production SRE because it aligns roughly with four calendar weeks, is long enough to smooth out short-term noise, and short enough to recover from within a reasonable timeframe if you invest in reliability improvements.

SLA — the external promise with consequences

A Service Level Agreement is a contract typically between a service provider and a paying customer that defines the reliability standards the provider commits to and the remedies (usually service credits or refunds) that apply if those standards are not met. SLAs are commercial documents as much as technical ones. They are written by lawyers as well as engineers.

The critical relationship between SLOs and SLAs: your SLA target must always be less strict than your internal SLO. If your internal SLO is 99.9%, your SLA might commit to 99.5%. This safety margin serves two purposes: it gives you time to detect and respond to an SLO violation before it becomes an SLA breach, and it prevents the absurd situation where your internal engineering target is identical to your external legal commitment leaving zero room for error.

How the three connect — the complete picture

Now that each term is clear, let's see how they stack into a single coherent framework from raw measurement all the way to customer commitment.

Choosing the right SLIs — measure what users experience

The most important principle when choosing SLIs: measure what the user experiences, not what the system reports about itself. CPU utilisation is not an SLI. Database connection pool usage is not an SLI. These are internal signals. The user does not care about your CPU they care whether their request succeeded and how fast it came back.

A useful test for any proposed SLI: "If this metric were perfect, would users definitely be happy?" If the answer is no if you could imagine a scenario where the metric is green but users are miserable it is not the right SLI. If a perfect metric guarantees a good user experience, you are measuring the right thing.

Practical SLI selection by service type

Setting SLO targets — the art of calibrating ambition

The most common SLO mistake is choosing a target based on what sounds impressive rather than what the service actually delivers. Setting an SLO of 99.99% when your service historically runs at 99.5% is not aspirational it is self-deception. Your SLO should reflect your current capability and your users' actual needs, with a realistic improvement trajectory built in over time.

The four-step process for setting an initial SLO

Step 1: measure your current performance. Before setting any target, measure what your service is actually delivering today. Do this over 90 days minimum to understand the baseline and seasonal patterns. Step 2: understand what your users need. A payment processing service needs far higher availability than an internal analytics dashboard. The target should reflect the real impact of failure on users. Step 3: set the target slightly below your current performance. Not so low that there is no incentive to improve, but low enough that you are not constantly violating it. Start at roughly the 5th percentile of your last 90 days' performance. Step 4: build in a ratchet. Commit to reviewing SLOs quarterly and tightening them as the service improves. This creates a continuous improvement trajectory without the demoralising effect of setting targets you cannot meet.

Real-world examples — worked end-to-end

Example 1: E-commerce checkout API

Example 2: Internal analytics dashboard

Notice how the targets differ dramatically between the two examples. A checkout API failure costs the business money in real time high availability target, latency SLO, commercial SLA. An internal dashboard failure means analysts have to wait or use another tool relaxed SLO, no SLA. The targets reflect the real cost of failure to the business and its users.

The most common SLI/SLO/SLA mistakes