Reviewing a Minecraft Cheating Case: A Checklist for Staff

Banning a cheater is easy. Banning the right person, for the right reason, in a way that survives an appeal, takes a process. Use this checklist before you apply a sanction and when you review one.

Before the sanction

1. What triggered the case? Alerts, reports, or staff observation. Write it down.
2. Is there more than one independent signal? A single report or a single alert is a lead, not proof.
3. Was the check done with the player's knowledge? Explain what you are checking and why.
4. Is the evidence from the player's own machine or from observed behavior? Hard evidence beats impressions.
5. Could there be an innocent explanation? Lag, a legitimate mod, a shared computer. Rule these out.

At the decision

• Apply the sanction your rules define for that proof level, no more and no less.
• Have a second staff member review serious cases, such as permanent bans.
• Treat automated reports as a decision aid. False positives are possible, so a human confirms the finding.

What to record

• Date, staff member, and the reason the case was opened.
• The evidence reviewed: screenshots, the scan report, relevant logs.
• The decision and the rule it was based on.

Handling appeals

1. Reply within a stated time, even if only to confirm receipt.
2. Have someone other than the original moderator review it when possible.
3. Look at the saved evidence first, then the player's explanation.
4. Answer with the outcome and the reason. Do not share details that would help a cheater avoid the next check.

Why this matters

Players accept strict enforcement when it is consistent and explained. A written standard, solid evidence, and a clear appeal path protect your community and your staff. For finding that evidence faster, see our screenshare guide and our overview of how to detect cheaters.