Documentation menu

Docs/Plugins/Honeypot

Honeypot

Trap channels that automatically action bots posting where no human would.

Requires the HONEYPOT feature.

A honeypot is a channel no human should post in - hidden at the bottom of the list, named accordingly, with a pinned warning if you like. Compromised accounts and spam bots mass-post into every channel they can see; the moment one posts in a trap channel, HepBoat actions it automatically and cleans up the mess.

plugins:
  honeypot:
    enabled: true
    exempt_roles: [411175551308398592]   # extra roles to exempt
    action_bots: true
    channels:
      665875009507426304:
        action: ban              # kick / softban / ban / tempban
        delete_message_days: 1   # on a ban or tempban, also purge recent messages
        tempban_duration: 3d     # only used by tempban - 3d, 12h, 1w, 1h30m
        log_channel: 665875009507426305
        notice: true             # sticky warning embed with a running counter

Setup checklist

  1. Create a dedicated trap channel. Regular members must be able to view and post there, while its name and topic make it clear that posting is forbidden.
  2. Open Setup > Honeypot, enable the plugin, and add that channel.
  3. Start with action: kick or a short tempban while testing. Add staff and trusted automation roles to exempt_roles.
  4. Choose a dedicated log_channel. The bot needs View Channel, Send Messages, and Embed Links there.
  5. For ban or tempban, choose the purge window. For tempban, set a duration such as 3d.
  6. Save and run Diagnostics. Confirm the bot has Kick or Ban Members for the selected action and sits high enough to act on the test account.
  7. Post once as a non-staff test account. Confirm the message cleanup, infraction, mod log entry, dedicated notification, and notice counter.
  8. Test the Unban button if the selected action bans, then switch to the final production action.

Setting one up well

  1. Create a channel everyone can see and post in, but that reads as obviously off-limits (#do-not-post-here).
  2. Add it under channels, exempt your staff roles, enable the plugin.
  3. The trigger, the action, and the cleanup all land in your mod log like any other moderation event. Set a log_channel for a dedicated notification that also preserves the message that tripped the trap, images included.

Setup → Honeypot configures the same thing with channel pickers.

Seeing what tripped the trap

When a trap has a log_channel, the message that tripped it is forwarded into that channel before anything is deleted, followed by the notification with the action taken and the Unban button.

That order matters. A honeypot ban deletes the message and can purge the member's recent history, and once a message is gone its images stop loading, so a link captured at the time would be dead by the time anyone looked. The forwarded copy is a real message in your log channel, so it keeps working.

This is what lets a moderator answer the only question that matters after a trip: was this a scambot, or a member who genuinely wandered into the wrong channel? If the forward could not be made (missing permissions, or the message vanished first), the notification says so plainly rather than showing a link that will not load.

Choosing the action

  • Ban - permanent, and the usual choice for scambots.
  • Tempban - the same ban, lifted automatically when tempban_duration runs out (3d, 12h, 1w, 1h30m). Good for compromised accounts, where the person gets their account back and you would rather they came back too, or where your appeal policy expects them to wait a set time first. It purges recent messages exactly like a ban does, and it is recorded as a normal tempban infraction, so it shows in the member's history and lifts on schedule even if the bot restarts in between.
  • Softban - ban then immediate unban: clears the last 7 days of messages and removes the account without keeping it out.
  • Kick - removes the account and the triggering message only.

Undoing a false positive

Sometimes the "scambot" is just a member who did not read the room. When a trap bans someone (permanently or temporarily), the log_channel notification carries an Unban button: one click lifts the ban, records a normal unban infraction under the clicking moderator's name, and edits the notification to show who reversed it. Only moderators can use it, it keeps working after bot restarts, and pressing it twice is harmless - if the ban was already lifted (by unban, an appeal, or a manual unban), it simply says so.

Moderators and above never trip a honeypot, and neither does the bot itself - exempt_roles is for the extra roles you want to add on top of that.

Webhook posts are always actioned, whatever action_bots says, and they are handled by deleting the webhook rather than by punishing an account. The sticky notice's counter follows the action you configured, so it reads Bans, Kicks, or Softbans rather than always Bans.

Troubleshooting

  • Your test does nothing: moderators and exempt roles never trip the trap. Use a regular test account.
  • The message deletes but no punishment lands: check Discord permission and role hierarchy for the selected action.
  • There is an infraction but no notification: check log_channel permissions.
  • The notification says the message could not be forwarded: the bot needs View Channel, Send Messages, and Read Message History in both the trap channel and the log channel.
  • Webhook spam remains: the bot needs Manage Webhooks to remove the webhook.
  • The tempban never lifts: confirm the duration parsed, then check the member's timed infraction record rather than relying only on the notification text.