Error budget & burn rate calculator

burn rate, at a glance

A burn rate is how fast you spend the budget against the pace that would use it up exactly over the window. Here is what each rate does to a 30-day budget.

A sustained 1x finishes the window with nothing to spare. Anything above it means the budget runs out early.

SLI, SLO, SLA: the three letters

Start here, because the budget is built from them. An SLI is what you measure, like the share of requests that succeed. An SLO is the target you set for that number, say 99.9%. An SLA is the promise you sign with a customer, usually a looser number with money attached if you miss it. You run to the SLO so you never get near the SLA.

what are "the nines"?

You will hear SRE teams talk in "nines". It is shorthand for a reliability target, named by how many nines lead the percentage: 99% is "two nines", 99.9% is "three nines", 99.99% is "four nines". Each extra nine cuts the downtime you allow by about ten times, and usually costs about ten times more engineering to reach. So instead of quoting an exact number, people say "we run three nines" or "are we going for four nines?". The half steps, like 99.5% and 99.95%, fill the big gap between full nines, which is where a lot of real targets sit. Below two nines is rare for anything people pay for. The numbers on this page, 43 minutes a month at three nines and about four at four, are just those nines turned into time.

how do you calculate an error budget?

Your SLO is never 100%, and the gap is the failure you are allowed. Multiply that gap by the length of the window and you get real, spendable time.

So three nines is not "never go down". It is a 43-minute allowance every month, to spend on a bad deploy, a slow dependency or a retry storm. When it reaches zero, the objective is broken.

how much error budget have I used?

Measure the availability you actually delivered, and the downtime you took is the budget you have consumed. What is left is the room you have before the SLO breaks.

burn rate: your speedometer

The total tells you how much; the burn rate tells you how fast. It compares the failure rate you are running at to the one the SLO allows.

A burn rate of 1× spends the whole window exactly. Under 1× banks budget for later; over 1× and you can read the deadline straight off the rate.

This is why alerts watch the rate, not the total. A 14.4× burn spends 2% of a month in a single hour, the classic fast-burn trigger, and it fires while you still have budget left to save.

why not just aim for 100%?

Because almost no one can tell the difference, and the cost is brutal. Past a point your users are capped by their own phone, wifi and ISP, so a jump they never feel can cost ten times the engineering. Google states it plainly: 100% is the wrong reliability target for basically everything. The budget exists so you stop chasing nines nobody notices and spend that effort where it actually moves the needle. The uptime SLA calculator has the full downtime-per-nine table if you want to compare targets.

turn burn rate into alerts

A single threshold either pages too late or cries wolf. The standard fix pairs a long window that confirms the trend with a short window that clears the alert quickly once you have fixed it, and both have to be burning for it to fire. These are the common presets for a 30-day budget.

The fast page catches a sudden outage; the slow ticket catches a quiet leak that would still drain the month. Same budget, two speeds.

the budget is a policy, not just a number

The math is the easy part. The value comes from agreeing in advance what happens when the budget runs out: risky launches pause and the team spends on reliability until the number recovers. While budget is healthy you ship fast and take the risk, because that is what it is for. One rule keeps everyone honest: if you never spend your budget, your SLO is too strict, and you are buying reliability no user asked for. For a fuller walkthrough with the formulas, read error budgets explained.

FAQ