| error rate | time to alert | budget burned (at alert, or after the SLO interval if no alert fires) |
|---|---|---|
| 0.01% | ||
| 0.05% | ||
| 0.10% | ||
| 0.50% | ||
| 1.00% | ||
| 5.00% | ||
| 10.00% | ||
| 50.00% | ||
| 90.00% | ||
| 100.00% |
This is a little simulator to help you build intuition about SLO burn rate alerting. You can learn more about the theory behind burn rate alerting in the SLO Workbook section on Burn Rate.
Change the values in the form and see how the "time to alert" changes for
different observed error rates in the table. For example, if you set the
SLO to 99.95% over a 14d interval, and you
configure the burn alert exhaustion interval to be 6h, you
should find that:
2m 32s.25m.1% will burn down your budget, and after
about 11h you will be less than 6h away from exhausting
your budget, and you'll be alerted.
0.01% is well below your SLO error rate of
0.05% so you'll never be alerted.
This calculator attempts to emulate the way that Honeycomb implements burn alerts. You can read more about Honeycomb Burn Alerts in their docs.
In Honeycomb, you don't configure burn rate and lookback interval independently. You specify an error budget exhaustion interval which defines the sensitivity of the alert, and ¼ of that exhaustion interval is used as the alert lookback interval.
That means that for high burn rates (when you would otherwise burn all of your budget within the alert exhaustion window) an alert will fire once you've consumed 25% of your error budget. Smaller burn rates will alert later, after burning down more of your budget.
Yes! Put 0 (zero) in the exhaustion interval box.
It absolutely is. It makes several simplifying assumptions that are pretty unlikely to be true in real life. It assumes that the rate of SLI events is constant, and it assumes that any introduced error rates are constant. Ironically, it's when these assumptions are violated that burn rate alerting can be most useful.
If you'd like to help extend the calculator to simulate more interesting scenarios such as changing error rates, please contribute on GitHub!
Nick Stenning did. If you found it helpful, please say hi on Twitter!