## TL;DR
One message per CVE is a denial-of-service on your own channel. Stop the loop, switch to a single digest message per run (severity-grouped, top findings listed, link to the full report), cap messages per run, and respect rate limits with backoff. Nobody reads message 37 of 400.

```text
the agent's Slack alert loop fired 400 messages before the rate limit killed it - one alert per CVE with no batching
```

## Use this when
- A channel got flooded with per-finding messages.
- The alert loop only stopped because the platform rate-limited it.
- The team muted the channel, which means future real alerts will be missed too.

## Not for this skill when
- One alert went to the wrong channel. That is routing, not batching.
- You need per-finding granularity for automation. Then use a webhook to a system, not chat messages to humans.

## Steps
1. Stop the loop and post a brief apology plus a pointer to the full report in the flooded channel. Verify: the channel is quiet and the team knows where the real report lives.
2. Rewrite the alerter to emit one digest per run: counts by severity, the top 10 findings with CVE IDs, and a link to the full report. Verify: a 400-finding run produces exactly one message.
3. Cap it: hard limit of a small number of messages per run (e.g. 3), with overflow going to the linked report only. Verify: a synthetic 1000-finding run still produces at most 3 messages.
4. Respect rate limits properly: backoff and retry on 429 instead of hammering until the key is throttled. Verify: the retry logic is in the code, not just hoped for.
5. Separate criticals: a genuine critical-severity, KEV-listed CVE may deserve its own immediate message or page; everything else waits for the digest. Verify: the policy names exactly which findings break out of the digest.

## Variant phrasings
### Slack alert spam 400 messages
The short phrasing.
### one alert per CVE
The pattern phrasing.
### alert loop rate limited
The platform-side symptom.

Compatibility: Slack, Teams, PagerDuty, any chat or paging integration; digest-then-detail is universal.

## Why it happens
The loop was written as "for each finding: send alert", which is the natural first implementation and the wrong one for humans. The rate limit became the batching mechanism by accident. Chat is a human attention channel; it needs human-scale message counts.

## Edge cases / pitfalls
- Do not "fix" this by raising rate limits or using a second bot token; the problem is message count, not throughput.
- Threaded replies (one parent, findings as thread children) still notify on every reply in most clients; prefer the single digest.
- If the team muted the channel during the flood, unmuting needs a human nudge; the digest alone will not bring them back.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_rnZfY5_3D_VBn74IU4qh2A