BlazeBans/Start here

Best practices

How to run BlazeBans so that punishments stay consistent, defensible, and easy to review six months later. Everything here is a default worth adopting, not a rule.

Use /punish rather than choosing a punishment yourself

This is the single most useful habit to build in a staff team.

minecraft
/punish Steve Cheating

Instead of a moderator deciding whether this is a warning, a mute, or a ban, and for how long, /punish reads the player's history and applies the step your rules say comes next.

First offence warns. Second mutes. Third bans for thirty days. Fourth is permanent. Whatever you configured, applied the same way by everyone, every time.

Compare that to the alternative:

minecraft
/ban Steve 30d Cheating

That works, and it puts the decision in the hands of whoever happens to be online. One moderator gives seven days, another gives thirty, a third goes straight to permanent. Six months later the history is a record of who was on duty rather than what the player did.

What it gives you

Correct escalation without anyone checking. The moderator does not have to open /history, count previous offences, and work out which rung the player is on. BlazeBans does that.

One decision, made once. The hard question, "what should cheating cost the third time", gets answered when you write the ladder, calmly, by whoever sets policy. Not at 2am by whoever caught them.

Less for staff to learn. New moderators need one command and a list of offence names, rather than command syntax, duration formats, and your escalation policy.

Consistency you can point at. When a player appeals claiming they were treated more harshly than someone else, you can show that the same ladder applied to both.

How the step is chosen

BlazeBans counts how many of that ladder's steps the player has already received, matching on punishment type and stored reason, and applies the one at that position. Past the last step it stays on the last step, so a permanent ban does not roll over into nothing.

That matching is why every step in a ladder needs a distinct reason:

yaml
ladders:
  Cheating:
    - type: BAN
      duration: 30d
      reason: Cheating (1st Offense)
    - type: BAN
      duration: 60d
      reason: Cheating (2nd Offense)
    - type: BAN
      duration: permanent
      reason: Cheating (3rd Offense)

Two steps both reading Cheating would count as the same offence and the ladder would never advance. The shipped ladders number their reasons for exactly this reason.

Before it is useful

/punish is only as good as your ladders. Configure them first, in Templates and ladders or through /blazebans editor, and cover the offences your staff actually deal with.

Grant blazebans.command.punish to everyone who moderates. Duration limits, staff hierarchy, and exemptions all still apply, so a junior moderator cannot use it to exceed their tier.

Serious steps ask for confirmation before they are applied, so an escalation to a permanent ban is never a surprise.

When to use a direct command instead

/punish is the default, not the only tool.

  • Something not in a ladder. A one-off situation your rules never anticipated.
  • Overriding the ladder deliberately. Something severe enough to skip straight to a permanent ban. Do it consciously and note why in the reason.
  • Kicks. Usually a nudge rather than a punishment, and a ladder step is heavier than the situation.

/punish also accepts a plain template ID, not just a ladder. That applies that template once, with no escalation, which is a tidy way to keep staff using a single command for everything.

Name the system behind an automated punishment

If another plugin punishes through BlazeBans, an anticheat or a chat filter for example, have it pass --punisher so the record says which system did it.

minecraft
/ban Steve 30d Cheating --punisher Anti-cheat
/punish Steve Cheating --punisher Anti-cheat

Without it, every automated punishment is recorded as CONSOLE. That is technically true and useless in practice: six months later nobody can tell an anticheat ban from a chat filter mute from a web panel action from something an administrator typed at the server console at 3am.

With it, the record carries the system's name everywhere a staff name appears: in /history, in /staffhistory, in the Discord post, and on staff profiles.

What that gets you

Readable history. /history Steve showing Anti-cheat next to a ban tells a moderator reviewing an appeal exactly what kind of evidence to look for.

Reviewable automation. /staffhistory Anti-cheat gives you every punishment that system has issued. If it is producing false positives, that is where you see the pattern, and its reversal rate on /blazebans staffprofile Anti-cheat is a real measure of how well it is tuned.

Honest staff metrics. Automated punishments no longer pile up under CONSOLE alongside genuine administrator actions, so your moderators' own numbers mean something.

A rollback that works. /staffrollback Anti-cheat 2h undoes a misbehaving detector's last two hours without touching anything your humans did. That is very hard to do afterwards if everything was logged as console.

Using it

Combine it with /punish where you can, so automated punishments escalate on the same ladders as manual ones:

minecraft
/punish Steve Cheating --punisher Anti-cheat

An anticheat that bans on first detection, while your ladder says a first offence is a warning, is applying a different policy from your staff. Routing it through /punish keeps one policy.

