# Discord moderation past 1,000 members: process, not headcount > The point where informal moderation stops working is sharper than most owners expect, and the fix is process rather than more moderators. - Canonical: https://discordservers.blog/blog/scaling-moderation-past-1000-members - Published: 2026-09-24 - Author: The Journal desk - Publication: The Journal, an independent site not affiliated with Discord Inc. --- Small servers moderate themselves. Everyone knows everyone, the norms are visible in the scrollback, and the owner handles the rare problem personally. That model has a ceiling, and it arrives faster than people expect — usually somewhere between eight hundred and fifteen hundred members. Past it, the same approach produces inconsistent decisions, an exhausted owner, and a staff team that quietly stops enforcing things. ## What actually breaks Not the volume of incidents. The **variance** in how they are handled. Below the ceiling, one or two people make every call, so the calls are consistent by construction. Above it, five moderators are making decisions independently, and members notice that the same behaviour gets a warning from one and a ban from another. That inconsistency does more damage to trust than under-moderation does, because it reads as favouritism whether or not it is. The second thing that breaks is context. In a small server the moderator remembers that this member has been warned twice. At three thousand members nobody remembers anything, so every incident is judged as if it were a first offence. ## Write the ladder down The intervention that fixes most of this is unglamorous: a [written escalation ladder](/blog/writing-a-moderation-policy) that every moderator follows. Something like — first offence: informal note, logged. Second: formal warning, logged. Third: timeout, duration by severity. Fourth: temporary ban. Fifth: permanent. The specific rungs matter far less than that they are **written and shared**. A written ladder does three things at once: it makes decisions consistent between moderators, it makes them defensible to the member, and it removes the emotional weight from the moderator, who is now applying a policy rather than making a personal judgement. Written is the minimum. Run by software is better, for the rungs that do not need a person to apply them. Vetox's **Automated Actions** count a member's violations across every automod rule inside a rolling window and apply the next rung itself — mute, then a longer timeout, then further still — so a member who trips three different filters in one evening is handled as one escalating pattern rather than three moderators independently guessing whether this looks like a first offence. Starter allows one such action; every paid tier allows fifty. The ladder in the paragraph above is close to exactly what this feature asks you to configure. ## Logging is not optional past this size If your moderation history lives in your moderators' memories, you do not have moderation history. Every action needs a record with the member, the action, the reason and who took it. Not for bureaucracy — because the third warning is only meaningful if someone can see the first two, and because when a member appeals, the difference between "we remember you causing trouble" and a dated list of incidents is the difference between an argument and a conversation. Most bots log moderation actions. What varies is [whether the history is queryable per member](/blog/writing-a-moderation-policy), and whether the log survives the bot being removed and re-added. Check both before you rely on it. Vetox's answer sits inside its 32 moderation commands: every warning is attached to the member, capped at 100 per member and 1,000 warned members per server — identical whether the server pays or not — and readable per member in one command rather than reconstructed from a channel search. **Moderation Tools** is the companion surface: it lists every punishment currently in force, active bans, active mutes, unexpired temporary roles, and lets any staff member with access lift or shorten one without needing to remember who issued it. **Logging** covers the event side with 148 types across 14 categories, free on every tier; the one part that costs anything is resolving which staff member performed the action, which requires Basic ($4.99/month) and is worth paying for at this size specifically, because "who did this" is a question a thousand-member team asks constantly and a ten-member team almost never has to. ## Split the team by function, not by seniority Most servers organise staff by rank: helper, moderator, admin. That structure creates a promotion ladder and not much else. Splitting by **function** works better at scale, because the jobs are genuinely different: - **Reactive** — handling reports and incidents as they arrive. - **Proactive** — reading channels, spotting problems before they are reported. - **Structural** — configuration, automod tuning, onboarding, channel layout. The third of those is invisible and is the one that gets dropped when the team is stretched, which is precisely why it needs an owner. Nobody schedules "review the automod false positives," so nobody does it. This three-way split is the coarse version; [a four-function model with a named adjudication tier](/blog/discord-staff-team-structure) is worth building once the team is past about ten people, because escalation needs somewhere to actually end. ## Automate the mechanical, never the judgement Automation should absorb the volume: spam, raid patterns, obvious slurs, link floods. Those are pattern matches and a machine is better at them, faster, and never tired at 3am. It should not absorb decisions about intent. Whether a heated argument is a disagreement or harassment is a judgement call, and a rule that automatically bans on a keyword will eventually ban someone quoting the keyword to report it. The right split is: **automod handles the mechanical, humans handle the contested, and everything automod does lands in a log a human reads.** If nobody reads the automod log, you do not know what your rules are actually doing. The pattern-matching side of that split is **Auto-Mod**: eight rule types — invites, external links, mass mentions, excessive caps, spoilers, repeated text, a word list and anti-spam — each scoped to specific channels and roles, each able to fire up to five actions from delete through timeout. All eight are free on every tier including Starter, so there is no tier decision blocking you from starting today. That still leaves the question of who is allowed to touch the mechanical layer once it exists — tuning a threshold is itself a decision, and not every moderator should be able to make it. **Access Control**, which requires Max ($7.99/month), narrows which of forty dashboard sections, grouped into eleven, a given role or person may open, enforced on every request rather than by hiding a sidebar link — so "this moderator tunes automod and nothing else" becomes a setting instead of a promise nobody checks. ## Prevent the burnout you are about to cause Moderator burnout is the most common failure mode above a thousand members, and it is a staffing design problem rather than a personal one — [what actually prevents it](/blog/discord-moderation-burnout) turns out to be structural, not motivational. Three things reduce it measurably. **Rotas**, so nobody is always on. **A clear escalation path**, so a moderator facing something genuinely nasty can hand it up rather than absorb it. And **a channel where staff can discuss a call before making it**, which turns an isolated decision into a shared one. A moderator who quits does not usually leave over one incident. They leave over the accumulated sense that it is always their problem. ## The order to do this in 1. Write the ladder. An afternoon. 2. Turn on comprehensive logging. An hour. 3. Assign the structural role to a named person. A conversation. 4. Split the team by function. A week of adjustment. 5. Add the rota once the team is larger than four. Doing these in the other order — hiring more moderators first — produces more people making inconsistent decisions faster, which is the problem you started with.