Skip to content

Moderation System

Moderation in Armory Bot is built around one idea: every action leaves a case behind. Warn, timeout, ban — each one lands in the case history, so any moderator can pick up where the last one left off.

Command Groups

  • /mod — main moderation actions
  • /cases — case, notes, history, and report tools

Core Actions

Member actions (/mod)

  • Kick, ban, softban, unban, tempban
  • Timeout and untimeout
  • Warn, warnings, clearwarn, clearwarns
  • Purge message batches with optional filters
  • Channel lock/unlock and slowmode
  • Add/remove roles with hierarchy checks
  • Massban helper for raids, bot-message cleanup, snipe, history import

Case tracking (/cases)

  • View/list/update case reasons
  • Stats and moderation activity summaries
  • History export
  • Internal moderator notes
  • Incident report command

Warning and Escalation Behavior

Warnings are persisted and surfaced through /mod warnings and case records.

Warning threshold actions and automod policy settings are configured on the Moderation and Automod dashboard pages (open with /dashboard) — "configure on the web, act in Discord" (ADR-0015).

Configuration (Dashboard)

  • Moderation page — mod log channel, public log channel, mute role, report channel/webhook, per-action defaults and DM templates
  • Automod page — master toggle, spam/link/badword/mention/caps rules with per-rule thresholds and exemptions, warning threshold/action/decay

Honeypot Channel

The honeypot is a trap channel: post the bait message in it, and anyone who sends a message there gets banned. There's no command for this — it's configured entirely on the Moderation dashboard page.

Setting it up

Point the honeypot at a fresh, empty channel. The bot posts two messages and pins them both: the bait message, and a counter directly underneath it. They need to be the first two messages in the channel. Because every later post is deleted by the trap, the pair then stays together at the top permanently without anything having to maintain it.

Set the enable toggle, pick the channel, write the bait message, and choose how many days of that member's recent messages to delete on ban (0-7, default 1). Saving publishes both messages; saving again edits them in place rather than posting new ones.

The bot needs Manage Messages in that channel to pin. If it can't — no permission, or the channel has hit Discord's 50-pin limit — the messages still post and the trap still works; the dashboard just warns you they went up unpinned. Leave the channel visible to @everyone, or the trap catches nothing.

The bot also needs Ban Members at the server level. Without it the trap still deletes what people post, but it can't ban them — so the dashboard warns you on save if the permission is missing. Watch for role hierarchy too: the bot's highest role has to sit above anyone you expect it to ban.

Who gets banned

Nobody is safe except the server owner. The exemption is owner-only — admins and moderators are not exempt and will be banned like anyone else if they post in the honeypot channel.

Some messages are deleted but never trigger a ban: webhook messages, and system messages such as pin notices, join notices, and boost announcements. Those carry a real member as their author, so without that exemption an admin pinning something in the channel would be banned by the trap.

Threads count as the honeypot too. A thread is a separate channel with its own id, so posting inside one used to slip past the trap entirely. Anything posted in a thread under the honeypot channel is now caught exactly as if it were posted in the channel itself, with the same owner-only exemption. Opening a thread isn't itself a post — the "started a thread" notice is just deleted — but the first message inside it triggers the ban. Denying @everyone Create Public Threads in that channel keeps things tidy, though the trap no longer relies on you doing so.

The thread is deleted along with the catch, so the channel never accumulates empty husks for the next raider to reuse. That applies even when the poster was exempt — the server owner keeps their skin, but the trap channel still keeps no threads. This needs Manage Threads; without it the ban still lands and only the empty thread is left behind.

The counter

The counter message is a template you write, with {count} for the running total — for example Scammers caught: {count}. Every catch edits that pinned message in place. Leave the counter template blank if you'd rather have just the bait message and no counter.

The dashboard also shows the same lifetime total read-only, and that number is the authoritative one: it's recorded the instant a ban succeeds, while the pinned message is a view of it that updates a few seconds later.

Ban messaging

Three surfaces can be given honeypot-specific text. Each one is optional, and leaving it blank keeps whatever your server already does:

Field Blank means
Ban DM Send your normal ban DM
Announcement Channel Use the server's ban announcement channel (Welcome page)
Announcement Message Post your normal ban announcement

The ban DM goes out just before the ban lands — a member who wandered in gets told why, though a spam bot will never read it. The announcement replaces your normal ban announcement for honeypot catches rather than adding to it, so the community sees exactly one message per ban. Its template takes {caught} for the number caught in this wave and {count} for the all-time total.

Under a raid

Bans and deletions are immediate and one-to-one, and every catch gets its own mod-log entry with the user, their account age, and what they posted — so staff keep the full record. The counter and the public announcement are coalesced: a wave of twenty bots produces one counter update and one announcement rather than twenty of each.

The ban itself is a normal case with reason "{name} triggered" — for example "Honeypot triggered", or "Bear Trap triggered" if renamed. The channel name shown on the dashboard is cosmetic and free to rename; leave it blank for the default "Honeypot".

Typical Workflow

  1. Add a warning:
/mod warn member:@User reason:"Spam in #general"
  1. Escalate if behavior continues:
/mod timeout member:@User duration:60 reason:"Continued disruption"
  1. Inspect history:
/cases list user:@User limit:10
/cases view case_number:42
  1. Update case details when needed:
/cases reason case_number:42 new_reason:"Updated after appeal review"

Bulk and Channel Controls

Purge

/mod purge count:50
/mod purge count:25 user:@User
/mod purge count:20 contains:"discord.gg"

Lockdown and slowmode

/mod lock reason:"Raid mitigation"
/mod slowmode seconds:10
/mod unlock

For a server-wide emergency, /server lockdown locks every text channel at once.

Permissions

Moderation commands require:

  • Manage Server permission, or
  • Explicit moderation override using /permissions grant command_group:moderation ...

Role assignment commands (/role add, /role remove) require the roles command category.

Logging and Audit

Moderation actions create case records and can be routed to a moderation log channel — set the mod log channel on the Moderation dashboard page, and event logging on the Logging page (both opened with /dashboard).

Troubleshooting

Action fails with permission error

  1. Confirm bot role is above target member role.
  2. Confirm bot has required Discord permission for the action.
  3. Confirm moderator has required command permission.

Warning escalation not matching policy

  1. Check policy values on the Moderation and Automod dashboard pages.
  2. Verify /mod warnings output for the target user.

Purge removes fewer messages than expected

  1. Message filters (user, contains) may reduce matches.
  2. Discord bulk-delete constraints can limit removable messages.