Service Level Agreement

Origin & evolution

The agreement and the engineering behind it grew up together but stayed distinct. Google's site reliability engineering practice gave the cleanest separation of the three terms that are still routinely confused. A service level indicator🌡️Service Level IndicatorDevOps & PlatformA service level indicator (SLI)View reference → (SLI) is a quantitative measure of some aspect of the service, such as latency or availability. A service level objective🥅Service Level ObjectiveDevOps & PlatformA service level objective (SLO)View reference → (SLO) is a target for that indicator, for example average latency under 120 milliseconds. A service level agreement (SLA) is the explicit contract with users that includes the consequences of meeting or missing the objectives🏁ObjectiveStrategyA strategic goal (OKR)View reference → it contains (Google SRE).

The hard-won lesson from that work is that the contractual number should sit looser than the internal one. Teams set the SLA threshold below the SLO they actually operate to, so the internal alarm sounds well before the contract is breached (Google Cloud). An SLA promising 99.9 per cent uptime is typically backed by an internal SLO of 99.95 per cent, leaving a buffer to fix problems before customers can claim credits.

The error budget⏳Error BudgetDevOps & PlatformAn error budget for a serviceView reference → formalised the buffer. The gap between perfect and the objective becomes a spendable quantity: as long as the budget holds, the team can ship and take risks🎲RiskComplianceA risk to the product or businessView reference →; when it runs low, reliability work takes priority. The SLA sets the floor a business is willing to be paid to defend.

How it works in practice

A payments API publishes an SLA of 99.9 per cent monthly uptime, which permits about 43 minutes of downtime in a 30-day month. The contract specifies the remedy: a 10 per cent service credit for breach in the 99.0 to 99.9 band, scaling to 30 per cent below 99.0.

Internally the team runs to an SLO of 99.95 per cent and watches an availability SLI computed from successful requests. In a month with a 25-minute outage, uptime lands at 99.94 per cent. The SLO is missed, so the on-call review and the error-budget freeze kick in, but the SLA holds, so no credits are owed. The buffer did its job🔨JobUserJob To Be Done: what the user is trying to accomplishView reference →: the internal target caught the problem the contract was never meant to absorb.

Service level agreement vs. its neighbours

• Service level objective is the internal target; the agreement is the external promise. The objective is what the team holds itself to and tunes freely. The agreement is negotiated, harder to change, and usually set looser, so the SLO trips first and the SLA stays safe.
• Service level indicator is the measurement underneath both. The indicator is the raw number, the objective is a target on it, and the agreement is a contract referencing it. Without a well-defined indicator, an agreement has nothing concrete to enforce.
• Contract is the broader legal instrument covering price, term, and liability. The agreement is the performance clause within or alongside it, the part that turns reliability into a commercial obligation with credits attached.

In the graph

In the Unified Product Graph, a service level agreement sits in the Customer Success region. The edge service_level_objective_satisfies_service_level_agreementService Level ObjectivesatisfiesService Level Agreementcross-domain encodes the buffer relationship directly: the internal objective is what keeps the external promise. product_guarantees_via_service_level_agreementProductguarantees viaService Level Agreementhierarchy ties the commitment to the product, service_level_agreement_governs_serviceService Level AgreementgovernsServicecross-domain binds it to the service it constrains, and service_blueprint_contains_service_level_agreementService BlueprintcontainsService Level Agreementhierarchy places it in the operational design. Separating the agreement, objective, and indicator into distinct connected types is what stops the common error of treating a contractual promise and an engineering target as the same thing.