service-level objective (SLO)

A service-level objective, or SLO, is a target value or range for some measurable aspect of a service, such as availability or response time. It turns a vague promise like “the API should be reliable” into a number the team commits to and can check against, for example 99.9 percent of requests succeeding over a rolling thirty-day window. Google’s SRE Workbook suggests making the window an integral number of weeks, with four weeks as its general-purpose default, so every window contains the same number of weekends.

The thing being measured is a service-level indicator, or SLI, the raw metric itself. The SLO is the goal set on top of it. Google’s SRE book frames the SLI as “a carefully defined quantitative measure” and the SLO as “a target value or range of values for a service level that is measured by an SLI.” These pieces, plus the error budget and the service-level agreement (SLA), fit together like this:

An SLI box flows down to a teal SLO box, which points to an SLA box (stricter than) and, by a dotted gap to arrow, to a yellow Error budget circle that a 100 percent perfection box also points to.
The SLO is the target on top of the SLI, and its gap to 100 percent is the error budget the SLA stays clear of.

The gap between an SLO and perfection is the team’s error budget. A 99.9 percent target over thirty days leaves a small, explicit allowance for failure:

Python 
>>> slo = 0.999
>>> window_minutes = 30 * 24 * 60
>>> error_budget_minutes = (1 - slo) * window_minutes
>>> round(error_budget_minutes, 1)
43.2

Read as an availability target measured over time, three nines a month works out to about forty-three minutes of downtime the team can spend before the objective is at risk. For the request-based SLO in the opening example, the same budget is instead 0.1 percent of the month’s requests, so a service handling three million requests can fail about three thousand of them.

How It Shows Up in Practice

A Python developer meets SLOs as the targets wired into a service’s dashboards and alerts. The numbers come from observability data, and an alert usually fires when the service is burning its error budget fast enough to put the objective at risk.

A good SLO measures what users actually feel, such as successful page loads, rather than something convenient but irrelevant like CPU usage. Common SLO types cover availability, latency, and error rate. Teams keep the count of objectives small, because every SLO is a promise someone has to watch and defend.

SLO vs. SLA

An SLO is an internal target. A service-level agreement, or SLA, is the external version, a contract with customers that attaches consequences, often refunds or service credits, to missing the objectives it contains.

Because breaking an SLA costs real money, teams deliberately set their internal SLOs stricter than the SLA promises, which leaves a buffer to react before a customer-facing commitment is breached. The service-level agreement entry covers how that contract and its penalties work.

Python Timer Functions: Three Ways to Monitor Your Code

Tutorial

Python Timer Functions: Three Ways to Monitor Your Code

In this step-by-step tutorial, you'll learn how to use Python timer functions to monitor how quickly your programs are running. You'll use classes, context managers, and decorators to measure your program's running time. You'll also learn the benefits of each method and which to use given the situation.

intermediate python stdlib

For additional information on related topics, take a look at the following resources:

By Martin Breuss • Updated Sept. 7, 2026
Software Engineering Glossary Share Feedback