SLI, SLO, SLA

In a Nutshell

These three acronyms are how teams define, target, and promise reliability in measurable terms. An SLI (Service Level Indicator) is a measurement of how the service is performing — e.g., "99.95% of requests succeeded this month." An SLO (Service Level Objective) is your internal target for that indicator — "we aim for 99.9% success." An SLA (Service Level Agreement) is a contractual promise to customers with consequences if broken — "99.9% uptime or you get a refund." They nest: SLIs measure, SLOs target, SLAs promise. Together with the error budget they produce, they turn the fuzzy goal of "be reliable" into concrete numbers that guide engineering decisions and balance reliability against velocity.

How It Actually Works

The Three Levels

Term	What It Is	Audience	Example
SLI	A measured indicator of service level	Internal (data)	99.95% of requests < 300ms
SLO	An internal target for an SLI	Internal (goal)	99.9% of requests < 300ms/month
SLA	A contractual promise with penalties	External (contract)	99.9% uptime or 10% credit

SLI  = what you MEASURE     ("99.95% succeeded")
SLO  = what you TARGET      ("aim for 99.9%")   ← internal, stricter
SLA  = what you PROMISE     ("99.9% or refund") ← external, has teeth

Key relationship: your SLO should be stricter than your SLA, so you notice and fix problems before you breach the customer promise and owe penalties.

What Makes a Good SLI

An SLI should measure what users actually experience, expressed as a ratio of good events to total events:

SLI = good events / total events

Availability SLI:  successful requests / total requests
Latency SLI:       requests < 300ms / total requests
Quality SLI:       requests served without error / total requests

Base SLIs on the four golden signals (latency, errors) from the USER's
perspective — not internal metrics like CPU that users don't feel.

The Error Budget: The Most Powerful Idea Here

An SLO of 99.9% implicitly says you're allowed to fail 0.1% of the time. That allowance is your error budget — and it's a feature, not a bug:

SLO = 99.9% availability  →  error budget = 0.1% = ~43 minutes/month of
                             allowed downtime/failures.

The error budget is a BUDGET you can SPEND:
  - Budget remaining → ship features, take risks, deploy faster.
  - Budget exhausted → freeze risky changes, focus on reliability.

This resolves the eternal dev-vs-ops tension: 100% reliability is neither
achievable nor worth the cost. The error budget makes the trade-off
EXPLICIT and DATA-DRIVEN instead of a political argument.

The error budget aligns incentives: developers who want to ship fast and SREs who want stability now share one number that objectively says whether it's safe to take risks.

Why Not Aim for 100%?

Each additional nine costs exponentially more (redundancy, complexity, ops).
And beyond a point, users can't even tell:
  - The user's own network/device is often less reliable than 99.99%.
  - Chasing 100% means shipping nothing (every change is a risk).

The right SLO is the LEAST reliable you can be while keeping users happy —
freeing budget for features. Reliability is a means, not an end.

Choosing SLO Targets

Consideration	Effect on Target
User expectations	Higher for critical paths (payments) than nice-to-haves
Cost of each nine	Diminishing returns — don't over-invest
Business criticality	Core revenue paths get stricter SLOs
Achievability	Set targets you can actually meet and measure

Not everything needs the same SLO — a payment flow might target 99.99%, a recommendation widget 99.5%.

How They Drive Action

SLIs measured continuously → compared to SLO → error budget tracked.
  Burning budget too fast → alert → investigate/slow down.
  Budget healthy → proceed with feature work and deploys.
  Approaching SLA breach → escalate before penalties trigger.
Monitoring, alerting, and release decisions all key off these numbers.

Seeing It in Action

Scenario: Defining reliability targets for an e-commerce checkout service.

Define SLIs (measure what users feel, good/total):
  Availability SLI:  successful checkout requests / total checkout requests
  Latency SLI:       checkouts completing < 500ms / total checkouts

Set SLOs (internal targets, stricter than the SLA):
  Availability SLO:  99.95% of checkouts succeed (monthly)
  Latency SLO:       99% of checkouts < 500ms

Set the SLA (external promise, looser, with penalties):
  SLA: 99.9% checkout availability, or affected enterprise customers
       receive a service credit.
  (SLA 99.9% < SLO 99.95% → the internal target gives buffer to fix
   issues BEFORE breaching the contract and owing credits.)

Error budget (from the 99.95% SLO):
  0.05% of requests may fail = the monthly error budget.
  At 2M checkouts/month → budget ≈ 1,000 failed checkouts.

