Ban Wave Batching and Reversal Plans for Minecraft Servers

What a ban wave is and when to use one

A ban wave groups confirmed cases into one scheduled batch. Staff review the whole list against a written checklist before anything is applied. Batching gives reviewers time to check evidence, spot shared patterns such as alt accounts, and stop a batch that looks wrong. Every wave needs an owner who can halt it before it runs.

Decide which cases qualify for a wave

Set entry rules in writing. Your policy decides the details, but a common set of gates looks like this:

• A staff member confirmed the case, not only an automated alert.
• An evidence bundle exists and is linked from the case record.
• No appeal or dispute is open for the same account.
• No staff investigation of the same account is active.
• The account is not on the wave allowlist, such as staff test accounts.

Build and freeze the wave list

Build the list once and freeze it. Changing the list after review means the reviewers approved something else. Use this order:

• Export the candidate cases for the wave window.
• Deduplicate by account UUID, not by username, since usernames change.
• Check linked and alt accounts and add them to the review, not the wave, until a human decides.
• Remove allowlisted and disputed accounts and log each removal with a reason.
• Record the final count and a hash or copy of the list, then freeze it.

Set gates and stop conditions

Each gate needs a named owner and a clear stop condition. The table shows the structure. Fill in the owners and thresholds that match your staff size.

Write the reversal plan before the wave runs

Reversal planning is the part most teams skip. Before the wave runs, write down how each action can be undone, who can do it, and how long it takes. Test the reversal command on a staging account first, using your ban plugin's own documented command. Do not rely on memory during an incident.

Keep one reversal record per wave:

wave_id: WAVE-<YYYY-MM-DD>-<n>
accounts_in_wave: <count>
list_hash: <sha256 of frozen list>
reversal_owner: <name>
reversal_method: <your ban plugin's unban procedure, verified in staging>
reversal_tested_on: <staging server and date>
stop_contact: <channel for halting the wave>

Decide who can halt a wave

The halt authority should be a named role with no conflict in the case. The person who built the list should not be the only person who can stop it. Write the halt step in the wave record, including the channel to use and the expected response time from the owner. If the owner is unreachable, the wave does not run.

A halt is not a failure. Log it with the reason, the number of accounts affected, and what changed. Halted waves are often the most useful records in the review because they show which gate caught a problem.

Watch the first 24 hours after a wave

Track appeals, reversal requests, and new reports that name a banned account. A spike in any of them after a wave is a signal to pause and review the list, even if each individual appeal looks weak. Log the time you checked and what you saw, so the review has a record.

Worked example of wave arithmetic

Use PLACEHOLDER inputs to check the list count. Suppose [PLACEHOLDER: 40] candidate cases pass the entry gates, [PLACEHOLDER: 3] accounts are removed as allowlisted, and [PLACEHOLDER: 2] are removed because an appeal opened. The frozen list then holds [PLACEHOLDER: 35] accounts. Write all four numbers into the reversal record, so a reviewer can recount the list later and get the same total.

Run one wave end to end

A wave is easier to audit when every step has a timestamp and a name. Follow this order and record each step in the wave record:

• Select the window and export candidates, then record the export time.
• Apply the entry gates and log every removal with its reason.
• Run the alt-account and appeal checks, and send anything unclear to review.
• Freeze the list, record its hash, and get the final sign-off in writing.
• Apply the wave in the agreed time slot, with the halt contact online.
• Run the reversal test plan only if a reversal is needed, and log its result.

Pitfalls in ban waves

The biggest risk is editing the list after sign-off because a case looks obvious. Obvious cases still need the frozen list and a new sign-off. Another risk is letting alt-account links decide a ban on their own. Shared IP or device data supports a review, but it does not replace the evidence bundle for each account.

Teams also forget that a wave changes the appeal queue. Expect a short rise in appeals after each wave, and staff the queue for it before the wave runs, not after.

What we have not verified

This page does not give a recommended wave size or interval, because those depend on your staff capacity and player count. We have not measured how often waves produce reversals on any server. Treat the gates above as a starting structure to adapt, not as proven settings.