SLO Error Budget Burn Analyzer

Formula

BurnRate = CurrentErrorRate / AllowedErrorRate

The Burn Rate tells you how fast you are consuming your error budget relative to the target. A Burn Rate of 1 means you will exactly hit 0 budget at the end of the window. A Burn Rate of 10 means you will run out in 3 days (for a 30-day window).

Worked Examples

Example 1: Safe

Problem:SLO 99.9%, Current Errors 0.05%

Solution:Allowed 0.1%. Burning at 0.5x speed. Safe to ship.

Result:Burn Rate: 0.5x

Example 2: On Fire

Problem:SLO 99.9%, Current Errors 0.5%

Solution:Allowed 0.1%. Burning at 5x speed. Budget empty in 6 days.

Result:Burn Rate: 5.0x

Example 3: Depleted

Problem:Budget < 0

Solution:Code Freeze. Focus on reliability fix.

Result:Status: Freeze

Frequently Asked Questions

What is an Error Budget?

The allowed amount of unreliability. If SLO is 99.9%, your Error Budget is 0.1%. It represents the 'risk' you can spend on innovation.

What happens when budget is gone?

In strict SRE culture (Google model), you stop shipping new features (Code Freeze) and only work on reliability bugs until the budget replenishes.

Why use Burn Rate for alerts?

Alerting on raw error rate is noisy. Alerting on 'Burn Rate' predicts IF you will violate the SLO, reducing false positives for minor blips.

What is a rolling window?

SLOs are usually measured over a rolling 28 or 30 days. As bad days 'roll off' the back of the window, you gain budget back.

SLI vs SLO vs SLA?

SLI: The metric (Latency). SLO: The internal goal ( < 200ms). SLA: The contract with customer ($ penalty if missed).

What is a Multi-Window alert?

An advanced technique checking Short Window burn (1h) and Long Window burn (6h) to detect fast spikes vs slow leaks.

Does this apply to latency?

Yes. An 'error' can be defined as 'Request took > 500ms'. Failed requests consume budget.

Who owns the budget?

The product team and engineering team share it. Product accepts that feature velocity stops if reliability drops.

Background & Theory

Burn Rate Logic

If you have a 30-day window, you want your budget to last 30 days. This is a Burn Rate of 1.

Burn Rate 1: You are consuming budget exactly as planned.
Burn Rate 2: You are consuming 2x fast. You'll run out in 15 days. Alert Ticket.
Burn Rate 10: You'll run out in 3 days. Page the on-call engineer immediately.

The Four Golden Signals

Most SLOs are built on:

Latency: Time it takes.
Traffic: Demand on system.
Errors: Rate of failure.
Saturation: How "full" the system is.

History

The Ops vs Dev Conflict

Historically, Devs wanted to ship code (Change), and Ops wanted stability (No Change). This misalignment caused constant friction and outages.

Google and SRE

Ben Treynor Sloss at Google introduced "Site Reliability Engineering" (SRE) in the early 2000s. The core concept was the Error Budget. It objectively aligned incentives: "You can break things as much as you want, as long as you stay within budget."

The Rise of Observability

Tools like Prometheus, Datadog, and Honeycomb made it possible to track SLIs in real-time. Burn Rate Alerting (Chapter 5 of the SRE Workbook) became the gold standard for on-call notification, replacing "I feel like it's slow" with math.

Common Misconceptions

Myth: "100% uptime is the goal." Reality: 100% is too expensive and prevents innovation. 99.9% is usually better for business.
Myth: "Error budget is just a metric." Reality: It's a policy. If you don't change behavior (stop shipping) when it burns, it's useless.