Quality Attributes

SLO (Service Level Objective)

Also known as: service level objective

Definition

An SLO is a target value for an SLI over a window — for example, 99.9% of requests succeed over 28 days. It is an internal commitment that defines how reliable a service intends to be, and its complement is the error budget the team is permitted to spend on change.

Last reviewed · Part of the Architecture Glossary

In practice

An SLO has four parts, and omitting any of them makes it unenforceable: SLI, target, window, scope.

99.9% of POST /checkout requests return non-5xx within 500 ms, measured at the edge load balancer, over a rolling 28 days.

The target should be chosen from the reliability users actually need, then sanity-checked against the reliability of your dependencies. A service calling three dependencies that are each 99.9% cannot exceed roughly 99.7% availability by composition alone; promising 99.99% above them requires caching, fallbacks or redundancy, not intention.

Costs escalate sharply — each additional nine is roughly an order of magnitude more engineering. That is the argument for setting the SLO lower than the best you can do: an unnecessarily strict target spends the budget of a team that could be shipping.

When it matters

Every user-facing service; every dependency contract between teams; every argument about whether to freeze deploys.

Common mistake

Setting 99.99% because it sounds serious. That is 4m 19s of downtime per month — less than one bad deploy — and it commits the team to a change-management regime nobody agreed to. Use the calculator to see the number before you commit to it.

See also

Go deeper