SLI / SLO / SLA

"Is the store reliable enough?" is a question nobody can answer without numbers. The product manager wants to ship a new checkout this week; the on-call engineer says the order service had a bad month and wants to freeze deploys. Without a shared definition of "good enough", that discussion is opinion against opinion. Measuring reliability requires a shared vocabulary that connects raw telemetry to engineering decisions to customer commitments. Google's Site Reliability Engineering practice introduced a three-tier model for this purpose¹, now standard across the industry.

flowchart LR
    telemetry["Telemetry\n(logs, metrics, traces)"]
    sli["SLI\nRaw measurement"]
    slo["SLO\nInternal target"]
    sla["SLA\nExternal contract"]
    budget["Error Budget\nEngineering lever"]

    telemetry e1@-->|aggregated into| sli
    sli e2@-->|evaluated against| slo
    slo e3@-->|informs| sla
    slo e4@-->|remainder becomes| budget

    e1@{ animate: true }
    e2@{ animate: true }
    e3@{ animate: true }
    e4@{ animate: true }

SLI — The Raw Measurement

An SLI is a quantitative metric pulled directly from instrumentation that reflects user-perceived system quality. Not every metric is a good SLI; only those that correlate with whether the user is getting value from the service.

The most useful way to write an SLI is as a ratio of events, so that it always lies between 0% and 100%²:

For example: "the proportion of GET /products requests that return a non-5xx status in less than 300 ms". "Valid" lets you exclude events that should not count, such as 4xx responses caused by the client.

Canonical SLI categories

How SLIs are collected

• Application-level instrumentation: request counters and latency histograms exported via Spring Boot Actuator / Micrometer (Hands-on 6).
• Synthetic monitoring: probes that send real requests from outside the system on a schedule (e.g. Prometheus Blackbox Exporter).
• Log-based: parsing access logs to count 2xx vs 5xx responses.
• Client-side: measuring from the browser or mobile client for true end-user experience.

sum(rate(http_server_requests_seconds_count{application="order", status!~"5.."}[5m]))
/
sum(rate(http_server_requests_seconds_count{application="order"}[5m]))

SLO — The Target You Commit To

An SLO is a specific, time-bound target for an SLI. It answers: "How good does this metric need to be for us to consider the service healthy?"

Format:

SLI ≥ threshold over a rolling window

A rolling window always covers the last N days (for example, from 28 days ago until now), so it moves forward every minute; a calendar window resets on the 1st of each month.

Examples:

Choosing the right SLO

SLOs must be ambitious but achievable. An SLO that is never breached is not driving reliability work — it is too loose. An SLO that is constantly breached is noise — the team stops trusting it.

• Start by measuring the current SLI over 30–90 days.
• Set the initial SLO at the observed baseline minus a small buffer.
• Tighten it over time as the system improves.
• Make SLOs public within the engineering org so all teams understand the targets they are building toward.
• Remember composite availability (overview): a service cannot promise more than the product of the services it synchronously depends on.

Error Budget

The error budget is the quantity of unreliability the SLO permits. It is the engineering team's licence to take risk.

For a 99.9% availability SLO, the budget is 0.1% — of the time or of the requests in the window, depending on how the SLI is defined.

If the error budget is intact, the team can:

• Deploy frequently and accept some deployment risk
• Run experiments on production systems
• Take on more technical debt

If the error budget is exhausted, the team must:

• Freeze non-essential deployments
• Prioritise reliability work over feature work
• Investigate and fix the root causes consuming the budget

These rules only work if they are agreed in advance: an error budget policy is a short document, signed by product and engineering, that says what happens when the budget runs out.

Burn rate

Burn rate measures how fast the error budget is being consumed relative to the SLO window²:

With a 99.9% SLO, an error rate of 0.1% is a burn rate of 1 — the budget lasts exactly the whole window. An error rate of 1.44% is a burn rate of 14.4. A burn rate of \(b\) exhausts the budget in (window ÷ \(b\)).

For a 28-day window:

The thresholds 14.4× and 6× come from the SRE Workbook: sustained for 1 hour, a 14.4× burn consumes about 2% of the budget; sustained for 6 hours, a 6× burn consumes about 5%. (The Workbook derives them for a 30-day window; with 28 days the percentages are almost the same.) High burn-rate alerts catch fast-moving incidents early, while low burn-rate alerts catch slow degradation that would otherwise be invisible².

# Prometheus alerting rule (99.9% SLO → budget = 0.001)
- alert: OrderErrorBudgetFastBurn
  expr: |
    (
      sum(rate(http_server_requests_seconds_count{application="order", status=~"5.."}[1h]))
      /
      sum(rate(http_server_requests_seconds_count{application="order"}[1h]))
    ) > (14.4 * 0.001)
  for: 2m
  labels:
    severity: page

SLA — The Contractual Commitment

An SLA is a formal agreement between service provider and customer that defines the expected level of service and the remedies (typically service credits) if that level is not met. SLAs are legal documents; missing them has financial consequences.

Structure of an SLA

1. Covered services — which products and regions are in scope
2. SLO targets — the availability or latency commitments
3. Measurement methodology — how uptime is calculated, which incidents count
4. Exclusions — scheduled maintenance, force majeure, customer-caused outages
5. Remedies — service credit schedule for each tier of breach

Real-world SLA examples

The commitments below are taken from the providers' public SLA pages³⁴; the exact conditions (deployment type, region, credit tiers) change over time, so always read the current page.

Notice two things. First, the higher numbers apply only when you deploy redundantly (multiple zones, Multi-AZ) — redundancy is the price of the extra nine. Second, the remedy is a credit on your bill, not compensation for your lost sales: an SLA transfers some financial risk, it does not make your system available.

SLA vs SLO

SLA and SLO are often confused. The critical distinction:

Best practice: set your SLO stricter than your SLA. The buffer between SLO and SLA is the safety margin that prevents a reliability incident from triggering contractual penalties. If the SLA is 99.9%, the SLO might be 99.95%.

Best practices

Key takeaways

• An SLI is a ratio of good events to valid events that reflects what users feel; an SLO is a target for it over a window; an SLA is a contract with penalties, looser than the SLO.
• The error budget is 1 − SLO, in time or in requests: 99.9% over 28 days ≈ 40.3 minutes (≈ 43.8 minutes over a 30.44-day month).
• Burn rate = observed error rate ÷ budget; 14.4× empties a 28-day budget in about 2 days and should page someone.
• The budget turns "ship or freeze?" into a data-driven decision — if there is an agreed policy.
• Always state the window and use percentiles, never averages, for latency.