A breach alert tells you the promise is already broken. By the time it fires, the error budget is spent and the only thing left to do is explain it. Acting on burn rate, before breach, is the only point where there is still something to protect.
The arithmetic
A 99.9% SLO over 30 days allows about 43 minutes of full failure. At a burn rate of 14.4 that budget is gone in about two days; at 36, in 20 hours. A slow leak at a burn rate of 2 spends it in 15 days, quietly.
| Burn rate | 30-day budget gone in |
|---|---|
| 2 | 15 days |
| 6 | 5 days |
| 14.4 | about 2 days |
| 36 | 20 hours |
Every tool starts too late
SLO and observability tools measure the burn and alert someone after the threshold. AI SRE tools investigate after the page. Coding agents fix what a person says is broken, after someone notices. Each one is useful, and each one starts after the damage has begun.
What acting early takes
- A signal that is early and quiet: multi-window burn rate, not a breach.
- Evidence fast enough to trust: what changed, where, and when.
- An action a person can approve in one tap, with the expected effect on burn.
- A code fix afterwards, so the same burn does not come back.
That is the loop we built SteadyNines around. The best time to act is while budget is left. It is also the cheapest.
How SteadyNines acts on burn rate