Minecraft anticheat guide

Responding to a Cheating Wave on a Minecraft Server

A numbered runbook for a sudden cheating wave on a Minecraft server: freeze changes, save evidence, triage alerts, punish in batches, and recover.

Updated 2026-11-07 · ~5 min read

minecraft cheating waveanticheat incident responseminecraft cheaters responseanticheat alert triageminecraft server cheater flood

How do you respond to a sudden cheating wave?

Slow down before you punish. Freeze configuration changes, save the logs and alerts before they rotate out, and sort alerts into confirmed cases and noise. Apply punishments in a batch you can explain later, then return automation to its planned level. Tell players only after you have a plan.

Step 1: Freeze changes and preserve evidence

Edits made mid-wave make it hard to know which setting caused which result. Stop changing configuration, then copy the current files and logs to a dated folder. FairPlay's player logs can include violations, chat, joins, and leaves, so limit who can open them.

Announce a configuration freeze to staff in your staff channel.
Copy config.yml, punishments.yml, and mitigations.yml to a dated backup folder.
Save the server log, the FairPlay player logs, and the alert channel history.
Restrict access to the evidence folder and redact chat, joins, and leaves before sharing anything outside staff.

Backup for a dated incident folder. Run from the server root and adjust the FairPlay folder name to match yours.

mkdir -p backups/incident-YYYY-MM-DD
cp plugins/<fairplay-folder>/config.yml plugins/<fairplay-folder>/punishments.yml plugins/<fairplay-folder>/mitigations.yml backups/incident-YYYY-MM-DD/

Step 2: Confirm staff can see the alerts

A wave can look quieter than it is when alerts are suppressed. FairPlay's alert guide lists four causes to check: recipient permission, the viewer's alert toggle, a per-viewer alertsTarget filter, and the alert cooldown. The cooldown defaults to 1,000 ms per the docs, so repeated alerts for one player and check are throttled on purpose.

Confirm each reviewer has fairplay.notify, or fairplay.notify.self for their own account.
Check each reviewer's alert toggle and alertsTarget filter.
Wait out the alert cooldown before judging a quiet feed.
Run one controlled test with a cooperating player and confirm the alert arrives.

Step 3: Triage the alerts in a fixed order

Group alerts by pattern before you read individual cases. The pattern tells you whether you are looking at players, a shared cause, or a delivery problem.

Alert patterns during a cheating wave and the next action.
Pattern	Likely meaning	Next action
Many alerts, one player, one check	One player under review	Treat as a single case and open the history
Many players, one check, same minutes	Possible shared cause such as a recent change or lag	Check recent plugin, version, and server-performance changes before punishing
Alerts stop after a restart or reload	Delivery or configuration issue	Check the console output and the reload guide before trusting the quiet
Alerts arrive but the webhook is silent	Delivery issue on the Discord side	Check the webhook guide. Reload does not confirm Discord delivery, per the docs
Alerts involve Bedrock players	Bedrock eligibility or Geyser behavior	Check the Bedrock setting and Geyser guidance before any punishment

Step 4: Punish in a controlled batch

Decide each case on its own evidence, and record the decision with a case ID. Automatic kick and ban are separate gates in mitigations.yml, both disabled by default. Enable a gate only if you have written down why, and only for the window you planned.

Create a case ID for each player you act on and link the evidence.
Choose a manual action or a configured mitigation for each case, not both by default.
Enable one automatic gate at a time, if at all, and note the time it was enabled.
Review the batch with a second staff member before you finish it.

Step 5: Return automation to its planned level

Once the wave is contained, restore the settings you wrote down before the incident. Reload only after backing up, then confirm the change took effect. Some settings need a restart, so check the startup output as well.

Restore the planned kick and ban state from your pre-incident record.
Run /fairplay reload with an account that holds fairplay.command.reload.
Run a controlled test with a cooperating tester to confirm alerts still arrive.
Write the final state and the time it was restored in the incident log.

Step 6: Tell players what you did

Keep the message factual. Say that you are reviewing reports, that you do not discuss individual cases in public, and where players can send evidence. Do not name suspects or promise a result you cannot control.

What have we not verified?

This runbook does not identify the cause of any specific wave, and it does not claim how quickly an anticheat detects cheating. It also does not set a review time limit. Set your own window with staff and record it.

FAQ

Should we ban everyone flagged during the wave?

No. Treat alerts as signals and review each case on its evidence. Automatic kick and ban are separate gates that default to disabled, so a flagged player is not a banned player unless you enabled that gate.

Will /fairplay reload fix a quiet alert feed?

It can refresh the configuration, but it does not confirm that Discord webhook messages were delivered. Check the webhook setup separately and test one message.

How long should the review take?

This guide does not set a duration. Agree on a window with your staff, write it into the incident log, and extend it only with a recorded reason.

What should we share with players?

Share that you are reviewing reports and where players can send evidence. Keep individual cases private, and do not post raw player logs, which can include chat and join history.