How the error budget is worked out
The error budget is what the SLO leaves over, applied to the window:
error budget = (1 - SLO% / 100) × window
A 99.9% SLO over 30 days leaves 0.1% of 43,200 minutes, which is 43m 12s of full downtime. Over a 28-day window the same target allows 40m 19.2s. If you count requests instead of time, 0.1% of 1,000,000 requests is 1,000 failed requests.
When only some requests fail, a request-based budget counts the damage more closely than a time budget. If 10% of requests fail for an hour, that hour costs 10% of 60 minutes, or 6 minutes, of a time budget.
Burn rate
Burn rate is how fast you are spending the budget compared with the pace that would use it up exactly at the end of the window. A burn rate of 1 spends the whole budget in the whole window. A burn rate of 2 spends it in half the window:
burn rate = share of budget used / share of window gone
For a 99.9% SLO over 30 days, a steady 0.2% error rate is a burn rate of 2 and empties the budget in 15 days. A 1% error rate is a burn rate of 10 and takes 3 days. A full outage is a burn rate of 1,000 and takes 43 minutes.
Burn-rate alerts
The Google SRE workbook suggests alerting on burn rate over two windows at once: a long window to show the problem is real and a short one, a twelfth of its length, to show it is still happening. Its recommended settings for a 30-day SLO are below. The table recalculates for your target and window, and keeps the ticket row at a burn rate of at least 1 so it never fires while you are still inside the SLO.
| Budget spent | Windows | Burn rate | Error rate over | Budget gone in | Action |
|---|---|---|---|---|---|
| 2% | 1h and 5m | 14.4 | 1.44% | 2d 2h | Page |
| 5% | 6h and 30m | 6 | 0.6% | 5d | Page |
| 10% | 3d and 6h | 1 | 0.1% | 30d | Ticket |
The first row pages someone when 2% of a month's budget goes in an hour. At that pace the whole budget lasts about two days. The last row opens a ticket for a slower leak, one that over a 30-day window would only just use up the budget by the end.
Choosing the window
The SRE workbook calls a four-week rolling window a good general-purpose choice. A whole number of weeks always holds the same number of weekends, which a 30-day window does not. A rolling window also keeps counting a big outage on the last day of a month, which a calendar month drops as soon as the next one starts. Contracts usually measure calendar months instead. Google Workspace and Atlassian both measure their SLAs per calendar month, so a 99.9% promise allows 40m 19.2s in a 28-day February and 44m 38.4s in a 31-day month. The uptime calculator converts any target into those periods, and the SLA, SLO and SLI guide covers what the team should do when the budget runs out.
Sources
- Google SRE workbook: Alerting on SLOs (burn rate, multiwindow alerts, tables 5-4 and 5-8)
- Google SRE workbook: Implementing SLOs (four-week rolling window)
- Google SRE book, chapter 3: Embracing Risk (error budgets)
- Google Workspace SLA (calendar month)
- Atlassian Cloud SLA (calendar month, UTC)