Minecraft anticheat guide
Anticheat Metrics Server Owners Can Track
Which anticheat metrics to track, how to calculate each one from your own logs, and how to read trends before you change enforcement settings.
Which anticheat metrics matter most
Track alert volume per check, the share of alerts staff confirm, the share of punishments overturned on appeal, and the median time from alert to decision. Calculate each one from your own logs over a fixed window. Compare your server's trend with its own past, not with another server's numbers, and treat every value as a local measurement.
Define each metric before you collect it
A metric without a written formula drifts over time. Write the formula, the source fields, and the window before the first export. These five cover most owner questions:
Pick a window and keep it fixed
Use the same window length for every report, such as one week or one month, and state the start and end dates on each chart. Changing the window between reports makes two numbers look different even when nothing changed. Choose the length from your traffic: a small server may need a longer window before a rate means anything.
Record every configuration change, version update, and rule change with a date. A sudden shift in alert volume often lines up with one of these events, not with a change in cheating behavior.
Example layout with placeholder values
The values below are placeholders for layout only. They are not measurements from any server or any anticheat. Replace each one with your own calculated value.
| Metric | Source fields | Example value (PLACEHOLDER) | Review cadence |
|---|---|---|---|
| Alerts per 1,000 sessions | alert count, session count | [PLACEHOLDER] | Weekly |
| Confirmation rate | alert id, staff verdict | [PLACEHOLDER] | Weekly |
| Appeal overturn rate | punishment id, appeal outcome | [PLACEHOLDER] | Monthly |
| Median time to decision | alert time, decision time | [PLACEHOLDER] | Weekly |
| Alerts per check | check name, alert id | [PLACEHOLDER] | Monthly |
Separate signal from repeated alerts
One player can trigger the same check dozens of times in a session. If you count raw alerts, a single player can make the numbers jump. Count unique players per check per window as a second series, and keep raw alert counts for workload planning.
Use a short cooldown or deduplication step when you export the data. Document it in the same place as the formulas, so a later reader knows which numbers were deduplicated.
Work one metric end to end
Take a weekly window with PLACEHOLDER inputs: [PLACEHOLDER: 1,000] alerts and [PLACEHOLDER: 50,000] player sessions. Alerts per 1,000 sessions is [PLACEHOLDER: 1,000] / ([PLACEHOLDER: 50,000] / 1,000), which equals [PLACEHOLDER: 20]. These inputs show the arithmetic only. They are not data from any server, and the result should never be copied into a report.
Pitfalls that distort anticheat metrics
The most common error is mixing window lengths, such as a seven-day alert count against a thirty-day session count. The second most common is counting usernames instead of account UUIDs, which inflates unique-player counts when a player changes name. Dividing by sessions from a proxy while counting alerts from one backend server also produces a rate that looks sound but means nothing.
What these metrics cannot tell you
Alert and decision metrics describe what your anticheat flagged and what staff did next. They do not describe what the anticheat missed. A falling alert count can mean less cheating, weaker detection, or a changed player base. Only known-positive tests run in staging can show missed detections, and this page does not provide detection rates.
We have not verified how these formulas behave on every anticheat's log format. Check each field name against your own log output before you trust a chart.
FAQ
Can these metrics show how accurate my anticheat is?
No. They measure alerts, staff decisions, and appeals. Accuracy needs ground truth, such as test accounts that you know are cheating or known-clean accounts run through staging. Use those results alongside these metrics.
Why use a median for decision time instead of an average?
One stalled case can pull an average far from typical handling time. Report the median and also the 90th percentile, so you can see both the usual case and the slow tail.
If alert volume drops after tuning, did the anticheat get better?
Not necessarily. A drop with an unchanged confirmation rate could mean less cheating, or it could mean the check now misses cases. Run your staging test set before you call the tuning a success.
Which metric should we start with if we have no history yet?
Start with alert volume per check and the review backlog. Both come from fields you can check in your own logs, and neither needs ground truth. Add the confirmation rate once staff record verdicts consistently for a full window.