About this template
"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.