How to use it
- Choose Downtime for a time-based SLO or Requests for a request-based one.
- Enter the SLO target, the window (often 28 or 30 days) and how many days of it have passed.
- Enter the bad minutes, or the requests and failed requests so far.
- Read the budget, the share used, the burn rate and the days left at the current pace.
Formulas
- Allowed bad share e = 1 − SLO
- Time budget = e × window days × 1440 minutes
- Request budget = e × requests so far × window ÷ days elapsed
- Budget used = bad so far ÷ budget
- Burn rate = observed bad share ÷ e (bad minutes ÷ elapsed minutes, or failed ÷ total requests)
- Days left = budget left ÷ (bad so far ÷ days elapsed)
Worked example
A 99.9 % SLO over 30 days, 10 days in, with 20 minutes of downtime:
- budget: 0.001 × 30 × 1440 = 43.2 min;
- used: 20 ÷ 43.2 = 46.3 %, so 23.2 min are left;
- the bad share so far is 20 ÷ 14,400 = 0.139 %, so the burn rate is 0.139 ÷ 0.1 = 1.389;
- at 2 bad minutes a day, the remaining 23.2 minutes last 11.6 days — two days before the window ends;
- reliability so far: 99.8611 %.
Tips
- Alert on burn rate, not on raw errors. A short spike at a high burn rate and a slow leak at a burn rate just above 1 both threaten the SLO; burn-rate alerts over a short and a long window catch both.
- Pick the window people plan around. A 28-day window always holds four of each weekday, which keeps weekly traffic cycles even.
- To turn an availability percentage into allowed downtime per day, week or year, use the uptime SLA calculator.