Enter the SLO target, one window of total and bad events and its length in days. The panel shows the budget already used, the burn rate and how long the remaining budget lasts at that rate.
Runs locally in your browserA burn rate of 1× spends the full error budget over one SLO period; this calculator does not fetch monitoring data.
Four numbers go in: the SLO target as a percentage, the total events in the observation window, how many of them were bad, and the length of that window in days. The panel answers the two questions an error budget raises — how much of the budget the observed failures use, and how much longer it lasts at that rate — and it does the arithmetic in the tab, without contacting a monitoring system.
Enter both counts from one window. The tool compares them with the permitted error rate and knows nothing about how your monitoring classifies an event, so a bad-event count that includes timeouts your SLO excludes moves the budget by exactly that much.
The permitted error rate is 100 − target: a 99.9% SLO allows 0.1% of events to fail. Multiplied by the event total that gives the figure printed as allowed bad events — 1,000 for one million events at 99.9%. Budget used is the observed failures divided by that allowance, so 2,500 failures against an allowance of 1,000 read 250% and leave nothing, while 500 failures read 50% and leave half. Availability is the plain failure ratio, 1 − bad ÷ total: 99.75% in the first case and 99.95% in the second.
Remaining budget floors at 0%: once the allowance is gone, further failures do not push the number negative, the bar turns red instead, and the panel says so. Failures equal to the allowance count as fully used rather than exceeded — that boundary is decided with a tolerance, because the allowance is a product of two typed numbers and an exact input can land a fraction of an ulp above it.
The burn rate divides the observed error rate by the permitted one. 1× means the budget is being spent at exactly the rate the SLO allows and lasts one full period; 2.50× means two and a half times faster; below 1× it outlives the period.
Projected exhaustion is the time left at the current rate, not the time a fresh budget would last: the period multiplied by the share of the budget still unused, divided by the burn rate. At 0.50× with half the budget unspent, a 30-day window leaves about 30 more days. A budget that is used up reads “budget already spent”, and a window with no bad events reads “not at this rate”. The period field is used for this projection only: it does not scale the counts.
It never calls a monitoring system, a metrics API or DNS. The four values are the only input, everything is computed in the browser, and the page keeps working offline.
It also stops there: no multi-window burn-rate alerting (the 1 h / 6 h / 3 d pairs), no per-service or per-user weighting, no time-based SLI where availability is counted in minutes instead of events, no alert routing. Those live in your monitoring platform. This page is the arithmetic check that tells you whether a window of numbers is still inside the budget or already past it.