Pick a name per system and keep it stable, since it is what you will search on later. Anti-cheat, Chat-Filter, Appeals-Panel, and Discord-Bot are all clearer than CONSOLE.

Multi-word names work. The flag captures everything up to the next flag or the end of the line, so put it last or before another -- flag:

minecraft
/ban Steve 30d Cheating --punisher Chat Filter --silent

Full flag reference in Durations and flags.

Make the right thing the easy thing

Withhold blazebans.reason.custom. Staff can then only use template and ladder IDs, and free text is refused. Your history becomes searchable because Cheating is always spelled the same way.

Give newer staff the punish GUI. /punishgui <player> is point and click, offers only your templates, and confirms before it acts. Someone trusted enough to moderate is not always someone who will remember flag syntax mid-incident.

Set duration limits per rank. Without them, anyone holding blazebans.command.ban can issue a permanent ban. A permanent ban should be a decision someone senior makes deliberately.

Set staff weights. Stop staff punishing each other by accident, and stop a compromised junior account touching senior ones.

Look before you act

minecraft
/blazebans profile Steve

One screen showing their record, active punishments, linked accounts, and attached evidence. Thirty seconds here catches the cases that matter: the fourth account on an address you banned last week, or a player already muted for the same thing.

Build the habit of opening the profile first. It is also the right place to notice that a "first offence" is nothing of the sort.

Attach evidence

minecraft
/punish Steve Cheating --proof https://your-host.example/clip

A punishment with a clip on it survives an appeal argument. One without it comes down to whose memory the room trusts.

If evidence was not ready at the time, attach it afterwards:

minecraft
/proof add Steve https://your-host.example/clip

Link somewhere that keeps files. BlazeBans stores a URL and nothing else, so a screenshot in a channel that gets purged leaves a dead link on the record.

Once your team is in the habit, consider turning on proof requirements for the templates where evidence genuinely matters. Leave it off for the urgent ones.

Be careful with IP punishments

Reach for an account ban first. An IP ban can catch a sibling, a housemate, or an entire school, and the person it catches has no idea why.

Where evasion is the actual problem, /alts plus a manual ban is usually better than automation. It takes thirty seconds and catches nobody's brother. See Alts and IP tools and Ban evasion.

Use --silent deliberately

--silent suppresses the staff broadcast, the public announcement, and the Discord post. The record is still written and still visible in history.

Good uses: an ongoing investigation, or a punishment that would tip off someone you are still watching.

Bad use: routine punishments, because it is quieter. Your team should be able to see each other's work.

yaml
punishments:
  appeal-url: "https://yourserver.com/appeal"

The default is https://example.com/appeal. A banned player looking at that has nowhere to go, and this is the single most commonly forgotten setting in the plugin.

Review staff activity

minecraft
/blazebans staffprofile SomeModerator

Reversal rate is the number worth watching. Everyone gets one wrong occasionally. A moderator whose punishments are overturned far more often than their colleagues' is either misreading the rules or being handed the hard cases, and both are worth a conversation rather than a guess.

If something is badly wrong, /staffrollback reverses everything they issued in a window. Check /staffhistory first; there is no undo.

Correct, do not rewrite

/editpunishment exists to fix a typo or a wrong duration. It replaces the stored values rather than appending a note.

Do not use it to quietly change what someone was punished for after an argument. Revoke it and issue the right one, so the record shows what happened.

Revoking never deletes. A second ban reads differently when you can see the first was overturned on appeal, and that is a feature.

Back up the punishment database

Your history is the record of every moderation decision your team has made, and it is what you rely on when someone appeals a ban from a year ago.

SQLite is one file: copy it with the server stopped. MySQL, MariaDB, and PostgreSQL have their own dump tools, on a schedule.

Restore it once, on a test server, before you need it. A backup you have never restored is a hypothesis. See Database.

Write the rules down where staff can see them

BlazeBans enforces whatever you configure, and configuration is not documentation. A ladder that escalates to a permanent ban on the third offence only works if your moderators know that is the policy and can explain it to a player who asks.

Keep the template list and your public rules in agreement. When you change one, change the other.

A reasonable starting shape

For a server setting this up today:

  1. Configure ladders covering your common offences, with numbered reasons per step.
  2. Grant blazebans.command.punish and blazebans.command.punishgui to all staff.
  3. Withhold blazebans.reason.custom.
  4. Set duration limits and staff weights per rank.
  5. Set appeal-url.
  6. Point Discord webhooks at a private staff channel.
  7. Tell staff: open the profile, then run /punish, and attach proof.

That is most of the value in the plugin, and it takes an evening.