GuidesSLO burn rate alerts

SLOs explained: error budgets and burn rate alerts

Updated 17 October 2026 · 9 minute read

A service level objective (SLO) is a target for how reliable a service should be, such as "99.9% of requests succeed over 30 days". The 0.1% left over is the error budget. A burn rate alert fires when you are using that budget much faster than the target allows. Done well, it pages you for problems that threaten the objective and stays quiet for short blips that do not.

SLI, SLO, SLA and error budget

The SLA is for customers and lawyers. The SLO is for the team, and it should be stricter than any SLA so that you notice trouble before it costs money.

A worked example

Take a 99.9% availability SLO over 30 days.

• 30 days is 30 × 24 × 60 = 43,200 minutes.
• The error budget is 0.1% of that: 43,200 × 0.001 = 43.2 minutes of total outage.
• If the service handles 10 million requests in those 30 days, the budget is 10,000 failed requests.

Request-based budgets are usually more useful than minutes. A partial failure, where 2% of requests fail for an hour, uses budget in proportion to the failures, not as if the whole service were down.

Choosing SLIs

Good SLIs measure what users feel, close to the user. Most services start with two.

• Availability — good requests divided by valid requests. Decide what counts as bad: 5xx responses and timeouts usually do; 4xx responses caused by the client usually do not.
• Latency — the share of requests faster than a threshold, for example "99% of checkout requests complete in under 500 ms". Express it as a ratio of fast requests, not as an average, so it fits the same budget maths.

Some practical rules:

• Measure at the load balancer or service edge, where users are served.
• Keep the number of SLOs small. Three to five per user-facing service is plenty.
• Exclude health checks and internal traffic, or they will dilute the ratio.
• Pick a target you can meet today. A 99.99% objective on a service that runs at 99.8% only produces alerts nobody can act on.

If your services send OpenTelemetry traces, request counts, errors and latency per service are already there to build SLIs from. See APM and tracing.

Why threshold alerts cause fatigue

The classic approach is a threshold: "page if the error rate is above 1% for 5 minutes". It has two problems.

• It pages on blips. A 6-minute spike to 1.5% errors uses about 0.2% of a 99.9% monthly budget. That is not worth waking someone for, yet the rule fires.
• It misses slow leaks. An error rate of 0.5% never crosses the threshold, but it spends the whole monthly budget in 6 days.

Burn rate alerts fix both problems by asking a better question: at the current rate, how much of the budget are we using?

What burn rate means

Burn rate is how fast you spend the error budget, relative to the rate that would use it up exactly at the end of the window.

burn rate = observed error rate / (1 - SLO target)

For a 99.9% SLO the allowed error rate is 0.1%.

• An error rate of 0.1% is a burn rate of 1: the budget lasts exactly 30 days.
• An error rate of 1% is a burn rate of 10: the budget is gone in 3 days.
• An error rate of 1.44% is a burn rate of 14.4: the budget is gone in 50 hours.

The share of the budget spent in a period is: burn rate × period length / SLO window. At 14.4× for one hour: 14.4 × 1 / 720 hours = 2% of the monthly budget.

Multi-window, multi-burn-rate alerts

A common practice is to combine several burn rates, each checked over a long and a short window. The values below are for a 30-day 99.9% SLO.

How it works:

• Both windows must be over the burn rate for the alert to fire. The long window proves the problem is significant. The short window proves it is still happening.
• The short window makes alerts reset quickly. Without it, a 1-hour window keeps firing for up to an hour after you have fixed the cause. With a 5-minute short window, the alert clears within minutes.
• Fast burns page; slow burns create tickets. A 14.4× burn needs someone now. A 1× burn needs attention this week, not at 3 a.m.

A typical paging rule, in pseudo-code:

page if
  error_ratio(1h) > 14.4 * 0.001  and  error_ratio(5m) > 14.4 * 0.001
or
  error_ratio(6h) > 6 * 0.001     and  error_ratio(30m) > 6 * 0.001

Two cautions. Low-traffic services make ratios jumpy: one failure in 20 requests is 5% errors. Add a minimum request count, or use longer windows. And if you change the SLO target or window, recalculate the thresholds; they are not universal constants.

When the budget is spent

An error budget is only useful if the team agrees in advance what happens when it runs out. Write a short error budget policy. Common elements:

1. Slow down risky change. Pause feature releases to the affected service, except fixes and security patches, until the budget recovers.
2. Spend engineering time on reliability. Work through the causes found in incident reviews: missing retries, capacity limits, fragile dependencies.
3. Review the incidents that used the most budget, without blame, and track the follow-up actions.
4. Check the SLO itself. If you miss it every month and users do not complain, the target may be too strict. If users complain while you meet it, the SLI may be measuring the wrong thing.

The reverse also holds. If you have plenty of budget left, you can afford to ship faster, run experiments and do risky maintenance.

SLOs in Televane

Televane supports SLOs with multi-window burn-rate alerts, so you can page on the error budget rather than on every blip. Here is how the parts fit together.

• Indicators from your services. Send traces over OpenTelemetry and Televane shows throughput, error rate and p95 latency for every service, with error rate, p95, p99 and request-rate alert rules per service or operation.
• Routing and on-call. Notifications go to email, Slack, Microsoft Teams, PagerDuty or signed webhooks. On-call rotations and escalation policies decide who gets paged, and escalation stops when someone acknowledges.
• Less noise around the page. Related alerts are grouped into one incident with its timeline, a noise report shows flapping rules, and silences cover maintenance windows.
• SLOs as code. SLOs, alert rules and dashboards are declarative resources you can apply with obsctl and keep in GitHub, GitLab or Bitbucket, so changes to targets are reviewed like any other change.

Read more on the alerts and incidents page and in Televane for DevOps and SRE teams. Plans and limits are on the pricing page, and you can start free with a 14-day Pro trial and no card.

Frequently asked questions