Guides Jul 15, 2026 5 min read
What an SLO is, really
Service level objectives get explained with maths. They are easier to understand as a decision about who gets paged, and when.
Tomás Ferreira
An SLO, a service level objective, is usually introduced with a formula: the percentage of requests that succeed, over a window, compared to a target. That is the definition. It is not the point.
The point of an SLO is that it decides, in advance and in daylight, what is worth waking someone up for.
Uptime is the wrong number
"99.9% uptime" sounds like an SLO but is usually a marketing line. It does not say what counts as up, over what window, measured from where. A site that returns a blank page in 200 milliseconds is up by most monitors' definition and down by every customer's.
A real SLO names the thing customers experience. For a checkout API that is something like: 99.9% of POST /orders requests return a 2xx in under 800 milliseconds, measured over thirty days, from the customer's side of the load balancer.
The error budget
The useful thing about a percentage is that it has a complement. 99.9% over thirty days allows forty-three minutes of failure. That forty-three minutes is the error budget, and it changes the conversation from "is it down?" to "how much of this month's budget did that cost us?"
An outage that burns ten minutes at 3am is worth a page. A slow hour that burns two minutes is worth a ticket in the morning. The SLO tells you which is which without anyone having to argue about it during the incident.
Who gets paged, and when
This is the decision an SLO really encodes. Page when the budget is burning fast enough that, at this rate, it will be gone before the window ends. Do not page for a blip that costs seconds. Do not page for a slow decline that a ticket can catch tomorrow. Write those thresholds down, and the on-call engineer's phone stops being a lottery.
In Carbon
Every monitor can carry an SLO: the success condition, the latency ceiling, the target, and the window. The status page publishes the current budget, the incident opens when the burn rate crosses the line you set, and the monthly report says how much of the budget was spent and on what. The maths is done for you. The decision was always yours.
More from the blog
- Aug 27, 2026 Why we check every thirty seconds Most monitors check every three to five minutes. That interval was chosen for the monitor's budget, not for yours. Here is what the extra checks actually buy.
- Aug 12, 2026 Writing a status update at 3am The best incident communication we have seen came from people who had a template, a rule about timing, and permission to say 'we do not know yet'.
- Jul 30, 2026 Logs without sampling Sampling was a storage decision dressed up as a feature. Here is how we index every line and still answer a query over a month of logs in under a second.