An SLI is what you measure. An SLO is the target you set for it. An SLA is what you promise a customer, with a penalty attached if you miss. People use these terms interchangeably and it causes real arguments about what “reliable enough” means.

The three terms, plainly

SLI (Service Level Indicator) — a measurement. “The percentage of requests that returned in under 300ms” or “the percentage of requests that returned a 2xx or 3xx status.” It’s a number you can compute from data you already have (logs, metrics).

SLO (Service Level Objective) — an internal target for that measurement. “99.9% of requests return in under 300ms, measured over a rolling 30 days.” This is the number your team works toward. It’s internal — no one outside engineering needs to see it.

SLA (Service Level Agreement) — an external promise, usually contractual, usually with a consequence. “99.9% uptime or you get a service credit.” An SLA is built on top of an SLO, but it’s not the same thing — it’s the subset of your reliability target you’re willing to be held to financially.

How they connect

flowchart LR
    A[Raw data: logs, metrics] --> B["SLI (measurement)"]
    B --> C["SLO (internal target)"]
    C --> D["SLA (external promise)"]
    D --> E["Penalty if missed (credit, refund)"]
  

The direction matters. You don’t start by picking an SLA and working backwards — you start by measuring what you actually have (SLI), set an internal target with margin (SLO), and only then decide what subset of that you’re comfortable promising externally (SLA), with room to spare.

Why the gap between SLO and SLA matters

Your SLO should be stricter than your SLA. If your SLA promises 99.9% uptime, set your internal SLO at 99.95%. That gap is your safety margin — it means you find out you’re at risk of breaching the SLA while you still have room to react, instead of finding out from a customer’s support ticket.

Term	Audience	Consequence of missing it
SLI	Engineering	None — it’s just a number
SLO	Engineering, product	Internal: prioritize reliability work
SLA	Customers, legal	External: credits, refunds, churn risk

A concrete example

Say you run an API.

• SLI: percentage of requests completing in under 500ms, and percentage returning non-5xx, both measured per rolling 28-day window.
• SLO: 99.9% of requests under 500ms, 99.95% non-5xx.
• SLA: 99.9% monthly uptime (defined as the non-5xx measurement), with a 10% service credit if you fall below that and a 25% credit below 99%.

Notice the SLA only picked up one of the two SLIs (uptime, not latency) — that’s a real choice teams make, because promising a latency SLA is harder to define cleanly and harder to defend in a dispute.

The mistake to avoid

Don’t set an SLO you can’t measure, and don’t promise an SLA you haven’t been meeting internally for a while first. If you’ve never tracked your actual uptime, you don’t know if 99.9% is a stretch goal or something you’re already blowing through weekly. Measure for a month before you commit to anything a customer can hold you to.

Once you have an SLO with a margin below the SLA, the next practical question is what you do when you’re burning through that margin faster than expected — that’s what an error budget is for.

---