What Is an SLO? Service Level Objectives Explained

An SLO (service level objective) is an internal target for how well a service should perform — typically an uptime percentage, latency threshold, or error rate. Unlike an SLA, which is a contract with customers that carries financial penalties, an SLO is a goal the engineering team sets for itself. A team might set an SLO of 99.95% availability for their API, even if the customer-facing SLA only promises 99.9%. The gap between the two is the safety margin — room for planned maintenance, deployments, and the occasional bad day without breaching the contractual commitment.

The concept comes from Google's Site Reliability Engineering (SRE) practice and has spread across the industry as a way to make reliability decisions concrete. Without an SLO, "is the service reliable enough?" is a subjective debate. With one, it becomes a measurable question: are we above or below the target this month?

SLOs, error budgets, and trade-offs

An SLO creates an error budget — the amount of unreliability you can afford within the target. At 99.95% monthly availability, your error budget is roughly 22 minutes of downtime. As long as you haven't burned through the budget, you can ship features, run migrations, and deploy with normal confidence. When the budget runs low, the team shifts focus from shipping to stabilizing. This is what makes SLOs useful in practice: they turn reliability from an abstract value into a resource you spend and track, the same way you'd track a sprint budget or a cloud bill.

SLOs and monitoring

Uptime monitoring provides the raw data to measure an SLO — every check is a data point toward the availability calculation. SLA reports show the actual uptime percentage over a period, making it straightforward to compare against the target. When the service dips below the SLO, incident management tracks the response, and the MTTR data shows how quickly the team recovered.

Related terms: SLA, uptime, MTTR, incident management