What Violation Levels Mean in Minecraft Anticheats

What is a violation level?

A violation level, or VL, is a running score that a check adds to when it sees an event it considers suspicious. It counts flags over time, so a higher VL means more flags, not a confirmed cheat. Each anticheat defines its own scale, scoring, and expiry, so a VL of 5 in one product may not match a VL of 5 in another.

In FairPlay 4.0.5, the violation-expiration window and alert cooldown control how long a VL counts and how often staff see messages. Defaults include a 10,000 ms violation-expiration window and a 1,000 ms per-player/check alert cooldown. The cooldown limits repeated staff messages; violation accounting and mitigations continue on each fail.

How expiry, cooldown, and webhook thresholds differ

These settings are separate. Changing one does not change the others. The values below are FairPlay 4.0.5 sample defaults, so check your own files.

enabled: false
minimum-vl: 2.0
cooldown-ms: 2000

How a VL moves over time

A VL rises when a check fails and falls as violations expire. The amount added per fail depends on the check, so a single VL number does not mean the same thing across checks. Read the VL together with the check name and the time window it covers.

The alert cooldown adds a second layer. Staff messages are rate-limited per player and check, so a short log of messages does not mean few fails happened. Violation accounting continues on each fail, as the FairPlay docs describe.

What to look for in config and logs

Read the punishment and webhook settings before you read a VL trend. A high VL with no punishment configured is a different situation from a high VL that triggers an action.

• The violation-expiration window in your config, compared with the default of 10,000 ms.
• The per-player and per-check alert cooldown, compared with the default of 1,000 ms.
• The webhook minimum-vl and cooldown-ms values, and whether the webhook is enabled.
• Per-check overrides for punishments, if your setup uses them, and which checks they cover.
• Alert lines for one player across a session, to see whether the VL rose in steps or in a single burst.

A numbered procedure for setting thresholds

Change one value at a time, and record each change with the date and the reason.

• Run in alert-only mode and record the highest VL each player reaches over one week.
• Note which checks produce most of the high VL values, and whether those checks are the ones you expect.
• Review the top VL cases by hand, and label each as a likely false positive, a likely true positive, or unclear.
• Raise the webhook minimum only after the false positives in your review are understood.
• Compare the expiry window with how long a real session or fight lasts on your server.
• Retest on staging, then enable one punishment at a time and watch the next week of alerts.

Edge cases that change how a VL reads

A burst of lag can cause several fails in a short time, which raises the VL quickly. Players on high ping can also produce more fails in some checks. Read the time pattern before you treat a fast rise as intent.

A low VL on a rarely used check can still matter if it repeats across sessions. Watch for the same check and the same player over several days rather than a single peak.

Which VL pattern leads to which next step

Use the pattern you observe to choose the next step. A VL alone rarely decides the case.

What we have not verified

We have not tested which VL values best separate cheaters from legitimate players. Good thresholds depend on the check, the server, and the player base. Test changes on staging and review false positives before you enable punishments.