About this template
400 alerts a month. You act on thirty.
Everyone knows which monitors are noise. Nobody wants to be the person who muted the one that mattered — so the noise stays, and the real pages get skimmed.
Fixing that needs a number, not an opinion.
Noise is action rate, not volume
action_rate = triggers a human acknowledged ÷ total triggers
A monitor that fires 200 times and gets acted on 200 times is the best monitor you have. Volume alone says nothing, and the rules file says so explicitly.
When acknowledgement data isn't available it falls back to auto-resolve rate — the share of alerts that fixed themselves untouched — and tells you which metric it used. An alert that always self-resolves is telling you its threshold is wrong.
Four verdicts
- RETUNE — high volume, low action rate, fast self-resolve. Gets a specific proposed threshold.
- NEEDS OWNER — fires regularly, nobody acks. That's a routing problem, not a threshold one, so it proposes a team — never a mute.
- FLAPPING — resolves and re-triggers inside the evaluation window. Gets a recovery threshold or a longer window.
- HEALTHY — named explicitly. A report that flags everything is as useless as one that flags nothing.
Proposals are specific or they don't ship
"Raise the threshold" isn't a proposal.
"p95 over the last 30 days is 340ms; this fires at 200ms; propose 400ms" is — and every RETUNE comes with the percentile that justifies it.
The monitors it won't touch
Anything tagged or named as paging, SLO, security, data-loss, or billing is out of scope for retuning regardless of its numbers. They're listed in an Out of scope section so nobody assumes they were missed — they were excluded deliberately.
The reason is cost asymmetry: a missed page costs more than a noisy one.
What you supply
DD_API_KEY, DD_APP_KEY (both read-only) and DD_SITE, plus your own Claude
Code login. Export them in your shell — nothing is stored in the template.
No Events API access? Drop a CSV export into ~/ddnoise/exports/ instead and it
says which input it used.
The guard is a file, not a promise
~/ddnoise/policy/NOISE-RULES.md carries NEVER_MUTE, the actionability
formula and the never-touch list. The skill reads it before every run. Muting the
wrong monitor is how outages get missed, so that decision is never the agent's.
Where this stops
It reads monitors and drafts proposals. It does not mute, disable, delete, or edit a monitor, and it does not resolve incidents.
It won't call an alert a false positive — it can't know that from monitor state — and it won't give root cause, because it's reading alert metadata, not traces.
Verified on build: the skill, the working tree, the NEVER_MUTE guard, the
action-rate rule and the never-touch list are present on a fresh fork, and no
Datadog key shape exists in the snapshot. Running it on your own org is yours.