Batching
Some things only make sense in bulk. Thirty messages in a minute is a raid; one message is a Tuesday.
Turn batching on and the rule stops firing per event. Instead it collects them and runs once, with the whole burst summarised.
The three settings
| Setting | Meaning |
|---|---|
| Quiet window | flush once no new event has arrived for this long |
| Max wait | never wait longer than this after the first event |
| Only fire at | a threshold, below it, nothing happens at all |
Set the quiet window and the max wait to the same value and you get a fixed window: exactly "N events within X seconds".
Only fire at is a real threshold, not just an early flush. A window that closes below it fires nothing, which is what lets a rate gate exist without a defensive condition on every step.
You also choose the scope: one batch for the whole server, one per channel, or one per member.
What the rule receives
The workflow runs on the last event of the batch, plus:
{batch.count}, {batch.users}, {batch.user_ids}, {batch.first_at},
{batch.last_at}, {batch.overflow}.
The anti-raid gate, end to end
Trigger any message
Batching window 60s · max wait 60s · only fire at 30 · per channel
1. Lock the channel
2. Post "locked: {batch.count} messages in 60 seconds"
Below thirty messages a minute, nothing ever happens.
Two limits worth knowing
Batching is not offered on button and select triggers: Discord's reply window would be long dead by the time the batch flushed, so early clickers would get nothing.
The schedule is durable, a restart mid-window loses nothing, but the collected events live in cache. If that cache is unavailable the rule falls back to firing per event. It degrades to noisy, never to silent.
