Antinuke
Arm rules against channel deletes, admin grants and vanity theft, then prove they will actually fire.
Anti-nuke watches the people who already have power in your server. When somebody deletes channels, hands out Administrator or wipes your emotes faster than a rule allows, it punishes them and posts an incident. It is aimed at a compromised staff account, not at strangers at the door. That is anti-raid's job. Every anti-nuke command is Server Owner only, so a granted Administrator permission does not reach it.
Prove it will actually fire
,antinuke check is the most useful command in
this section, and the one to run first. It audits your live configuration and answers one question:
if somebody started nuking right now, would anything happen?
Syntax
,antinuke check
Run this before you need it
The alternative feedback is a warning that arrives after the first channel is already gone. The check is read-only, takes no arguments and changes nothing, so run it as often as you like.
It reports failures and warnings in a single embed, with a footer counting how many rules are armed. What it looks for:
| Finding | Why it matters |
|---|---|
| Nothing is armed | Every other check would come back clean on a server with zero protection |
| The bot is missing View Audit Log | Every rule below is inert without it |
| Roles sit at or above the bot's highest role | Anyone holding one of those cannot be punished |
| An armed rule needs a permission the bot doesn't have | That punishment fails every time the rule trips |
| No protection log channel, or one that no longer exists | Incidents have nowhere to go |
| The bot can't post in the configured log channel | Same outcome, different cause |
| Incidents are only reaching a channel through the Logs-channel fallback | No dedicated protection log is set, so incidents are landing in your general log channel. Fine if you meant it, easy to miss if you didn't |
| The whitelist is empty | Nobody, including your own staff, is exempt |
stripstaff is armed with no staff roles configured | That punishment would remove nothing |
Fix every failure before you trust anything on this page. A warning is worth reading but is not necessarily wrong: an empty whitelist is deliberate on some servers.
Arm your first rule
Give the bot a place to report
Run ,antinuke log <channel>. Without a
protection log, incidents fall back to your general log channel, and without that they are lost.
Syntax
,antinuke log <channel|off>
Example
,antinuke log #protection-logs
Whitelist the people who are allowed to do this
Run ,antinuke whitelist add <user|role>
for the staff whose legitimate work would otherwise trip a rule.
Syntax
,antinuke whitelist <add|remove> <user|role>
Example
,antinuke whitelist add @Staff
Arm a rule as a dry run
A warn rule posts the incident and does nothing else, so you can watch what it would have
caught.
Syntax
,antinuke channel on [++punish <punishment>] [++threshold <number>] [++window <seconds>]
Example
,antinuke channel on ++punish warn
Audit it
Run ,antinuke check and clear every failure.
Promote it to a real punishment
Re-arming keeps the threshold and window you already set.
Syntax
,antinuke channel on ++punish <punishment>
Example
,antinuke channel on ++punish ban
The most common actions have a subcommand of their own:
channel,
role,
emote,
botadd,
grantadmin and
removeadmin. Every other action is reached
through ,antinuke rule <action> <on|off>, which
takes the same flags and writes the same rule. The slash form offers the action as a picker, so you
cannot mistype one.
Syntax
,antinuke rule <action> <on|off> [++punish <punishment>] [++threshold <number>] [++window <seconds>] [++wide <on|off>] [++countbot <on|off>] [++revert <on|off>]
Example
,antinuke rule webhook on ++punish ban ++threshold 3
Choose what each rule watches
Actions that count toward a threshold
These trip only once enough matching actions land inside the window.
| Action | Trips on |
|---|---|
channel | a channel being deleted |
channelcreate | a channel being created |
role | a role being deleted |
rolecreate | a role being created |
emote | an emote being deleted |
sticker | a sticker being deleted |
ban | a member being banned |
unban | a member being unbanned |
kick | a member being kicked |
webhook | a webhook being created, changed or deleted |
integration | an integration being added or removed |
guild | server settings being changed |
Actions that trip on the first occurrence
These have no threshold and no window, on purpose. There is no acceptable number of times to hand Administrator to a stranger, or to sell the server's vanity URL, before something happens.
| Action | Trips on |
|---|---|
botadd | a bot being added to the server |
grantadmin | admin-shaped permissions being granted |
removeadmin | admin-shaped permissions being removed |
vanity | the server's vanity invite code being changed |
Set the threshold, the window and the punishment
The flags every counting rule accepts
++threshold is how many matching actions trip a rule, and ++window is how many seconds they have
to land inside. A rule armed with no flags uses a threshold of 3 inside a 60 second window.
| Flag | Accepts | Default |
|---|---|---|
++punish <punishment> | warn, timeout, stripstaff, kick, ban | ban, except emote which defaults to stripstaff |
++threshold <number> | 1 to 50 | 3 |
++window <seconds> | 5 to 300 | 60 |
Syntax
,antinuke <action> on [++punish <punishment>] [++threshold <number>] [++window <seconds>]
Example
,antinuke channel on ++punish ban ++threshold 3 ++window 60
Wider windows catch a slow, patient nuke. Narrower ones only ever see a burst. A tight threshold on a
busy server with active moderators is the usual cause of a false positive, which is what the
whitelist and warn are for.
What each punishment needs from the bot
Each punishment needs a permission the bot actually holds, and ,antinuke check tells you when it
does not:
| Punishment | Bot needs | Notes |
|---|---|---|
ban | Ban Members | |
kick | Kick Members | |
timeout | Moderate Members | Fixed at one hour, and reversible |
stripstaff | Manage Roles | Removes the roles on your ,staff list, so that list must not be empty |
warn | nothing | Posts the incident and takes no action at all |
One punishment per person, not one per action
One punishment, not thirty
Somebody who trips a rule is punished once for that incident, not once per action they took. A thirty-channel nuke produces one punishment and one incident embed rather than thirty of each.
That works as a 10 minute latch per person, across every rule at once. Once somebody has been punished, nothing they trip in the next 10 minutes produces a second punishment or a second incident, not the same rule again, and not a different one. Worth knowing before you read a quiet log as a rule that stopped working: a second incident three minutes after the first is silent on purpose.
Turn on the extra options a rule supports
Three flags are only accepted by the actions they make sense for. Asking for one elsewhere is refused with a message saying so.
++wide: watch the permissions that come before Administrator
++wide <on|off> applies to grantadmin and removeadmin. By default those rules watch
Administrator alone. With wide on they also watch the permissions that usually come first:
Ban Members, Kick Members, Moderate Members, Manage Server, Manage Channels, Manage Roles, Manage
Webhooks, Manage Expressions, Manage Nicknames, Mention Everyone and View Audit Log. The incident
embed names which one actually tripped it. Each rule reads its own flag, so widening grantadmin
leaves removeadmin alone.
Syntax
,antinuke grantadmin <on|off> [++punish <punishment>] [++wide <on|off>] [++revert <on|off>]
Example
,antinuke grantadmin on ++punish ban ++wide on
++countbot: count actions a person ordered through the bot
++countbot <on|off> applies to ban, kick, unban, grantadmin, removeadmin, role,
rolecreate, channel and channelcreate. Actions the bot performs are normally excused, which
also excuses a moderator who does the same thing by running the bot's own commands in a loop.
With countbot on, an action a person ordered through the bot counts against them personally.
Punishments the protection engine issues itself are never counted, so a rule can never trip on
its own response.
Syntax
,antinuke rule <action> <on|off> [++countbot <on|off>]
Example
,antinuke rule ban on ++punish ban ++countbot on
What countbot cannot cover
Discord's own bulk ban tool removes many members in one call and never touches this bot, so no anti-nuke rule sees it coming. The defence there is not granting Ban Members, real or fake, to anyone who should not have it.
A mass prune counts once, not once per member
Discord reports pruning as a single audit entry however many members it removed, and a prune is
counted against the kick rule. So a prune that clears hundreds of people adds one
occurrence toward that rule's threshold. A kick rule with the default threshold of 3 will not
trip on a prune alone. Lower the threshold to 1 if a prune is something you want caught on its
own.
++revert: put back what the triggering action changed
++revert <on|off> applies to channelcreate, rolecreate, ban, unban, grantadmin,
removeadmin, guild, webhook, integration and botadd. Read
the next section before turning it on. What it can and cannot
reverse is narrower than it sounds.
Syntax
,antinuke rule <action> <on|off> [++revert <on|off>]
Example
,antinuke rule channelcreate on ++punish ban ++revert on
Undo the damage with revert
revert runs after the person is punished, never before. Removing their ability to act again is the
actual fix, and restoring things while they still hold whatever let them act is a race you lose.
What revert can put back
It only reverses what the triggering action itself carries: delete a channel, role, webhook or
integration that was just created, re-ban somebody just unbanned, unban somebody just banned, take a
granted admin-shaped permission back off, put a stripped one back on, or restore a server setting to
its previous value. On botadd the invited bot is removed, and that one is on by default: pass
++revert off if you would rather keep the bot and only punish whoever added it.
What revert can never undo
It cannot undo a deletion
A deleted channel, role, emote or sticker is never recreated. Undoing a delete needs a snapshot of
what was destroyed and this system does not take one. revert is not a backup, and channel,
role, emote and sticker do not accept the flag at all.
Two more things it will never do. A kick cannot be undone, because Discord has no un-kick. A stolen vanity URL cannot be written back by a bot at all. The incident embed prints your old code so you can reclaim it by hand in Server Settings → Vanity URL, and it is worth doing quickly before somebody else takes the freed code.
When revert is held back
Revert is held back in two situations, and the incident embed says which one applied. It never
runs on a rule armed as warn, because a dry run that deletes channels is not a dry run. And it
never runs when the punishment itself was skipped, because the person is still in a position to
do it all over again.
A revert pass is bounded. If it cannot finish, or it notices the same things being destroyed again, it stops and reports what it did not attempt in a follow-up summary rather than silently truncating.
Re-arming a ban rule
Re-arming ban always needs revert stated again
Every other action carries its revert setting forward when you re-arm it. ban does not.
Auto-unbanning is powerful enough that it must be asked for explicitly with ++revert on each
time.
Keep your staff off the punishment path
,antinuke whitelist takes add, remove,
list and clear, and accepts either a user or a role. A whitelisted person's actions are exempt
from every rule.
Syntax
,antinuke whitelist <add|remove|list|clear> [user|role]
Example
,antinuke whitelist add @Staff
The server owner is never punishable, whether whitelisted or not. Discord's owner outranks everybody regardless of role position, and no bot can act against them.
Whitelisting a role above your own highest role is refused. Allowing it would let a member permanently exempt a role they do not control, which is a privilege escalation dressed as a config change.
Review and reset
,antinuke info lists every armed rule with its
punishment, threshold, window and any extra options. Rules can also be armed and edited from the
Anti-Nuke page of the ,config panel, which writes exactly what
the commands write.
Syntax
,antinuke info
,antinuke reset turns every rule off at once.
It does not clear the whitelist or the log channel.
Syntax
,antinuke reset
Common issues
,antinuke check says a role sits at or above the bot. Drag the bot's own role higher in
Server Settings → Roles. A tie is as unpunishable as being outranked.
A rule is armed but nothing happens. Most often the bot is missing View Audit Log. Run
,antinuke check. It names the cause.
stripstaff trips but removes nothing. Your staff-role list is empty. Add roles with
,staff add <role>.
A moderator got banned for doing their job. Whitelist them or the role, then raise the threshold
or widen the window. Re-arm the rule as warn for a while if you want to watch it first.
Nothing appears in the log. Set a dedicated channel with
,antinuke log <channel> and confirm the bot can
post there. The check reports an unpostable channel as a failure, and reports a general log channel
standing in for a missing protection log as a warning.
The shared Get protection to actually fire entry works the same ground from the symptom end, and covers the Anti-Nuke Is Not Working incident the bot posts when a rule is armed without View Audit Log.