SLO and error budget calculator

What an SLO and an error budget are

A service level objective (SLO) is the reliability you promise yourselves, written as a percentage over a window: "99.9% of requests succeed, measured over 30 days". The error budget is what's left over: the 0.1% of requests (or minutes) that are allowed to fail. At 99.9% over 30 days that is 43 minutes and 12 seconds of full downtime, or the same share of failed requests spread across the month.

The budget turns reliability into something a team can spend. While budget remains, you ship features and take reasonable risks. When it's nearly gone, you slow down, fix what keeps failing and make releases safer. That simple rule settles most arguments between "ship faster" and "stop breaking things".

How to choose a target

Start from what users notice and what your history shows, not from a round number. If your service has managed 99.7% over the last quarter, promising 99.99% next month only guarantees a permanently empty budget. Each extra nine costs far more than the last one: 99.9% allows about 43 minutes a month, 99.99% about 4 minutes, and 99.999% about 26 seconds, which is less time than most deploys take to roll back.

• Measure from the user's side: successful requests at the load balancer, or a synthetic check of the critical journey, rather than CPU or pod health.
• Use separate SLOs for different promises, for example availability of the checkout API and latency of search.
• Never set an SLO higher than the services you depend on can deliver together.

Burn rate, and why simple threshold alerts fail

The burn rate is how fast you're spending the budget compared with the pace the SLO allows. A burn rate of 1 means the budget runs out exactly at the end of the window. A burn rate of 14.4 on a 30-day SLO means 2% of the whole month's budget disappears every hour, so you'd be out of budget in about two days.

A plain "error rate above 1% for 5 minutes" alert is either too noisy (it fires for short blips that barely touch the budget) or too slow (a steady 0.5% error rate never fires, yet quietly spends the whole month's budget). Burn-rate alerts fix both by asking a better question: at this pace, how soon will we run out?

Multi-window, multi-burn-rate alerts

The rules this calculator writes follow the approach in the Google SRE Workbook. Each alert checks a long window and a short window together: the long window proves the burn is significant, the short window proves it's still happening, so the alert resolves quickly once you fix the problem.

• Page: 2% of the budget burned in 1 hour (checked against the last 5 minutes too), or 5% in 6 hours (checked against the last 30 minutes).
• Ticket: 10% of the budget burned over 3 days (checked against the last 6 hours). Real, but not worth waking anyone for.

The burn-rate factors change with your window. On a 30-day SLO the fast rule uses 14.4, on a 28-day SLO it uses 13.44; the calculator works this out for you.

Making the budget mean something

An error budget only changes behaviour if it has a policy attached. Agree in advance what happens when it's spent: for example, only fixes and reliability work are released until the budget recovers, and a postmortem is written for any incident that used more than 20% of it. Review the SLO itself every quarter; if users are unhappy while you're meeting it, the target or the measurement is wrong.