Error Budget and Burn Rate: Setting Up SLO Monitoring

Cleanly Separating SLI, SLO and SLA

The three terms are often used interchangeably - and that is exactly what creates false expectations. They describe three different things that build on one another. An SLI (Service Level Indicator) is the value actually measured: real availability, say 99.94% last month. An SLO (Service Level Objective) is the internally set target for that value, for example 99.9% over 30 days. An SLA (Service Level Agreement) is the contractual commitment to the customer, legally binding and with consequences for non-compliance (Atlassian).

The order matters: the SLI provides the measurement, the SLO sets the internal target on top of it, and the SLA is the external promise that rests on that target (SigNoz). In practice the SLO should therefore stay stricter than the SLA - the buffer between them is your safety margin. If you promise a customer 99.5%, you should aim internally for 99.9% so that a minor disruption does not immediately trigger a contract breach. An SLO of 99.99% specifically means that downtime over a month must stay below 4.32 minutes (Atlassian) - a mark that is hard to hold without continuous measurement.

In practice, many teams fail not at the technology but at confusing these layers. Whoever mistakes the SLI for the goal optimises the measurement instead of the outcome. Whoever equates the SLO with the SLA gives up the safety buffer and effectively leaves the customer no reserve. It makes sense to start with a few clearly defined SLOs - ideally for the most important user paths - and to expand them only once the measurement runs reliably (Nobl9). A single, cleanly measured availability SLO for the homepage is worth more than a dozen half-baked metrics that nobody maintains.

What matters is the insight that an SLO should track the user experience, not pure infrastructure. A response-time measurement of 200 milliseconds is worthless if checkout still loses half the orders. Nobl9 puts it this way: such measurements tell you whether the infrastructure is running, but not whether the user can complete their task (Nobl9). A good SLO therefore reflects a real user interaction - the reachability of the homepage, a working login, the load time of the product page.

What 99.9 Percent Really Means

The error budget is simply the inverse of the SLO: error budget = 100% minus SLO (Google SRE Book). At 99.9%, that leaves 0.1% of the time for outages - and 0.1% of a month is exactly those 43.8 minutes. Each additional nine tightens this dramatically: the jump from 99.9% to 99.99% cuts the monthly budget from roughly 43 minutes to just over 4 minutes (Google SRE Book - Availability Table). Nobl9 explicitly notes that each further nine costs exponentially more while typically delivering diminishing value to the user (Nobl9). Realistic targets beat perfect targets.

This table is the reality check for any availability promise. Anyone promising customers 99.99% effectively leaves no maintenance window - a single poorly planned deploy can consume the monthly budget. The gap between hosting marketing and actual headroom is also covered in the article comparing hosting uptime guarantees, and how to calculate an SLA correctly is explored in the article on understanding and calculating uptime SLAs.

Burn Rate: How Fast the Budget Burns

The burn rate describes how quickly the error budget is consumed. A burn rate of 1 means the budget is used up at exactly the expected pace - it lasts precisely until month end. A burn rate of 2 consumes twice as fast: the budget is exhausted after 15 days instead of 30. This value is the decisive early warning. Anyone who only checks availability at month end notices a gradual decline only once the SLA has already been breached.

The advantage of the burn rate over a plain uptime figure lies in the speed of detection. A momentary disruption with a high burn rate eats large parts of the budget in a short time. Instead of waiting until an arbitrary threshold such as 99% is reached, the burn rate alerts as soon as the consumption pace becomes dangerous. This shifts the question from Is the site down right now? to Are we burning our budget too fast? - and that is exactly the actionable question.

A vivid calculation makes the difference tangible. With an SLO of 99.9%, the monthly budget is 43.8 minutes. If a service goes fully down for one hour, the entire budget for a month is exceeded in a single incident - the burn rate in that window is far above a factor of 1. If the same one-hour outage instead occurs spread out as six short disruptions over the quarter, the average burn rate stays moderate and the budget may well suffice. The same total downtime can therefore be uncritical or fatal depending on its distribution - and only the burn-rate view reliably distinguishes the two cases.

Multi-Window Burn-Rate Alerts Against Alert Fatigue

This is where the real craft lies. A single threshold produces either too many false alarms or reacts too slowly. Alert too sensitively and the team is flooded with noise; alert too sluggishly and a real disruption goes unnoticed for a long time. The result is alert fatigue - and it is measurably dangerous: in the SANS Detection and Response Survey 2025, a large share of alerts went unaddressed - roughly 67% are ultimately ignored - and more than 60% of teams struggle with false positives frequently or very frequently (SANS 2025). When every alert feels urgent, in the end none of them is.

