Automations - Triggers Reference

A trigger is the event that makes a rule run. Each rule has exactly one, chosen under Run this rule when in the rule editor. The dashboard shows the label in the second column; the first column is the internal name used in these docs.

Notes on triggers

• Messages (on_message): new messages. Under the trigger, Also check edited messages runs the rule again when a message is edited, so a word, link or invite filter cannot be dodged by posting something harmless and editing it afterwards; leave it off for rules that should act once per message (replies, greetings). Edits never count toward the spam detectors, and only real edits count (not the link previews Discord adds). Other bots' and webhooks' messages reach only rules with Include bots and webhooks on (under Advanced), and the bot's own messages only rules with Include the bot's own events; the spam detectors never count either.
• Reactions (on_reaction_add, on_reaction_remove): fire for a reaction on any message in the server, older messages and messages from before the bot restarted included. The member is who reacted; the message conditions check the message reacted to. Reaction emoji is picks the emojis the rule reacts to: a standard emoji matches in every skin tone, and a server emoji keeps matching after it is renamed. The emoji and how many of it the message now has are in the Reaction variables.
• Moderation (on_mod_*): fire for every moderation case of that type, whether it came from a slash command, an action taken directly in Discord, an infraction threshold or another automation rule. A timeout, kick or ban the bot carries out fires the trigger once it went through (a refused one fires nothing), so a rule that bans on a kick never gets ahead of the kick. They need the Moderation module. Under the trigger, Staff actions and Automatic actions (both on by default) choose which of them the rule runs for: automatic ones are those taken by automation rules, infraction thresholds, anti-spam and bots, and a timeout that ran out.
  • When a member's timeout ends (on_mod_untimeout) fires once for every end of a timeout: /untimeout, the timeout removed in Discord, or the timeout simply running out (noticed within about two minutes, since Discord announces nothing then). For a member who left while timed out, it still runs when the timeout ends, without the member-based actions. It fires after the Moderation module has given back the roles of Remove these roles while timed out (see Taking Action).
  • When a note is added to a member (on_mod_note) fires for every /note.
• Spam (on_*_spam, on_spam_detected): fire when a member (or, for joins and new threads, the server) passes a spam threshold: the Moderation module's Anti-Spam detector's, or the rule's own. See Spam triggers below. Join raid detected hands its rules every member who joined in the burst, for the *_join_spam_members actions, and Thread creation spam detected the threads and their creators, for the *_thread_spam_creators and *_thread_spam_threads actions.
• Anti-raid (on_antiraid_level): runs after every level change, whoever made it. Use the conditions Anti-raid level is or Anti-raid level is at least to react to particular levels.
• Level-ups (on_level_up_text, on_level_up_voice): fire when a member reaches a new level in the Levels module.
• Custom status (on_custom_status_update): fires when a member sets or changes their custom status, also when they come online with one, but not when they clear it. It needs the presences intent. Pair it with Custom status contains text, for example to catch invite links or scam offers in statuses.
• Threads (on_thread_create, on_thread_delete, on_thread_update, on_thread_archive, on_thread_unarchive): the member is the thread's creator, so member conditions, variables and actions (roles, timeout, kick, ban, warn, DM) apply to them; a creator who left is only a user (a ban still works). When a thread is archived and When a thread is unarchived fire only when that changes; When a thread is updated fires on every change of a thread the bot has cached (a rename, a lock, slowmode, tags, archiving). Threads the bot makes itself (proof and form threads) run rules only with Include the bot's own events on.
• The bot's own events: no rule runs for something the bot itself did (its reactions, its role or nickname changes, its threads and invites) unless the rule has Include the bot's own events on under Advanced.

Spam triggers

The spam triggers are Any spam detected, one per Anti-Spam detector (Message, Mention, Link, Attachment, Emoji, Line, Character and Sticker spam detected) and the two server-wide ones, Join raid detected and Thread creation spam detected.

Thresholds

Under the trigger in the rule editor, a per-detector or server-wide spam rule uses either:

• Anti-Spam settings (the default): the detector's amount and window on Moderation > Anti-Spam, with its scope overrides and Count per channel. The rule runs only while that detector (and Generic Anti-Spam Enabled) is on.
• Own threshold: its own Amount and Within (seconds) (1 second to 1 hour) and, for the per-member triggers, Count per channel. The rule then runs whatever the Anti-Spam settings, even with Anti-Spam off, and its conditions decide where it applies.

Any spam detected always uses the detectors: it runs when any enabled detector trips, and matches the detectors that did.

After a rule fires

A per-member spam rule remembers the messages it acted on and does not count them again, so it needs a new burst from that member to fire again. Each rule keeps its own count: a stricter rule of the same kind still counts every message, so rules can escalate, for example:

For Keep cleaning for (seconds) after it fired (10 by default, 0 to 60), the rule does not fire again for that member (in that channel, when it counts per channel). If the rule has Delete contributing spam messages, each further message of the same kind from the member meanwhile is deleted and added to the rule's archive, without running the actions or logging again. Other rules still see those messages.

The server-wide triggers fire on every join or new thread while the count stays over the threshold, so a rule acts on the latest arrivals as well.

Archives and logs

When a per-member spam rule fires, the messages behind it are saved in an archive (a web page kept for 30 days), which its messages can link with {spam.archive_url}; see Variables. Messages it deletes are reported in one Message Spam or Spam Detected mod log entry with that archive, not one by one; see Anti-Spam.

Rule order across triggers

A message runs the When a message is sent rules first, then the per-detector spam rules in detector order (message, mention, link, attachment, emoji, line, character, sticker), then Any spam detected. A rule with Allow further rules off that ran successfully ends this for the message: after a When a message is sent rule, no spam rule runs for it (the message still counts toward the detectors), and after a spam rule, no later spam trigger does.

Scheduled rules

On a time schedule (cron-like) runs a rule by the clock instead of on an event. Pick how the schedule is written:

Times use the server's primary timezone. The bot checks schedules once a minute and runs a due rule once. A scheduled rule has no member, message or channel behind it, so its actions need their channel set explicitly, and member-based actions and variables are not available.

What each trigger allows

The rule editor only offers the conditions and actions that work with the chosen trigger: