Discord Raid Response: The First 60 Seconds

A raid is a coordinated flood — dozens or hundreds of accounts joining and spamming your server in a compressed window, usually to drown channels, post shock content, or mass-mention members. It’s loud, fast, and designed to overwhelm your moderators while it happens.

Most raid advice is written before a raid, as prevention. This page is written for the minute it’s actually happening, and for the part nobody talks about: what’s still in your server after the burst stops.

Minute one: stop the bleeding

In order, fastest first:

  1. Pause your invites. Server Settings → Invites, or disable the active invite link. This cuts the supply line — no new raiders can join while you deal with the ones already in. This is the single highest-value action and it takes seconds.
  2. Raise verification to Highest. Server Settings → Safety Setup → “Highest” requires a verified phone number to chat. It instantly silences accounts that can’t clear it — which is most raid accounts.
  3. Enable / lean on Raid Protection. Discord’s built-in Raid Protection uses join-signal ML to detect raids and can auto-require CAPTCHA from new joiners. If it’s on, it may already be acting; if not, turn it on now.
  4. Lock down the hot channels. Set the affected channels to slowmode (or remove send permissions from @everyone temporarily). This stops the flood without banning anyone yet.
  5. Don’t mass-ban blindly in the chaos. Banning the wrong accounts mid-raid hits real members caught in the crossfire. Contain first (steps 1–4), then identify, then ban.

If you run a dedicated anti-raid bot, this is its moment: Beemo auto-bans suspected raid bursts with no configuration, and Wick’s join-rate controls and verification gate are built for exactly this. They are genuinely good at stopping the burst.

After the burst: the part the tools miss

Here’s what raid-burst protection doesn’t do: once the flood stops and the join rate drops back to normal, those tools stop looking. But a raid is rarely only the loud part. Two things commonly survive it:

Neither shows up to a join-rate detector, because neither is a burst. Catching them means looking at how individual accounts behave over time, and ideally whether the same account is behaving that way in other servers — which a single community can’t see on its own. (This is the same blind spot covered in quiet automation that survives verification.)

What to do once it’s calm

  1. Audit who joined in the raid window. Sort members by join date; review the cluster that arrived around the attack.
  2. Don’t restore invites until you’ve reviewed. Keep the supply line cut while you clean up.
  3. Ban the confirmed raiders, timeout the maybes. Reversible action on uncertain accounts protects real members who joined at a bad time.
  4. Write a short post-mortem. When did it start, what was the join rate, which accounts, what stopped it. Raid crews repeat patterns — your notes make the next one faster to shut down.
  5. Keep watching the survivors. The accounts that joined quietly during the raid are the ones to keep an eye on.

Where Gait fits

Gait isn’t a perimeter tool — it doesn’t gate joins or auto-ban bursts, and you should keep the tools that do. Gait works behind the perimeter: it keeps scoring accounts by their behavior (timing, lifecycle, content rhythm — never message content, see our privacy approach) the whole time they’re in your server, and aggregates those signals across every server running Gait.

That makes it the layer for the after-the-raid problem: the sleeper account that joined quietly, and the raid-crew account that’s hit other communities with the same pattern. Each account is graded from confirmed_human to confirmed_automated, with its Discord identity and the reasons it was flagged, so your moderators decide the action. Pair it with Beemo or Wick for the burst, and let Gait surface what stayed behind.

Related pages