Service Level Objective

Origin & evolution

The concept was formalised by Google's Site Reliability Engineering practice, founded by Ben Treynor Sloss, who coined the term Site Reliability Engineering. The canonical treatment is the chapter Service Level Objectives in the Site Reliability Engineering book (O'Reilly, 2017). It draws three terms apart with care. A service level indicator🌡️Service Level IndicatorDevOps & PlatformA service level indicator (SLI)View reference → is the measurement, the actual ratio of good requests to total. A service level objective is the target set for that measurement. A service level agreement⏱️Service Level AgreementCustomer SuccessA service level agreement with customersView reference → is the contract with users that attaches consequences, usually financial, to meeting or missing the objectives🏁ObjectiveStrategyA strategic goal (OKR)View reference → inside it.

The genuinely original move was the error budget, built on the observation👁️ObservationUser ResearchA specific behaviour or statement observedView reference → that 100 percent is the wrong reliability target for almost everything, because no user can tell the difference between 100 percent and 99.999 percent available. If the objective is 99.9 percent, the remaining 0.1 percent is a budget the team is allowed to spend on releases🚢ReleaseProduct SpecificationA shipped version of the productView reference →, experiments🧫ExperimentValidationA test designed to validate a hypothesisView reference →, and risk🎲RiskComplianceA risk to the product or businessView reference →. The budget reframed reliability as a resource to allocate, and it gave product and operations a shared, unemotional rule: while there is budget, ship; once it is spent, freeze features⭐FeatureProduct SpecificationA product capability or featureView reference → and stabilise. Google's own framing is that the error budget⏳Error BudgetDevOps & PlatformAn error budget for a serviceView reference → removes the politics from arguments between developers who want to launch and operators who want stability.

The practice matured into a discipline of its own, covered at length in the follow-up SRE Workbook. The recurring lesson there is that the maths is the easy part. The hard part is choosing an objective that reflects what users actually feel, and resisting the urge to set a number you cannot defend when it bites.

How it works in practice

A team sets an objective on its checkout API: 99.95 percent of requests in a rolling 28-day window should return successfully. That permits roughly twenty-one minutes of full unavailability per window. The indicator is the ratio of good requests to total, measured at the load balancer, so the number reflects what users hit rather than what the servers think happened.

A risky migration burns nine minutes of budget in one bad afternoon. With twelve minutes left, the team pauses the next two feature releases and spends a sprint hardening the deploy pipeline. Nobody debates whether reliability is "good enough", because the budget already answered the question. The quarter ends with the objective met and the pipeline safer, and the decision⚖️DecisionStrategyA recorded decision with context, rationale, and consequencesView reference → to slow down was a reading off a gauge rather than a fight between two teams.

Service level objective vs. its neighbours

• Service level indicator is the raw measurement, the percentage of successful requests as it stands. The objective is the line drawn on that measurement. The indicator is a fact about the present; the objective is a commitment about the window.
• Service level agreement is the external, contractual promise to customers, with penalties if breached. The objective is the internal target, set deliberately stricter so the team reacts before the contract is at risk. You measure against the objective and report against the agreement, and the gap between them is your safety margin.
• Error budget is the allowance the objective generates: one minus the objective, expressed as permitted failure. The objective sets the bar; the budget is what you have left to spend before you hit it. One is the target, the other is the runway to it.

In the graph

In the Unified Product Graph, the canonical type is service_level_objective🥅Service Level ObjectiveDevOps & PlatformA service level objective (SLO), with the older abbreviation slo🥅Service Level ObjectiveDevOps & PlatformA service level objective (SLO) deprecated in its favour so the full vocabulary reads plainly in the graph. It is a hub in the Operations and Quality region with devops as its home domain. The inbound product_commits_to_service_level_objectiveProductcommits toService Level Objectivehierarchy records that an objective is a promise the product makes, not a passive metric🔢MetricStrategyA unified metric that measures progress, health, or behaviour across the productView reference →. Its outbound edges assemble the SRE vocabulary in one structure: service_level_objective_measured_by_service_level_indicatorService Level Objectivemeasured byService Level Indicatorhierarchy ties it to the measurement, and service_level_objective_budgets_as_error_budgetService Level Objectivebudgets asError Budgethierarchy ties it to the allowance it produces. The cross-domain edges make it answerable across the organisation: service_level_objective_satisfies_service_level_agreementService Level ObjectivesatisfiesService Level Agreementcross-domain connects the internal target to the external promise, and service_level_objective_tracks_metricService Level ObjectivetracksMetriccross-domain reaches into Analytics. That structure keeps the three letters from collapsing into each other, because each term holds a distinct, queryable place.