Something went wrong. Try again.
[READ-ONLY] Mirror of https://github.com/openstatusHQ/openstatus. 🫖 Status page with uptime monitoring & API monitoring as code 🫖 openstatus.dev
bun drizzle-orm monitoring monitoring-as-code nextjs observability on-call open-source shadcn-ui status-page statuspage synthetic-monitoring tinybird turso uptime uptime-checker uptime-monitor
Something went wrong. Try again.
123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182---title: "Error Budgets Explained"seo: title: "Error Budget: How to Calculate and Use One"description: "How to calculate an error budget from your SLO, what burn rate means, and what to actually do when the budget runs out. With a per-SLO downtime table."author: "openstatus"publishedAt: "2026-08-15"category: "fundamentals"faq: - question: "What is an error budget?" answer: "An error budget is the amount of unreliability you are allowed before you break your own target. If your SLO is 99.9% availability over a month, you are permitting 0.1% of that month to fail - about 43 minutes. That 43 minutes is the budget. It is not a forecast or a tolerance for sloppiness; it is a quantity you are expected to spend." - question: "How do you calculate an error budget?" answer: "Error budget = (100% − SLO) × the measurement window. For a 99.9% monthly SLO, that is 0.1% of 30 days, or roughly 43 minutes. For a 99.99% monthly SLO it is about 4 minutes 19 seconds. Calculate it against the window your agreement actually uses - a yearly window is ten times more forgiving than a monthly one for the same percentage." - question: "What is error budget burn rate?" answer: "Burn rate is 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 finish the period with exactly zero budget left. A burn rate of 14.4 means you are spending 2% of a 30-day budget every hour, and the entire month's allowance disappears in about two days." - question: "What happens when the error budget is spent?" answer: "That is a policy decision you should make before it happens, not during the incident. The common policy is to freeze feature deploys and redirect engineering to reliability work until the budget recovers at the start of the next window. The point is that the budget converts an argument about whether to slow down into a number that already decided it." - question: "What is the difference between an error budget and an SLA?" answer: "An SLA is the promise you make to customers, with financial consequences. The error budget is the operating room between that promise and the stricter internal target you hold yourself to. The SLA says what happens if you fail; the error budget tells you how close you are to failing, while there is still time to act."---
An error budget is the most useful number in reliability work, and the one most teamsdefine once and then never look at again. It turns "should we ship this risky changeon 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, startwith [SLA vs SLO vs SLI](/guides/sla-vs-slo-vs-sli) — the error budget only makessense 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: theunreliability you have explicitly permitted.
If your SLO is 99.9% availability measured monthly, you are saying 0.1% of the monthis allowed to fail. That is roughly 43 minutes. Those 43 minutes are not a tolerancefor 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 tooslowly.
## 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 targetsmeasured over 30 days and over a year:
| SLO | Budget per 30-day month | Budget per year || --- | --- | --- || 99% | 7h 12m | 3d 15h 36m || 99.5% | 3h 36m | 1d 19h 48m || 99.9% | 43m 12s | 8h 45m 36s || 99.95% | 21m 36s | 4h 22m 48s || 99.99% | 4m 19s | 52m 34s || 99.999% | 26s | 5m 15s |
Two things fall out of that table. First, each additional nine cuts your room tomanoeuvre by 10× — 99.99% is not "slightly better than" 99.9%, it is a differentoperating model requiring redundancy and automated failover. Second, a yearly windowis enormously more forgiving than a monthly one. A four-hour outage is a roundingerror against a 99.9% annual budget and a catastrophic overrun against the monthlyone. Agree on the window before you agree on the number.
You can work the same arithmetic for any target with the [SLA calculator](/play/uptime-sla).
## Burn Rate: the Part That Makes It Operational
A budget you check monthly is a postmortem tool. Burn rate is what makes it awarning system.
Burn rate measures how fast you are consuming the budget relative to the pace thatwould exactly exhaust it over the window. A burn rate of 1 means you will end theperiod with precisely nothing left. A burn rate of 2 means you will run out halfwaythrough.
This is what you alert on, because it catches a problem while the budget still hassomething in it:
| Burn rate | Budget consumed | Over | Meaning || --- | --- | --- | --- || 14.4× | 2% | 1 hour | The month's budget is gone in ~2 days. Wake someone up. || 6× | 5% | 6 hours | Serious, sustained degradation. Page during working hours. || 1× | 10% | 3 days | Slow bleed. File a ticket, not an alert. |
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 nopolicy 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 thewindow 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 wascalm, so the conversation during the incident is about facts rather than about whois most senior in the room.
## Common Mistakes
**Setting the SLO equal to the SLA.** Then the budget is zero and the first baddeploy is a contractual breach. The internal target must be stricter than the publicpromise — that gap *is* the budget.
**Measuring the budget against a window nobody agreed on.** Monthly and yearlywindows 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 aservice that responds in eight seconds, the budget says you are fine while customerschurn. Include latency in the SLI — and be precise about which measurement you mean,since [latency and response time](/docs/concept/latency-vs-response-time) are notthe same number — or accept that the budget only describes part of the experience.See also [why uptime percentage alone is misleading](/guides/why-uptime-percentage-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 themeasurement underneath it. openstatus does not compute the budget for you — itmeasures the number you compute it from.
[Uptime monitoring](/uptime-monitoring) runs checks from up to 28 regions and keepsthe history, which matters for two reasons. Regional failures are invisible to asingle-probe check, and a budget calculated from one vantage point will understatewhat your users actually experienced. And a budget needs a continuous record overthe whole window — you cannot reconstruct last month's consumption from a dashboardthat only shows the present.
From there the budget is a subtraction: allowed downtime for your target, minus whatthe history says you actually spent. Publishing the result on a[status page](/status-page) is what turns it from an internal number into theevidence behind your SLA.
## Frequently asked questions
<Details summary="What is an error budget?">
An error budget is the amount of unreliability you are allowed before you break your own target. If your SLO is 99.9% availability over a month, you are permitting 0.1% of that month to fail — about 43 minutes. That 43 minutes is the budget. It is not a forecast or a tolerance for sloppiness; it is a quantity you are expected to spend.
</Details>
<Details summary="How do you calculate an error budget?">
Error budget = (100% − SLO) × the measurement window. For a 99.9% monthly SLO, that is 0.1% of 30 days, or roughly 43 minutes. For a 99.99% monthly SLO it is about 4 minutes 19 seconds. Calculate it against the window your agreement actually uses — a yearly window is ten times more forgiving than a monthly one for the same percentage.
</Details>
<Details summary="What is error budget burn rate?">
Burn rate is 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 finish the period with exactly zero budget left. A burn rate of 14.4 means you are spending 2% of a 30-day budget every hour, and the entire month's allowance disappears in about two days.
</Details>
<Details summary="What happens when the error budget is spent?">
That is a policy decision you should make before it happens, not during the incident. The common policy is to freeze feature deploys and redirect engineering to reliability work until the budget recovers at the start of the next window. The point is that the budget converts an argument about whether to slow down into a number that already decided it.
</Details>
<Details summary="What is the difference between an error budget and an SLA?">
An SLA is the promise you make to customers, with financial consequences. The error budget is the operating room between that promise and the stricter internal target you hold yourself to. The SLA says what happens if you fail; the error budget tells you how close you are to failing, while there is still time to act.
</Details>