Guide/Protect your server/Cohorts: raids found by shape, not speed
Cohorts: raids found by shape, not speed β Discord Bot Guide
Raids found by how accounts resemble each other rather than how fast they arrive; review, undo, ban, sleepers, drills.
Quick answer
After an attack
!raid cohorts
!raid review a1b2c3d4
!raid undo a1b2c3d4 # wrong call: release everyone in it
!raid ban a1b2c3d4 # confirmed: asks before banning
!raid sleepers 90Ask the guide
Step by step
Why rate detection is not enough
Every raid protection on the market β including the join limit above β asks how many accounts arrived in the last minute. An attacker answers that by waiting. Thirty disposable accounts joined over three hours never trip a threshold, sit quietly, and start at once. Cohort detection asks a different question: do these accounts look like each other in ways unrelated people never would β the same naming formula, registrations minutes apart, the same invite, no avatars.
The grouping is done in code over a six-hour window, and the group is then judged as a whole. Nothing about when they joined is used to link them, because that is the one signal an attacker controls for free.
What happens when a cohort is confirmed
The accounts in the group are contained β quarantined by default, or whatever !antiraid action is set to. The server is not locked. Members who were already talking never find out it happened, which is the opposite of the usual outcome where a raid causes an outage whether or not it gets in.
The alert says what the accounts had in common and how certain the reading was, and links back to the cohort for review.
Going viral is not a raid
Fifty joins a minute after a video mentions your server looks identical to an attack under a rate threshold, so servers get locked down at the best moment of their life. A cohort is judged for both whether it was sent by one operator and whether it is real people arriving. When the reading is a genuine influx, the raid response stands down for an hour and the join limit is ignored.
Recovery without collateral
After an attack, staff normally ban a time range by hand and take the real members who joined during it along with the raid. Instead, review the group:
!raid cohorts groups judged recently
!raid review <id> who was in it and what they shared
!raid undo <id> release every account in the group
!raid ban <id> ban every account in the group (asks for confirmation; needs the ban permission)
!raid sleepers past raiders still here who never spokeSleepers is the backwards-looking half: most large servers are carrying the quiet leftovers of raids from months ago, and a join date cannot tell them apart from the real people who arrived the same day.
Network intelligence
When a raid is confirmed, Sweet stores a one-way fingerprint of its shape β the naming formula, the account-age band, whether avatars were set. Other servers running Sweet recognise that shape immediately, so the second server never has to learn the attack the hard way. No member lists, user IDs or server identifiers are shared; only the fingerprint.
Drills
Every owner runs their security settings blind until the night it matters. A drill runs three simulated arrivals β a patient raid, a classic fast raid, and a genuine influx β through the same code the live path uses, and reports exactly what your current settings would have done. Nothing touches the server: no joins, no punishments, no log entries.
!raid drillCopy and try
After an attack
!raid cohorts
!raid review a1b2c3d4
!raid undo a1b2c3d4 # wrong call: release everyone in it
!raid ban a1b2c3d4 # confirmed: asks before banning
!raid sleepers 90Good to know
- raid ban and raid undo need the ban permission, not only the configuration key.
- A prefix that matches several cohorts is refused; type more of the id.
Still stuck? Ask in the support server.