Error Budget Calculator

An error budget turns a service level objective into a number your team can actually spend. Enter the SLO target and the compliance window: this calculator returns the error budget percentage and the exact downtime it allows, in hours, minutes and seconds. Add your request volume and it also gives the request based budget: how many failed requests the SLO tolerates before the budget is gone.

Quick Answer

How an error budget works: SLI, SLO, and the gap between them

An error budget is the amount of unreliability a service is allowed before it breaks its promise to users. If your service level objective is 99.9 percent successful requests over 30 days, the error budget is the remaining 0.1 percent: the failures you can afford without violating the SLO. Google’s SRE teams invented the concept to settle the oldest argument in software: product wants to ship fast, operations wants stability. The budget is the compromise both sides can measure, and the Google SRE Workbook chapter on implementing SLOs walks through how teams set one in practice.

Start with the SLI, not the SLO

Before you pick a percentage, define what you are measuring. The service level indicator (SLI) is the measurement itself, for example the share of requests that return successfully in under 300 milliseconds. A budget built on server CPU or memory tells you nothing about what users felt, and a budget built on a vague “uptime” number hides slow responses that users experience as failure. Write the SLI in one sentence, agree which failures count, and only then set the target. One practical rule from working SRE teams: count server errors against the budget, and think carefully before counting client errors, since a user typing a bad password is not your service failing.

The policy is the point

The budget only works as a policy tool. When the budget is healthy, teams ship features freely. When it runs low, feature launches freeze until reliability recovers. That rule has to be agreed up front, with product and engineering in the same room, or the budget is just a dashboard nobody reads. The freeze does not have to be absolute: reliability work, security fixes, and rollbacks still ship. What stops is risky new features, and that distinction is what makes the policy survivable in a real roadmap argument.

SLO, SLA, and SLI are three different promises

People mix these three up constantly, and the confusion costs real money. The SLI is the measurement. The SLO is your internal target for that measurement, the line you aim to stay above. The SLA is the external contract with customers, usually with service credits or penalties if you breach it. Smart teams set the SLO stricter than the SLA, so they breach their own internal target and react while there is still room before the customer facing promise breaks. And while minutes of downtime make a good headline, downtime also has a price tag: a business downtime calculator turns those same minutes into lost revenue, which is often what finally gets a reliability budget approved.

Worked example: 99.9 percent over 30 days, checked against this exact tool

Take a 99.9 percent SLO measured over 30 days. The budget is 100 percent minus 99.9 percent, which is 0.1 percent. Thirty days hold 2,592,000 seconds, so the allowance is 2,592,000 times 0.001, which is 2,592 seconds, or 43 minutes and 12 seconds of total downtime. In request terms, 10 million requests in the window times 0.001 gives 10,000 failed requests. Enter these values above and the tool returns exactly these numbers: 43m 12s and 10,000 failed requests, plus an average of 0.024 downtime hours per day.

A common beginner error is setting the SLO from ambition instead of measurement. If your service actually runs at 98.7 percent and you promise 99.9 percent, the budget will be exhausted in the first week, the freeze policy will be ignored out of embarrassment, and the team will learn to ignore the budget entirely. Start from the baseline, tighten quarterly as reliability improves, and let the budget earn trust by being achievable.

Why each extra nine costs ten times as much

The Google SRE Workbook publishes the canonical 30-day allowances, and every serious error budget discussion references them: 99 percent allows 7 hours 12 minutes, 99.9 percent allows about 43 minutes, 99.99 percent allows about 4 minutes, and 99.999 percent allows about 26 seconds. The calculator’s second tab shows the exact figures for six targets, and the calculator itself computes the precise number for any SLO and any window. Notice how brutal each extra nine is. Going from 99.9 percent to 99.99 percent does not buy a little more reliability: it cuts your allowed downtime by a factor of ten, from 43 minutes to about 4. That is why SREs push back when a product manager casually asks for five nines without the engineering budget to match.

