burnrateshipped

Symptom

Running `burnrate demo` for a few minutes, the fast-burn window occasionally flips from OK to CRITICAL for a handful of ticks — this is DemoSource's simulated incident, injected roughly every few hours of simulated time to prove the alerting logic actually reacts to something.

Diagnosis

1. 01DemoSource rolls a low-probability chance each simulated minute to start a short incident window (a few minutes of elevated error rate) rather than a fixed schedule, so it feels like something that could actually happen rather than a scripted demo.
2. 02Once the incident window starts, the per-minute error rate jumps by roughly 50–100x its baseline — well past the fast window's threshold of 14.4x for a 99.9% SLO.
3. 03The slow-burn window barely moves during a short incident, because it averages over 6 hours — which is exactly the point: a brief spike alone shouldn't have escalated as a slow-burn issue.

Response

1. 01The dashboard's fast-burn row flips to a red CRITICAL badge the tick after the sample lands, since Model.Update re-evaluates both windows every second in live mode.
2. 02The error-budget gauge (`slo.Tracker`) ticks down proportionally to the errors consumed during the spike, so the 30-day budget reflects the incident even after the fast window recovers.
3. 03Once the simulated incident ends, the next few minutes of samples dilute the 5-minute window back toward baseline and the badge returns to OK — visibly demonstrating why the short window needs to stay short.

Blast radius

Contained entirely to the demo's simulated traffic — nothing in this tool talks to real infrastructure. In a real deployment, the same two-window pattern with a Prometheus-backed source would bound the blast radius to whatever it takes a human to notice the CRITICAL badge and start the actual incident response.

Lessons learned

This is exactly why the fast and slow windows are evaluated independently rather than averaged together — averaging a 5-minute spike into a 6-hour window would have hidden it almost completely, which defeats the entire purpose of multi-window burn-rate alerting.

Burn-rate math lives in its own dependency-free package

internal/slo has zero imports from Bubble Tea or Lip Gloss. It's pure arithmetic over Go structs, which means it's trivially unit tested and could be reused by a completely different frontend (a web API, a Slack bot) without touching the terminal code at all.

A demo mode is a first-class feature, not an afterthought

SLO tooling usually requires a real metrics backend before anyone can even see what it does. burnrate's DemoSource simulates believable traffic (with an occasional incident) so the tool is immediately useful — and immediately understandable — with zero setup.

Two windows, not one

A single error-rate reading can't tell a brief blip from a genuine regression. Pairing a short, sensitive window with a longer, noise-resistant window is the well-established fix for that — a hard outage trips the fast window in minutes, while a slow leak still eventually trips the slow window instead of hiding inside noise.

Static snapshots and live demo data share one interface

Both `DemoSource` and `FileSource` implement the same small `Source` interface (`Tick`, `Window`, `Label`, `ServiceName`). The dashboard code has no idea — and doesn't need to know — whether it's looking at simulated or real data.

Phase 1 — Coredone

• —Multi-window burn-rate evaluation (`internal/slo`, unit tested)
• —Rolling error-budget tracker with a live gauge
• —Self-contained `demo` mode with simulated traffic
• —`run --file` snapshot mode for real exported metrics

Phase 2 — Real backendsplanned

• —A Prometheus-backed `data.Source` for live production metrics
• —Configurable window/threshold pairs instead of the built-in defaults
• —Multiple services in one dashboard view

Phase 3 — Distributionplanned

• —Homebrew tap for one-command install
• —Prebuilt release binaries for common platforms