# SLO Error Budget Report

> Reports burn rate over short and long windows with a projected exhaustion date — and flags the green SLOs too loose to constrain anything. Never moves a target.

- Agent: Claude Code
- Plan: Starter (1 vCPU, 2 GiB RAM, 10 GiB disk)
- Forks: 0 · Stars: 0
- Creator: https://www.jurniti.com/creator-ca0ff2
- Tags: claude-code, datadog, observability, reliability, slo, software-factory, sre
- Requires config (you provide): ANTHROPIC_API_KEY
- Skills: slo-error-budget

**To fork:** open https://www.jurniti.com/templates/slo-error-budget-report and use the Fork action — it starts a Stripe Checkout for a new VM seeded with this template's persist disk (same flat plan price, no fork fee).

## README

# "62% of budget remaining" told you nothing

The reliability review opened a dashboard of green SLOs. Everyone nodded. Three days
later checkout breached — it had been burning at 4× since Tuesday, and the percentage
never said so.

## Burn rate, not budget remaining

```
burn rate = budget consumed in window ÷ window as a fraction of the SLO period
```

A burn rate of 1 means you'll exactly exhaust the budget by period end. Above 1 you
breach early.

Reported over **both** a 1-hour and a 24-hour window, with the windows named —
short-only is noisy, long-only is slow, and either alone misleads.

And where burn exceeds 1, you get the sentence that actually changes behaviour:

> **Checkout availability is burning 3.4× and the budget is gone on the 14th.**

The date moves people. The percentage doesn't.

## Unspent budget is also a finding

An SLO that ends every period at 99% remaining isn't a triumph. Either the target is
too loose to constrain anything, or the SLI doesn't measure what users feel.

Those come back as **UNINFORMATIVE**, because a dashboard of permanently green SLOs is
decoration — and most reviews never surface them.

## An SLO on CPU is not an SLO

Availability, latency, correctness and freshness are *symptoms*. CPU, memory and queue
depth are *causes*. SLIs measuring causes get flagged as not being SLOs at all — named,
not rewritten. Rewriting someone's SLI is a conversation, not an edit.

## It will not move a target

Loosening a target so a red SLO goes green is the most damaging thing anyone can do to
a reliability practice. It must be a deliberate human act, so the agent refuses — no
editing SLOs, no resetting budgets, no silencing.

## What you supply

`DD_API_KEY`, `DD_APP_KEY` (both read-only) and `DD_SITE`, plus your own Claude Code
login. Or export a CSV into `~/slo/exports/` — it says which input it used.

## Where this stops

It reports. It does not edit an SLO, change a target, reset a budget, or silence
anything.

It won't tell you *why* a budget is burning — it sees the SLI, not traces. It won't
call a target correct, because what users tolerate is a product conversation. And
where no SLO exists it reports the gap rather than estimating a reliability number.

Verified on build: the skill, the working tree, the `NEVER_CHANGE_TARGETS` guard, the
burn-rate rule, the uninformative-SLO finding and the user-facing-SLI rule are present
on a fresh fork, with no Datadog key shape in the snapshot. Running it on your own org
is yours to do.