Tuning your rules
The workflow people skip and then regret: monitor first, read the log, fix the rule rather than the sensitivity, and know the escape hatches before you need them.
This is the part people skip. It is also the difference between a bot your moderators trust and one they switch off after a bad afternoon.
Follow it in order.
1. Stay in monitor mode
Every server starts in monitor mode, and you should leave it there for a while. The whole pipeline runs: every detector, the full judgement, the log entry. Only the action is withheld, and the log records what would have happened.
Nothing is learned by enforcing on day one that could not be learned more cheaply by watching for a week.
2. Set a log channel, and turn the volume up
Decisions are recorded whether or not you have a log channel, but you will not see them in Discord without one. While you are tuning, also switch on:
- Log events that resulted in no action. Noisy on a busy server, and it is the only way to see the near misses.
- Log messages that were exempt. Shows you what your staff would have tripped, which is often where the worst false positives hide.
Turn both off once you are enforcing.
Logging every clean message is all or nothing, and on a busy server it is thousands of embeds a day in a channel nobody can then read. If that is your problem, there is a score floor beside the setting: log the near misses and stay quiet about everything below it. That is usually what people wanted when they turned clean logging on, and it is the only way to see near misses in Discord without arming an action on a band you do not want enforced.
Three more things worth setting once and forgetting:
- A separate channel for the most serious events. Without one they land in the ordinary log with everything else, which is where they get missed. It falls back to your main channel if you do not set it.
- A role to ping when one of those fires. Nothing else pings anybody.
- Which kinds of event count as most serious. You can name your own, so the thing your server actually fears goes to the urgent channel and pings the role, whatever Wardnox considers serious in general.
Moderator buttons on log entries are on already. That is what makes an entry something you act on rather than something you read.
3. Watch for a few days
You are looking for three things.
| In the log | What it means |
|---|---|
| "Would have done" on an obvious scam | Working correctly |
| "Would have done" on ordinary conversation | A false positive. Read the explanation |
| An obvious scam that scored nothing | A gap in your rules |
Every log entry carries the reasoning that produced it. Read it. The question is never "why did it flag this", it is "which part of this is wrong".
4. Check which rules are actually wrong
The dashboard reports how often each rule fired and how often a moderator marked that firing a mistake. Mark them as you see them, using the False positive button on the log entry itself.
Doing that is not just bookkeeping. It also removes the incident from the member's history, so your tuning does not push somebody up the escalation ladder for something that was never their fault.
Then read the rates:
| False positives | What to do |
|---|---|
| Rare | Leave it alone |
| Occasional | Narrow it: a stricter match type, or a channel or role limit |
| Frequent | The rule is wrong. Rewrite or delete it |
| Almost everything, on a busy channel | Wardnox has probably already paused it. Check the log |
That last row is automatic. A rule that suddenly starts matching a large share of your traffic is switched to monitor mode on its own, your moderators are told, and the message that tripped it is not acted on. A runaway rule cannot mass-delete your channel while you are asleep.
5. Prefer the narrowest fix
In this order:
- Fix the rule. A better match type, a tighter pattern, a channel list. This is almost always the right answer.
- Make the rule contribute less. It stays as evidence without dominating.
- Reduce how much that kind of signal counts across the server.
- Loosen the overall sensitivity. Blunt: it affects everything at once.
- Switch a detector off. Last resort. You lose the signal everywhere, not just where it was wrong.
Changes to your settings and your security profile are snapshotted before they are applied, so options 3, 4 and 5 are one click from being undone. Editing an individual rule is not snapshotted, so note what a rule said before you change it.
6. Test before it goes live
The playground runs your real rules, against your real configuration, through the real engine, and touches Discord not at all. You can describe an author too, so you can ask what would happen to a brand-new account posting the same thing.
/security scan does the same from inside Discord, using your own account.
Use one of them before saving a rule you are unsure about. It costs seconds and it is the only way to find out what a rule does to text you did not think of.
7. Enforce
Switch enforcement on when, over several days:
- everything the log says it would have done looks correct,
- your busiest rules are rarely marked as mistakes, and
- the status command reports no missing permissions.
8. Know the escape hatches before you need them
| Situation | What to do |
|---|---|
| A rule is misfiring and enforcement must stop now | Emergency stop. Scanning and logging carry on |
| Under attack, harden everything | Lockdown, which is reversible and snapshotted |
| Undo that | Unlock |
| A configuration change made things worse | Restore the snapshot taken before it |
Learn these while nothing is wrong. Nobody reads documentation during a raid.
9. Re-tune after anything changes
A new profile, a detector you switched on, a raid, or simply your community talking about something new. Go back to monitor mode for a day. It costs a day of enforcement and it is much cheaper than a mass deletion you have to apologise for.