# Discord moderation policy your team can actually follow > Rules tell members what not to do. A policy tells moderators what to do about it — and the second document is the one most servers never write. - Canonical: https://discordservers.blog/blog/writing-a-moderation-policy - Published: 2026-08-26 - Author: The Journal desk - Publication: The Journal, an independent site not affiliated with Discord Inc. --- Most servers have rules. Far fewer have a policy. Rules are member-facing: do not spam, no harassment, keep it on topic. A policy is staff-facing and answers a different question — _given that someone broke a rule, what happens?_ Without one, the answer depends on which moderator was awake, and members notice that faster than anything else you get wrong. ## The problem a policy solves Not bad moderators. [Variance](/blog/scaling-moderation-past-1000-members). Five reasonable people applying their own judgement to the same behaviour will produce five different outcomes. Each is defensible alone; together they read as favouritism, and once members believe enforcement is arbitrary they stop respecting it — including the parts you apply consistently. A policy does not make moderators smarter. It makes them **predictable**, which is what members actually want. ## The minimum viable policy Four sections. It fits on one page and that is a feature. **A severity scale.** Three levels is enough: minor (off-topic, mild rudeness), serious (targeted hostility, repeated minor after warning), severe (harassment, threats, illegal content, raid participation). **A default response per level.** Minor: informal note, logged. Serious: formal warning, logged. Severe: immediate removal, discussed afterwards. The default is what happens absent a reason to deviate. **An escalation ladder for repeats.** Note → warning → timeout → temporary ban → permanent. The specific durations matter less than the sequence being written down. **When to escalate to a human above you.** Anything involving a real-world threat, anything involving a staff member, anything a moderator feels uncertain about. Naming this explicitly is what stops a junior moderator improvising on the worst possible case. ## Write the deviations in A policy that permits no judgement gets ignored within a month, because reality produces cases it did not anticipate. Say explicitly that a moderator may deviate, and require only that they **log why**. That single requirement preserves consistency where it matters — the reasoning is inspectable — without turning your team into an enforcement machine that cannot handle context. The failure mode you are avoiding is not "a moderator used judgement." It is "nobody can reconstruct why this member was banned." ## Log everything, including the informal The informal note is the part teams skip, and it is the one that makes the ladder work. A third warning is only meaningful if someone can see the first two, and the first is usually a quiet word that nobody recorded. If your bot supports notes distinct from warnings, use both: a note is context, a warning is a formal step on the ladder. If it does not, log notes as warnings and mark them. What must be captured every time: who, what, which rule, what action, and who took it. Vetox's own version of that record lives inside its moderation commands: `/warn-add` and `/warnings` write to and read a per-member history capped at 100 warnings per member and 1,000 warned members per server — identical whether the server pays or not — so a moderator opens one command and sees the whole prior record in seconds rather than assembling it from a channel search. **Command Management** attaches a preset reason to any moderation command, free on every tier, which is what turns "what rule, in whose words" into a dropdown instead of a sentence composed at 2am — and a preset, consistent reason is also the thing an appeal reviewer can actually parse a year later. ## Publish the parts members should see The severity scale and the escalation ladder should be public. Members behaving well are not disadvantaged by knowing what happens if they do not, and publishing removes the largest source of appeal friction — the belief that the outcome was invented on the spot. [Reviewing an appeal well](/blog/discord-appeal-process) depends entirely on there being a documented ladder to check the original decision against. Keep private: specific thresholds that would help someone game the system, and anything naming individual staff. ## Review it after real cases A policy written in the abstract survives contact with reality badly. Schedule a review after the first month and then quarterly, and drive it from actual cases: which decisions were hard, where did two moderators disagree, what did the policy not cover. The output of that review is usually one clarifying sentence, not a rewrite. ## The tooling that supports it Three capabilities make a policy practical rather than aspirational, and the third is the one most servers do not think to check for until they need it. **Queryable per-member history** — a moderator handling an incident needs the member's prior record in seconds, not a channel search. Covered above: this is what the warning system is for, and it is free on every tier, bounded only by the 100-per-member ceiling that exists to keep the record legible rather than to ration it. **Automated escalation** — a system that applies the ladder itself for mechanical offences removes the most common source of inconsistency, which is a tired moderator at 2am guessing whether this is strike two or three. Vetox's **Automated Actions** count a member's violations across every automod rule inside a rolling window and fire the next rung on its own; Starter allows one such action, every paid tier allows fifty. This is the feature that turns the escalation ladder from a document staff are supposed to remember into a setting that applies itself. **A record of who changed the policy's own configuration.** The one nobody thinks to ask for, because a policy document quietly assumes its own enforcement settings are stable. They are not — automod thresholds get retuned, a role gets added to an exemption list, and six months later nobody can say when or by whom. Vetox's **Dashboard Watcher** logs exactly that: user, module, timestamp, and the specific settings that moved, free on every tier, keeping the last 500 changes for 90 days. Pair it with **Access Control** ($7.99/month, Max) once the team is large enough that not everyone should be able to touch the escalation settings at all — delegate the sections that need delegating, and let the watcher confirm what each delegate actually did with the access. Most general bots offer some version of the first two; the third is rarer, and it is worth checking for specifically, because a policy you cannot audit is a policy you are trusting people to have followed. ## The shortest version If you write nothing else, write the ladder and where to log. Those two produce most of the consistency benefit, take an afternoon, and are the difference between a moderation team and five people improvising in parallel.