Error Budgets Explained

Aug 15, 2026 | by openstatus | [fundamentals]

An error budget is the most useful number in reliability work, and the one most teams define once and then never look at again. It turns "should we ship this risky change on a Friday?" from an argument about temperament into a question with an answer.

This guide assumes you already know how SLIs, SLOs, and SLAs relate. If not, start with SLA vs SLO vs SLI — the error budget only makes sense once those three are distinct in your head.

What an Error Budget Actually Is

Your SLO is a target for reliability. The error budget is its complement: the unreliability you have explicitly permitted.

If your SLO is 99.9% availability measured monthly, you are saying 0.1% of the month is allowed to fail. That is roughly 43 minutes. Those 43 minutes are not a tolerance for carelessness — they are a resource you are expected to spend, on deploys, migrations, experiments, and the incidents that follow from them.

A team that ends every month with a full budget is not winning. It is shipping too slowly.

How to Calculate It

The formula is one line:

Error budget = (100% − SLO) × measurement window

The window matters as much as the percentage. Here is the same set of targets measured over 30 days and over a year:

Two things fall out of that table. First, each additional nine cuts your room to manoeuvre by 10× — 99.99% is not "slightly better than" 99.9%, it is a different operating model requiring redundancy and automated failover. Second, a yearly window is enormously more forgiving than a monthly one. A four-hour outage is a rounding error against a 99.9% annual budget and a catastrophic overrun against the monthly one. Agree on the window before you agree on the number.

You can work the same arithmetic for any target with the SLA calculator.

Burn Rate: the Part That Makes It Operational

A budget you check monthly is a postmortem tool. Burn rate is what makes it a warning system.

Burn rate measures how fast you are consuming the budget relative to the pace that would exactly exhaust it over the window. A burn rate of 1 means you will end the period with precisely nothing left. A burn rate of 2 means you will run out halfway through.

This is what you alert on, because it catches a problem while the budget still has something in it:

The fast burn rates catch outages. The slow ones catch the more insidious failure — a small regression that never trips a threshold but quietly eats the month.

What to Do When It Runs Out

Decide this in advance, in writing, while nobody is stressed. A budget with no policy attached is just a metric.

The conventional policy is a feature freeze: when the budget is exhausted, non-essential deploys stop and engineering effort redirects to reliability until the window resets. Variations that work:

• Graduated response. At 50% consumed, review what spent it. At 75%, require sign-off for risky changes. At 100%, freeze.
• Freeze the risky surface only. Halt deploys to the service that missed its SLO rather than the whole organisation.
• Borrow deliberately. Sometimes a launch is worth overrunning for. That should be an explicit, recorded decision by someone accountable — not something that happens because nobody was watching.

The value is not the freeze. It is that the decision was made when everyone was calm, so the conversation during the incident is about facts rather than about who is most senior in the room.

Common Mistakes

Setting the SLO equal to the SLA. Then the budget is zero and the first bad deploy is a contractual breach. The internal target must be stricter than the public promise — that gap is the budget.

Measuring the budget against a window nobody agreed on. Monthly and yearly windows differ by more than 10× in practice. Pick one and use it everywhere.

Counting only hard downtime. If your SLI is availability but users experience a service that responds in eight seconds, the budget says you are fine while customers churn. Include latency in the SLI — and be precise about which measurement you mean, since latency and response time are not the same number — or accept that the budget only describes part of the experience. See also why uptime percentage alone is misleading.

Treating leftover budget as a scoreboard. An unspent budget is unshipped work.

How openstatus Fits In

An error budget is arithmetic on top of an SLI, so it is only as good as the measurement underneath it. openstatus does not compute the budget for you — it measures the number you compute it from.

Uptime monitoring runs checks from up to 28 regions and keeps the history, which matters for two reasons. Regional failures are invisible to a single-probe check, and a budget calculated from one vantage point will understate what your users actually experienced. And a budget needs a continuous record over the whole window — you cannot reconstruct last month's consumption from a dashboard that only shows the present.

From there the budget is a subtraction: allowed downtime for your target, minus what the history says you actually spent. Publishing the result on a status page is what turns it from an internal number into the evidence behind your SLA.

Frequently asked questions