The bars are drawn to scale, which is exactly the point: at four nines, a single five minute outage already spends the whole monthly budget. At five nines, a 26 second blip is the entire allowance. Before promising a higher target, ask what breaks first: the on call rotation, the deploy pipeline, or the dependency you do not control. If the honest answer is all three, the SLO is a wish, not a plan.

Time based or request based: pick the definition your users feel

A time based budget measures downtime in minutes, which fits services where any outage affects everyone at once: a checkout page that goes down is down for all shoppers. A request based budget measures failed requests against total traffic, which fits high volume APIs where a small error rate still means thousands of failed calls. This calculator covers both: the downtime figure is always computed, and the failed request figure appears when you enter a request volume. Pick the definition that matches how your users experience failure. A video platform with bursty traffic usually wants request based budgets; a corporate VPN with steady usage usually wants time based. Mixing the two definitions in one SLO is a common beginner mistake that makes the budget impossible to reason about.

Two details trip teams up when they switch definitions. First, a rolling window is not a calendar month: on a rolling 30 day window, an incident stops counting exactly 30 days after it happened, so a budget can refill mid month without anyone fixing anything. Second, request based budgets punish bursty traffic in a way time based budgets do not: the same error rate on a traffic spike produces far more failed requests, and therefore far more burned budget, than on a quiet day. State the window type and the counting rule in your SLO document, or two teams will read the same budget number two different ways.

Burn rate and the remaining budget policy

The budget is a monthly allowance, but nobody waits until day 30 to check the balance. Teams watch the burn rate: how fast the budget is being consumed relative to the window. Burning at 1x means you will exactly exhaust the budget by the end of the window. Burning at 14x means the budget dies in about two days, which is the classic page the on call threshold in Google’s alerting guidance, covered in the Google SRE Workbook chapter on alerting on SLOs. Two alert styles come from this. Fast burn alerts fire when a large fraction of the budget disappears in an hour or less: a full outage. Slow burn alerts fire when a small leak persists for days: a bad deploy degrading a few percent of requests. Most outages that surprise teams are slow burns nobody configured an alert for.

Burn rate is also how you read the remaining budget in plain language. Take the worked example: a 99.9 percent SLO over 30 days gives 43 minutes 12 seconds. If one incident already cost 20 minutes, the burned share is 20 divided by 43.2, which is 46.3 percent, leaving 23 minutes 12 seconds. You still meet the SLO, but nearly half the budget is gone with most of the window left, and that is a very different conversation from “we had one outage.” If you want the money side of the same incident, a cost per incident calculator turns that 20 minutes into a figure finance understands.

Budget remaining	What most teams do
Over 50%	Normal development speed, risky changes allowed.
25% to 50%	Extra review rigor, limit risky changes, watch burn rate daily.
10% to 25%	Feature freeze, reliability work only, until the budget refills.
Under 10%	All hands on reliability, no new features, on call reviews every incident.

Treat that table as a starting policy to adapt, not a Google rule: Google publishes the burn rate math and the alerting approach, while the exact freeze thresholds are each team’s own decision. The part that matters is writing your version down before you need it. A policy invented during an outage, under pressure from a launch deadline, is not a policy at all.

What competing calculators miss

Most error budget calculators on the web do one multiplication: SLO times window, done. They skip the request based mode entirely, they never show the standard SLO reference table, and none of them explain burn rate, which is the part teams actually operate on. Several also blur the line between SLO and SLA, presenting an internal target as if it were a customer contract, and none that we checked warn you that a five minute outage already breaches a four nines budget. This page adds all of it: the request based budget, the SRE Workbook table in the second tab, the burn rate framing above, and the SLO versus SLA distinction, so the number you get comes with the knowledge of what to do when it runs low.

One more gap is worth naming honestly. This calculator gives you the total budget for the window; it does not track incidents as they happen, and it does not know your burn rate today. For that you need production telemetry, an SLI query running against your logs or metrics, not a hand calculation after the fact. Use this tool to set the budget and sanity check a target. Use your monitoring to live inside it.

Frequently asked questions

References