Spam Detection

• Stops burst-posters flooding a channel with many short messages in seconds.
• Catches simple flood raids where a single account spams nonsense to push real conversation off-screen.
• Limits compromised accounts before they can drop a full payload.
• Works without a word list — the abuse pattern is volume, not content.

One user sending more than max_messages messages in the last window_seconds. The count is taken at the guild level — messages across different channels in the same server all feed the same buffer. With the defaults (max_messages = 5, window_seconds = 5), the 6th message inside a 5-second window is the one that trips the rule.

• Cross-guild spam — buffers are keyed per (guild_id, user_id), so a user spamming in two different servers has two independent counters.
• Distributed spam from multiple accounts — each account has its own buffer. A coordinated raid with one message per account looks normal to this trigger.
• Bot and webhook messages — they are skipped before reaching the evaluator.
• Spam that survives a bot restart — the buffer is in-memory only and resets on process start.
• Message content — this trigger does not care what was posted, only how fast.

A safe baseline for most community chat servers:

{
  "max_messages": 5,
  "window_seconds": 5
}

Pair with the Mute action and a 5-minute duration, and set per_user_cooldown_seconds to 60 on the rule to avoid chain-muting the same user on every subsequent burst inside the cooldown.

• Quick back-and-forth banter — an active user can easily hit 5 messages in 5 seconds during a heated discussion.
• Lists posted one message at a time instead of in a single block.
• Bot-command spam where the user issues several commands in a row and the bot replies in between.
• Typo corrections: the user posts, sees the mistake, posts again, then a third correction.

• Current behavior: the threshold uses a strict greater-than comparison. Setting max_messages = 5 means the 6th message in the window fires; five does not.
• Current behavior: the spam buffer is shared across every spam_detection rule in a guild. One deque per (guild_id, user_id) pair backs all such rules. If two spam_detection rules exist with different window sizes, the first one to execute sets the deque's maximum length, and all rules read from the same list of timestamps afterwards.
• Current behavior: the rule cache has a 60-second TTL. Configuration changes saved in the dashboard can take up to a minute to propagate to the bot.
• Current behavior: counting is timing-based, not content-based. A user posting several short on-topic replies in quick succession will trip the rule exactly the same way a flood raider would.
• Current behavior: the spam buffer is in-memory only. A bot restart clears the counters — fresh windows start from zero after a deploy.
• Current behavior: allowlist words do not apply. Spam Detection is volumetric, so the rule's allowlist_words list is ignored for the count. A spammer cannot neutralise the rule by sprinkling allowlisted fragments into their bursts.
• Current behavior: exempt users do not contribute to the buffer at all. Their messages are skipped before the timestamp is recorded, so they cannot accidentally drag a non-exempt user closer to the threshold either.

The most common pairing is Mute (Discord timeout) in the 5–10 minute range — short enough to be proportionate to a single burst, long enough to stop the flood. Combine with per_user_cooldown_seconds on the rule so the same user does not get re-muted for every additional burst inside the cooldown window.

• Mention Spam — per-message mention cap. Layer both to catch burst-posters who also ping-bomb.
• Caps Spam — single-message shouting pattern. Pairs well with Spam Detection for loud, fast posters.
• Duplicate Message — catches the same message reposted repeatedly, which Spam Detection alone can miss when the bursts are paced.
• Emoji Spam — another volumetric trigger, counted per-message rather than across a time window.