Enter your SLO and what has gone wrong so far. See the total error budget for the window, how much of it is spent and how long the rest will last at the current pace.
Runs entirely in your browser — nothing you enter here is sent to a server.
An error budget is the unreliability your SLO permits. If the target is 99.9%, the remaining 0.1% is not a failure to hide — it is an allowance you can spend on deploys, migrations, experiments and the occasional bad day. As long as some budget is left, the service is meeting its objective.
The value of the idea is that it turns an argument into arithmetic. Product wants to ship faster, operations wants stability; the budget says how much risk is currently affordable. Plenty left: ship. Nearly gone: slow down and fix what is burning it.
Count good and bad events: budget = total requests × (1 − SLO). Best for APIs and anything with steady traffic, because a short outage at peak hurts more than one at night.
Count bad minutes: budget = window × (1 − SLO). Simpler to measure with uptime checks and easier to explain to customers.
How fast you are spending compared with an even pace. 1× uses the whole budget exactly by the end of the window; 2× uses it in half the time.
Most teams use a rolling 28 or 30 days, so one bad incident does not disappear at midnight on the first of the month.
Agree the policy before you need it. A common one: above 50% remaining, release normally; below 25%, require an extra review for risky changes; at zero, stop feature releases until the service has earned some budget back. Whatever the thresholds, write them down while nobody is under pressure.
Subtract the SLO from 100% and apply the result to the window. For a 99.9% SLO over 30 days that is 0.1% of 43,200 minutes, or 43.2 minutes — or 0.1% of all requests served in those 30 days.
Anything at or below 1× means you will finish the window inside the budget. Short spikes above 1× are normal; a sustained rate above 1× means the SLO will be missed unless something changes.
Use request-based when you have reliable success and failure counts, because it weights incidents by how many users they affected. Use time-based when availability is measured by periodic checks.
Technically the SLO is missed for that window. In practice it triggers whatever policy your team agreed: usually a pause on risky launches and priority for reliability fixes until the budget recovers.
Upzilla records every failed check so the budget figure is real, not a guess. 10 monitors free, no card required.