The solution is multi-window multi-burn-rate alerting as described in the Google SRE Workbook. Instead of a single window, several are combined: a short window checks whether the problem is still active right now, a long window confirms that the budget consumption is sustained. Only when both conditions are true at the same time does the alert fire. As a rule of thumb, the short window should be about one twelfth of the long window's duration (Google SRE Workbook). That way the alert fires fast - and also goes quiet again promptly once the disruption is resolved.

These values from the Google SRE Workbook apply to a 99.9 percent SLO and are a proven starting point, not dogma (Google SRE Workbook). The logic behind them: a very high burn rate over a short window (14.4x in one hour consumes 2% of the monthly budget) demands immediate intervention and triggers an escalation. A low burn rate over three days (1x, 10% budget) is not an emergency but a hint - a ticket is enough. This way the team only receives an urgent notification when something genuinely burns. How to configure alerts so that they stay actionable in general is explored in the article on configuring monitoring alerts correctly.

Error-Budget Policy: Turning Numbers Into Decisions

An error budget only unlocks its value once concrete actions are tied to its consumption. Nobl9 puts it plainly: error budgets only work if teams take them seriously (Nobl9). A typical policy couples the budget to release velocity: as long as enough budget remains, the team may deploy freely. Once a critical service's budget is exhausted, new feature releases are frozen until the situation stabilises - energy then flows into stability rather than new functionality.

1. Define the budget - set the SLO (say 99.9%) and calculate the resulting monthly budget (43.8 minutes)
2. Measure the burn rate - continuously capture how fast the budget is consumed instead of only checking the final total
3. Set multi-window alerts - fast pages on a high burn rate, quiet tickets on slow erosion
4. Apply the policy - pause releases when the budget is exhausted and prioritise stabilisation
5. Reset the budget - each new measurement period starts a fresh budget and the cycle begins again

This coupling turns a metric into a genuine steering tool between engineering and product management. It ends the unproductive debate between We need to ship faster and We need to be more stable, because the budget objectively decides which mode is currently appropriate. If an incident does escalate, a clearly defined process helps keep the response time short - the article on incident management and escalation provides the suitable framework.

Measuring Availability From Multiple Locations

An SLO is only as good as the measurement behind it. If availability is checked from a single location, any local network or routing issue distorts the SLI - sometimes the monitoring reports an outage no user experiences, sometimes it misses a regional outage entirely. Measuring from several geographically distributed locations smooths out this distortion and delivers a dependable actual value. Why a single check point is not enough is explained in the article on multi-location monitoring.

XICTRAQ therefore checks availability from three distributed locations and only confirms an outage once several check points report it independently. This reduces false alarms from individual network paths and produces an SLI the team can trust. The gap-free uptime history also provides the data foundation from which error budget and burn rate can be calculated in the first place - without a historical measurement series there is no budget tracking.

Planned maintenance deserves special attention: it should not charge the error budget when it is announced and excluded correctly. If maintenance windows are not cleanly carved out, they generate false alarms and distort the SLI. How to separate such planned periods from real outages is described in the article on maintenance windows and false alerts.

SLO Monitoring in the Context of Compliance and Risk

Availability is no longer only a technical measure but increasingly a regulatory one. For operators of important services, the NIS2 directive requires appropriate availability and incident management including reporting obligations - documented SLO monitoring provides dependable evidence of that. Which obligations specifically apply to website operators is set out in the article on NIS2 reporting obligations for website operators.

The causes of availability losses also belong on the radar. A large share of unplanned outages does not stem from software bugs but from attacks or infrastructure disruptions - such as overload attacks that deliberately render a service unreachable. How to cushion such load spikes is described in the article on protecting against DDoS and DNS amplification attacks. SLO monitoring makes the resulting budget consumption visible and thereby connects the security view with the availability view.

The economic lever is considerable. In enterprise environments, the damage per minute of downtime is estimated at around 5,600 US dollars (Gartner) - a figure that varies strongly by business model but illustrates the order of magnitude. Every avoided burn-rate spike that is caught and stopped early therefore translates directly into the bottom line. Anyone who wants to know their own value will find a suitable calculation basis in the article on the cost of website outages.

Frequently Asked Questions About Error Budget and Burn Rate