Minecraft anticheat guide
Quarterly Anticheat Review Checklist for Server Owners
A quarterly anticheat review checklist covering metrics, config changes, appeals, staff workload, version updates, and open risks, with a named owner for each.
What a quarterly review covers
A quarterly anticheat review checks whether your anticheat still matches how your server runs. It covers the numbers, the config history, the appeals, the staff load, and any version or dependency change. Each area gets one owner and one written decision. The review ends with a list of actions, not a list of opinions.
Pull the quarter's numbers
Run the same metric export for the whole quarter, using the formulas from your metric definitions. Compare against the previous quarter and against any earlier quarters you have. Do not change a formula during the review. If a formula is wrong, fix it, note the date, and mark the old numbers as recalculated.
Review every config change
Open the config change log for the quarter. For each change, check that it has a reason, a staging result, and a date. Changes without staging results go to the top of the action list. Confirm that the live config matches the logged state.
Review appeals and reversals
Read the reason codes for every overturned appeal and every reversed ban wave. Group them by cause: a check threshold, a version update, a reviewer error, or a lag event. Only threshold causes should lead to a threshold change. Reviewer errors lead to a training or procedure change.
Check staff workload and backlog
A growing backlog can make enforcement slower than your policy says. Compare the backlog age at the end of the quarter with the quarter before. If reviewers spend more time on noise than on confirmed cases, the fix is usually a tuning or alert-routing change, not more reviewers.
Compare this quarter with the playbook
Your review should start from the playbook you wrote before, not from memory. Open the last review's register and check every open row first. Rows that stayed open for two quarters need either a decision or a written reason to keep them open. Rows that closed should show the evidence that closed them.
Carry forward only the metrics and checks that still answer a live question. If a metric no longer drives a decision, retire it and say so in the register. A shorter review that gets decisions made is more useful than a longer one that collects numbers nobody reads.
Check versions, dependencies, and hosting
List every server version, anticheat version, and dependency change in the quarter. For each one, confirm that a staging test was recorded. Confirm that your hosting limits still fit the server's load, and note any change in player count or game mode that could shift the numbers.
Record decisions with owners
Each finding becomes a row in one table. Keep the rows short and assign an owner to every row. A row without an owner stays open until someone takes it:
| Area | Question | Owner | Decision and date |
|---|---|---|---|
| Metrics | Did any formula change this quarter? | [PLACEHOLDER: analyst] | [PLACEHOLDER] |
| Config | Does every change have staging evidence? | [PLACEHOLDER: config owner] | [PLACEHOLDER] |
| Appeals | Which overturn causes repeat? | [PLACEHOLDER: appeals lead] | [PLACEHOLDER] |
| Staff load | Is the backlog age within policy? | [PLACEHOLDER: lead reviewer] | [PLACEHOLDER] |
| Versions | Was every update staged first? | [PLACEHOLDER: server owner] | [PLACEHOLDER] |
Worked example of the config evidence check
Suppose the quarter logged [PLACEHOLDER: 6] config changes, and [PLACEHOLDER: 4] of them have a staging result attached. The remaining [PLACEHOLDER: 2] changes go to the top of the action list, each with an owner and a deadline. The counts are placeholders. The point of the check is that every change can be matched to its evidence, not that any particular count is good.
Step-by-step quarterly procedure
Run the review in this order, and timebox each step so the meeting finishes:
Pitfalls in quarterly reviews
The review often turns into a status meeting where nobody changes anything. Require a decision for every row, even if the decision is to keep watching. Another pitfall is changing thresholds at the review itself. Threshold changes need staging evidence first, so schedule them as a separate action with its own record.
Some teams also skip the review in a busy quarter. A skipped review hides the slow drift that the review exists to catch, so keep it even when the agenda is short.
What we have not verified
This checklist does not set targets for any metric, and it does not decide when to change a threshold. We have not tested it on servers of different sizes. Adjust the cadence and the areas to your network before you rely on it.
FAQ
How long should the quarterly review take?
Time the first review and use that as the planning figure for the next one. A review that runs far longer than planned usually means the metric export or the config log needs work.
Who should attend the review?
Include the server owner or a delegate with decision authority, the lead reviewer, and whoever handles appeals. Add the config owner if config changes are on the agenda.
What if this quarter's numbers look worse than last quarter's?
Check for a rule change, a version update, or a shift in player population before you touch thresholds. A worse number with a clear external cause calls for a note in the register, not an immediate tuning change.
What if we have no staging environment?
Then the review cannot confirm that changes were tested. Record the gap as an open risk with an owner, and require a written rollback plan for every live change until a staging setup exists.