How it drives decisions through the month:
  Week 1: a bad deploy burns 40% of the budget in one incident.
    → Still budget left → keep shipping, but watch closely.
  Week 3: another incident pushes budget to 90% consumed.
    → Error-budget policy kicks in: FREEZE risky deploys, redirect the
      team to reliability work (add retries, circuit breakers, tests)
      until the budget recovers next period.
  Meanwhile: alerting is tuned to the burn RATE — a fast burn pages
    on-call immediately; a slow burn is a ticket. This avoids both
    alert fatigue and missing a real fire.

Contrast with vague "be reliable":
  ✗ Without SLOs: every incident is a subjective argument about whether
    to slow down. Dev wants features; ops wants stability; no shared truth.
  ✓ With an error budget: one objective number decides. Budget healthy →
    ship. Budget gone → stabilize. No politics.

Why SLIs, SLOs, and error budgets transform how teams operate: the deepest value isn't the measurement itself — it's that these numbers turn reliability from a vague aspiration and a source of endless dev-vs-ops conflict into an explicit, data-driven engineering discipline. The SLI grounds everything in what users actually experience (good events over total), the SLO sets a deliberate target that's stricter than the customer-facing SLA so you have room to react before owing penalties, and the error budget — the reliability you've chosen to allow — becomes a currency the whole organization shares. When the budget is healthy, the team ships features and takes reasonable risks; when it's exhausted, the same objective number tells everyone to stop and stabilize, ending the political argument that otherwise dominates every incident. Critically, this framework also embraces that 100% reliability is the wrong goal — it's exponentially expensive, users can't perceive the last nines over their own flaky networks, and chasing it means never shipping. The right SLO is the least reliable you can be while keeping users happy, which frees budget for the feature velocity that actually drives the business. Reliability, in this view, is a means to a happy user, not an end in itself — and SLIs/SLOs/error budgets are the tools that let you dial it precisely rather than guess.

Interview Questions

1. Q: Define SLI, SLO, and SLA and how they relate. Hint: SLI = a measured indicator of service performance (e.g., 99.95% of requests succeeded). SLO = your internal target for that indicator (e.g., aim for 99.9%). SLA = a contractual promise to customers with penalties if broken (e.g., 99.9% or a credit). They nest: SLIs measure, SLOs target, SLAs promise. The SLO should be stricter than the SLA so you catch and fix issues before breaching the contract.

2. Q: What is an error budget and why is it useful? Hint: The allowed unreliability implied by an SLO — a 99.9% SLO means a 0.1% error budget (~43 min/month). It's a budget you can spend: when budget remains, ship features and take risks; when it's exhausted, freeze risky changes and focus on reliability. It makes the reliability-vs-velocity trade-off explicit and data-driven, resolving the dev-vs-ops tension with one shared, objective number.

3. Q: What makes a good SLI? Hint: It measures what users actually experience, expressed as a ratio of good events to total events (successful requests / total requests; fast requests / total requests). Base SLIs on user-facing signals (latency, errors/availability) rather than internal metrics like CPU that users don't feel. A good SLI moves when users are unhappy and stays flat when they're fine.

4. Q: Why shouldn't you aim for 100% reliability? Hint: Each additional nine costs exponentially more (redundancy, complexity, ops), and beyond a point users can't perceive it — their own network/device is often less reliable than 99.99%. Chasing 100% means never shipping (every change is a risk). The right SLO is the least reliable you can be while keeping users happy, freeing error budget for feature velocity. Reliability is a means, not an end.

5. Q: Why should your SLO be stricter than your SLA? Hint: The SLA is a customer-facing promise with financial/contractual penalties. Setting the internal SLO stricter gives you a buffer — you detect and react to reliability problems (via error-budget burn and alerts) before you approach the SLA threshold, so you can fix issues before breaching the contract and owing credits or damaging trust. The gap between SLO and SLA is your safety margin.

References

• Google SRE Book — Service Level Objectives — the definitive treatment
• Google SRE Workbook — Implementing SLOs — practical SLO/error-budget setup
• Atlassian: SLA vs SLO vs SLI — clear distinctions

Dive Deeper

• The Site Reliability Workbook — Error budget policies — turning budgets into policy
• Implementing SLOs (Alex Hidalgo) — a full book on SLOs
• Multi-window, multi-burn-rate alerting — alerting on error-budget burn