# Datadog Alert Noise Digest

> Ranks Datadog monitors by action rate, not volume — then proposes specific thresholds with the percentile behind them. Never mutes a monitor.

- 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: alerts, claude-code, datadog, observability, oncall, software-factory, sre
- Requires config (you provide): ANTHROPIC_API_KEY
- Skills: datadog-noise-digest

**To fork:** open https://www.jurniti.com/templates/datadog-alert-noise-digest 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

# 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.