What are SLI, SLO, and SLA?

SLIs, SLOs, and SLAs are the chain that makes a service's level of service measurable and negotiable during normal operation. The Service Level Indicator is the metric chosen, for example the share of HTTP requests served successfully within a given latency; the Service Level Objective is the internal threshold set on that metric, for example 99.9% of requests over a thirty-day window; the Service Level Agreement is the contractual commitment made to the customer, almost always set more permissive than the SLO and backed by a penalty if it is missed. The distinction between the three, codified by Google in the book Site Reliability Engineering, rests on a single question: what happens if the target is missed? With no explicit consequence, it is an SLO, not an SLA. Conflating them leads to setting the SLA as if it were the working SLO, with no room for the incidents that happen anyway.

The error budget makes the chain operational

A 99.9% SLO is not a promise of perfection: it is a statement that 0.1% of requests are allowed to fail over a period, and that allowance is the error budget. It is the concept that turns the triplet into a decision tool rather than a number for a slide: as long as the budget is not exhausted, the team can ship new releases and take calculated risks; once it is spent, further releases pause until reliability recovers headroom. Without an error budget, a 100% SLO blocks every change, because every deploy is a risk the number has no room to absorb; with it, reliability and release velocity become two variables of the same equation, not two priorities in permanent conflict.

An enterprise example

A SaaS provider of accounting software defines its SLI as the percentage of requests to the billing API answered within 500 milliseconds. The internal SLO the team uses to decide when to halt releases is 99.5% over a monthly window. The SLA signed with enterprise customers is 99.0%, with a service credit penalty if the month closes below threshold: the gap between the two numbers is deliberate: breaching the internal SLO raises the alarm while there is still room to act, before the degradation becomes visible to the customer and contractually relevant.

Why it matters for decision makers

The triplet needs to stay distinct from two neighboring topics: RTO and RPO cover how long a service stays down and how much data is lost after a disaster, not the level of service during normal operation, which is SLI/SLO/SLA territory. And observability is the ability to understand what is happening inside a system from its external signals: it is the instrument an SLI is measured with, not the SLI itself, which is the metric chosen as a promise. For whoever signs a supply contract, the useful question is not whether an SLA exists, but whether a stricter internal SLO stands behind it, and whether the error budget supporting it has ever been tested by a real incident: an SLA with no SLO behind it is a commercial number with no engineering backing it.