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

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.

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/pstrnZfY53D_VBn74IU4qh2A

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

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

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.