Interactive tool
What an availability target actually allows
“Three nines” is abstract; 43 minutes a month is not. This converts a target into a budget, then shows the burn rate — because spending half your budget in a tenth of the window is a very different situation from spending it evenly.
Runs in your browser · nothing is sent anywhere
Target
43,200 minutes total
Needed for burn rate — spending half the budget in a tenth of the window is very different from spending it evenly.
✓ within budget
- Total budget
- 43 minutes
- Remaining
- 25 minutes
- Burn rate
- 0.83×
Within budget at 0.83× the sustainable rate. Spending budget is not failure — an unspent budget usually means you are shipping too cautiously.
An error budget converts “how reliable should we be” into “how much unavailability may we spend”, which is a decision engineers and product owners can share. A budget that is never spent usually means you are shipping too cautiously, not that things are going well.
What an error budget is
If you promise a service will be available 99.9% of the time, you have also said that 0.1% of the time it will not be. Over 30 days that is about 43 minutes. That allowance is the error budget.
It exists to make a target actionable. “Be reliable” cannot be planned against or argued with; “we have 43 minutes a month and we have used 18” can be both.
Using it
Set the target and the window, then enter how much downtime you have already had and how far through the window you are. The result is what is left and how fast you are spending it.
The burn rate is the number to watch. It compares spend against elapsed time, so it answers “will this hold” rather than “how much is left”. A rate of 1 runs out exactly as the window ends; 2 runs out halfway.
What this checks
- How much downtime or how many failed requests an SLO target allows over a window, and how fast a burn rate spends it.
What it cannot know
- Measure your service. The budget is only as good as the SLI you feed it.
- Decide what counts as a failure; that is a product decision.
Check it for real
sum(rate(http_requests_total{code!~"5.."}[30d])) / sum(rate(http_requests_total[30d]))A PromQL availability SLI over 30 days, assuming Prometheus-style request metrics with a code label. Your metric and label names may differ. Google SRE book: Service Level Objectives
Choosing a window, and what the number is for
A calendar window resets on a date, so a bad month is wiped by the first of the next one. A rolling window always looks back the same number of days, so a bad day keeps counting until it ages out. Rolling is harder to game and harder to explain. The same incident produces different numbers under each, so say which you use.
Each additional nine is roughly ten times less allowed downtime: over 30 days, 99% is about 7 hours, 99.9% about 43 minutes, 99.99% about 4.3 minutes. Four minutes a month is less than one careless deploy, so a target like that is a statement about your release process and your paging load as much as your architecture.
The budget is most useful as a decision rule agreed in advance — while it holds, ship; when it is gone, the next work is reliability work. Used only as a report it measures the same thing and changes nothing. On-call load is the other half of that argument.
Terms used here (3)plain definitions
Short definitions for the vocabulary on this page, in case any of it is new. Each links to the full entry.
- DevOps
- A way of building and running software in which the people who write it and the people who operate it share responsibility for how it behaves in production, and automate the path between the two. In practice that means small changes merged often (continuous integration), an automated route to production (continuous delivery), infrastructure described in code, and monitoring that tells the team quickly when something breaks. It is a set of practices and a way of working rather than a single tool. DORA's research measures it with four numbers: how often a team deploys, how long a change takes to reach production, how often a deployment fails, and how quickly the team recovers when one does.
- Prometheus
- An open-source monitoring and alerting toolkit that collects and stores time-series metrics data. Prometheus uses a pull model to scrape metrics from instrumented targets and provides a powerful query language (PromQL) for analysis and alerting.
- SLA/SLO/SLI
- Service Level Agreement, Objective, and Indicator — a hierarchy of reliability metrics. SLIs measure specific aspects of service performance, SLOs set target values for those indicators, and SLAs are contractual commitments with consequences for violations.
Questions people ask about this
What is an error budget?
It is the amount of unreliability your availability target allows. If you promise 99.9% over 30 days, you are also saying that about 43 minutes of failure in those 30 days is acceptable — that is the budget.
The point is that it makes the target actionable. “Be reliable” cannot be planned against; “we have 43 minutes and have used 18” can.
What does burn rate mean?
How fast you are spending the budget relative to how much of the window has passed. A burn rate of 1 spends the budget exactly as the window ends. A burn rate of 2 exhausts it at the halfway point. It is more useful than the raw remaining figure because it answers “will this hold” rather than “how much is left”.
Should we aim for more nines?
Each nine is roughly ten times less allowed downtime. Over 30 days: 99% is about 7 hours, 99.9% about 43 minutes, 99.99% about 4.3 minutes.
4.3 minutes a month is less than one careless deploy, so a target like that is a statement about your release process and your paging load as much as your architecture. The question worth asking is whether users notice the difference, not whether the number looks better.
Rolling window or calendar month?
A calendar window resets on a date, so a bad month is wiped clean by the first of the next one. A rolling window always looks back the same number of days, so a bad day keeps counting against you until it ages out. Rolling is harder to game and harder to explain; calendar is the reverse. Pick one and say which, because the same incident produces different numbers under each.
Did this get you to an answer?
No text box on purpose — please do not paste production logs anywhere
Something wrong or out of date? Report it
Tools that go with this
- Availability CalculatorWhole-system availability from parts in series and redundant groups, with the working shown.
- On-Call Load AssessmentYour paging numbers against published thresholds — Google SRE's 2 per shift, the 30–50% actionable band, DORA recovery tiers.
- Retry and Backoff CalculatorThe total time a retry schedule consumes, which is the number every timeout above it has to clear.