SLI / SLO / SLA

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.

Canonical SLI categories

How SLIs are collected

• Application-level instrumentation: request counters and latency histograms exported via Spring Boot Actuator / Micrometer.
• 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.

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

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.

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 over 28 days:

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

Burn rate

Burn rate measures how fast the error budget is being consumed relative to the SLO window. A burn rate of 1 means the budget will be exactly exhausted by the end of the window. A burn rate of 2 means the budget will run out in half the window.

High burn-rate alerts catch fast-moving incidents early, while low burn-rate alerts catch slow degradation that would otherwise be invisible².

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

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