SLO

An SLO is a target value for a Service Level Indicator (SLI). The SLI is the raw measurement, like the fraction of HTTP requests that return a 2xx or 3xx status, or the fraction of requests served faster than 300ms. The SLO is the line you draw on that measurement: "this number should stay at or above 99.9% over the last 28 days."

Three things sit close together and get confused. An SLI is what you measure. An SLO is the internal target for that SLI. An SLA (Service Level Agreement) is a contract with a customer that usually promises a weaker number than your SLO, with money or credits on the line if you miss it. A common pattern is an SLA of 99.9% backed by an internal SLO of 99.95%, so you have headroom before you ever breach the contract.

The key idea is that 100% is the wrong target. Chasing perfect uptime is infinitely expensive and stops you shipping features. An SLO names the actual reliability your users need and lets you stop there on purpose.

The number behind an SLO directly produces an error budget. If your availability SLO is 99.9% over 30 days, you are allowed to be unavailable for 0.1% of that window, which is about 43 minutes per month. That 0.1% is the budget you get to spend on bugs, bad deploys, and risky experiments.

You compute the SLI continuously, usually from request logs or metrics in Prometheus, Datadog, or a similar system. For an availability SLO that is good_requests / total_requests. You then track how much of the error budget is left. Burning the budget slowly is fine. Burning it fast, say half the month's budget in one hour, should page someone.

Teams use multi-window, multi-burn-rate alerts so they page on real problems instead of on every single failed request. A fast burn rate triggers an urgent page, a slow steady burn opens a ticket. This is how Google's SRE practice ties alerting to user-facing impact rather than to arbitrary CPU or memory thresholds.

Use SLOs when more than one team depends on a service and you need a shared, honest definition of "healthy." They are most useful as the deciding vote in the feature-versus-reliability argument: if the error budget is healthy, ship faster and take risks. If the budget is exhausted, freeze risky changes and spend the next sprint on stability. That removes opinion from the conversation and replaces it with a number.

The trade-offs are real. A bad SLI measures the wrong thing, so a service can hit 99.9% on paper while users are unhappy. Setting the target too high wastes engineering effort on reliability nobody asked for; setting it too low erodes trust. SLOs also need ongoing care: you must agree on the measurement window, pick which requests count, and revisit the target as traffic and expectations change.

Start with one or two SLOs per critical user journey, like "checkout completes" or "search returns results," not a dashboard of fifty metrics. Measure from the user's edge where you can, since a backend that is 99.99% healthy means little if the load balancer in front of it is dropping requests.

Say you run a payments API. You define one SLI as the fraction of POST /charge requests that return a success status, and a second as the fraction that complete within 500ms. You set an availability SLO of 99.95% and a latency SLO of 99% under 500ms, both over a rolling 28 days.

99.95% availability over 28 days gives you roughly 20 minutes of allowed downtime. A bad deploy that returns 500s for 8 minutes spends about 40% of the month's budget in one shot. Your burn-rate alert fires, the on-call engineer rolls back, and because you still have budget left, you keep shipping. If a second incident eats the rest of the budget, the team triggers a change freeze until the window rolls forward and the budget refills.

Over months this gives you a fair, data-driven record of whether the service met its promise, and a clear signal for when to invest in reliability versus when to keep building.