Three Acronyms, One Framework

SLA, SLO, and SLI appear together constantly in SRE and DevOps literature. They're related but distinct, and confusing them leads to poorly designed reliability targets, bad alerting, and contracts that don't reflect reality.

Here's the short version:

SLI: what you measure
SLO: what you target
SLA: what you promise (and what you owe if you break the promise)

They form a hierarchy. Let's walk through each one.

SLI: The Metric

An SLI (Service Level Indicator) is a quantitative measure of some aspect of your service's behavior.

Good SLIs are:

Measurable in real time
Directly tied to user experience
Consistent and reproducible

Common SLIs:

Availability:  successful_requests / total_requests
Latency:       p95 response time (milliseconds)
Error rate:    5xx_responses / total_responses
Throughput:    requests processed per second
Freshness:     age of most recent data (seconds)

SLIs are just measurements. They don't tell you whether the number is good or bad; that's what SLOs are for.

SLO: The Target

An SLO (Service Level Objective) is a target value or range for an SLI over a given time window.

SLI:  availability = 99.87% (last 30 days)
SLO:  availability >= 99.9% (per month)

The SLO is your internal commitment. It drives engineering priorities, deployment decisions, and on-call behavior. When your SLI crosses the SLO boundary, something needs to change.

A practical SLO for a production API:

Availability SLO:  >= 99.9% over a rolling 30-day window
Latency SLO:       p95 < 200ms (hourly average)
Error rate SLO:    < 0.5% of requests return 5xx

One common mistake: setting SLOs too high because it "sounds good." 99.999% uptime means less than 5 minutes of downtime per year. For most teams, that level of reliability is expensive to achieve and expensive to maintain. Start with what's achievable and meaningful, then raise the bar as you improve.

SLA: The Contract

An SLA (Service Level Agreement) is a formal agreement between you and your customers that specifies what happens when you fail to meet a reliability target.

SLAs usually include:

A defined metric and target (the SLO you're publicly committing to)
A measurement window
Consequences for breach (service credits, refunds, termination rights)

Example SLA:

Availability commitment: >= 99.5% per calendar month
If breached:
  - 99.0% – 99.5%: 10% service credit
  - 95.0% – 99.0%: 25% service credit
  - Below 95.0%:   50% service credit

Notice the SLA target (99.5%) is lower than the internal SLO (99.9%). This is intentional. Your SLO gives you a buffer: if you're hitting 99.9% internally, you have headroom before you breach the customer-facing SLA.

How They Relate

SLI measures → "We served 99.87% of requests successfully"
SLO targets  → "We need to hit 99.9% or we're missing our goal"
SLA commits  → "We promise customers 99.5% or we owe credits"

The SLA should always be easier to meet than the SLO. If they're the same, one bad month triggers both an internal miss and a customer payout simultaneously.

Starting From Scratch

If you're defining these for the first time, keep it simple:

Step 1: Pick 1-2 SLIs that reflect user experience. For most web services, availability and p95 latency cover 90% of what users care about.

Step 2: Set an SLO based on historical data. Look at the last 90 days. What did you actually achieve? Set the SLO slightly above that as a stretch target.

Step 3: Set your SLA 0.5–1% below the SLO. This gives you a buffer.

Step 4: Track everything. An SLO you don't measure is just a number in a document.

How up0 Helps

up0 tracks availability and latency SLIs from 5 regions, letting you see whether you're on track to meet your SLO before the month ends. You can set SLO targets per monitor, watch error budget burn in real time, and configure alerts when burn rate exceeds a safe threshold, so you know about SLA risk before customers do.

SLA vs SLO vs SLI: A Practical Guide for Engineering Teams