How to set up a Discord warning system bot

Before you start

• Have an online bot in a test server you manage with Moderation enabled. Moderation is included on the Free plan.
• Use a consenting test member and a staff account with Moderate Members. Put the bot role above the test member’s highest role, and confirm the bot can send messages in the channel where you will test.

1. Enable Moderation and separate it from AutoMod

   Open your bot’s Modules tab, enable Moderation, and select the test server before opening Settings. The module is Free and does not need a paid-plan setting to create a warning. This guide concerns a moderator deliberately recording an action after reviewing a situation. The AutoMod module is a different feature that can respond to configured filters; do not describe a manual warning as an automatic content scan or expect these commands to create an AutoMod rule.

   Choose a small staff-only test channel or a calm public test channel. The bot needs ordinary send permission there so it can show the result. In Discord, verify that the bot role is higher than the test member and that the staff member has Moderate Members. Warning actions check role hierarchy even before an escalation might be needed. A test against an owner, another bot, or a member above the bot is not a useful confirmation of the normal workflow.

2. Choose notification and log settings first

   In Moderation Settings, choose whether to DM users on punishment, optionally select a Log Channel, and decide whether moderation command messages should be auto-deleted. DMs are on by default, but a member can have DMs closed, so a DM attempt is not a guaranteed delivery record. A log channel is useful for staff visibility; make it a channel that the bot can write to and that only the appropriate staff can read. Save after each deliberate change.

   Use `modconfig` with no arguments to inspect the saved moderation settings from Discord. To adjust DMs, use `modconfig dm on` or `modconfig dm off`; the command can also set a log channel by a channel mention, ID, or matching text-channel name. Keep the first test simple: a clear reason, one test member, and no automatic consequence. Recording where staff will review actions is more useful than adding many settings before anyone has verified the basic warning path.

3. Issue one clear, reversible test warning

   From the authorized staff account, enter `warn @TestMember Please use the test channel`. The member mention is required; the rest of the command is the reason. The handler creates a moderation case and, when warning storage is available, adds an active warning for that member. The response includes the current warning total and the reason. Check the response carefully so staff can see that the target and reason were not reversed or omitted.

   Do not use a real member or a vague accusation for this test. A reason becomes part of the moderation record, and a clear test reason makes later cleanup easy to recognize. The warning handler will not target a bot, and it rejects hierarchy situations the moderator or bot cannot act on. If the command fails, inspect the mention, staff permission, role ordering, bot availability, and channel permissions before repeating it. Repeating a command without checking can create more records than the one test you intended.

4. Review the member history and its case record

   Enter `warnings @TestMember` to view the member’s active warning list. The display shows up to ten warning entries and includes the total count, so it is useful for a quick staff review rather than a substitute for a written policy. Enter `modlogs @TestMember` to review the moderation cases for that member. Case history can include different moderation actions, while the warning list concerns warnings. Keep those two records conceptually separate when explaining a decision to a member.

   Use `case 1` only when 1 is the case number displayed for the test server; case numbers are sequential per server. The case view identifies the action, target, moderator, reason, and date, and includes a duration only when that action has one. If staff need to correct the reason, use `reason 1 Updated test reason` with the actual case number. Correcting a case reason does not change the underlying event into a different action, so write specific reasons before acting whenever possible.

5. Add escalation only after the record workflow works

   The default warning threshold is 3 and the default warning action is none. Leave the action at none during an initial test. If your staff has an agreed policy, the dashboard can set a fallback threshold and action, or an authorized staff member can use `modconfig warnthreshold 3` and `modconfig warnaction mute`. The allowed fallback actions are none, mute, kick, and ban. A mute chosen through the fallback action lasts one hour in the current handler.

   For a more explicit rule, `modconfig autopunish 3 mute 1h` creates a mute rule at three warnings. Auto-punish rules support mute or ban, and the highest matching warning-count rule wins. A mute rule without a valid duration defaults to one hour. Do not add an escalation simply to test the command on a real member: it can take a moderation action after a warning. Test the record-only workflow first, review role hierarchy, and use a consenting account in a disposable server if you need to verify a policy rule.

6. Clean up the test and publish staff expectations

   After confirming the display, remove the test warning with `delwarn @TestMember 1`, using the number shown in that member’s warning list. To remove all active warnings for a member, authorized staff can use `clearwarnings @TestMember`; use that broader command only after checking the target. Warning deletion deactivates warning records, while case history is a separate record. Review the list again after cleanup so the test does not become misleading history for future staff.

   Write a short moderator policy outside the command itself: what deserves a warning, how reasons should be phrased, who reviews history, and when escalation is appropriate. Do not treat a warning count as a complete account of context. The Free Moderation module can help make staff actions consistent, but it cannot decide facts, resolve appeals, or replace human review. Once the test is clean and the policy is clear, use the signup button below to configure the same workflow for your own hosted bot.