Minecraft anticheat guide

Latency and Desync Terms for Minecraft Anticheat Admins

Plain definitions of latency, ping, transaction sync, provider modes, and snapshot settings, with the diagnostic command and config keys each term maps to.

Updated 2026-11-07 · ~5 min read

minecraft latency anticheatanticheat desync termsfairplay latency commandtransaction synchronization anticheatminecraft ping anticheat

What do latency and desync terms mean for anticheat admins?

Latency is the delay between the client and server, and desync is when the two sides disagree about player state. FairPlay exposes diagnostics and settings for both, but a diagnostic capture is not a ping test. The table defines each term and names the command or key where it appears.

Latency, transaction, and snapshot terms with where to find them.
Term	Plain definition	What you will see in output or config
Latency	The delay between a player's client and the server. It changes with network conditions.	Latency values in diagnostic output for one check.
Ping	A round-trip time reading. Use it as context for a fight, not as proof of anything.	A ping value shown in player or server status views.
Latency diagnostic	A bounded capture against one online player for 1 to 120 seconds.	The /fairplay latency <player> <seconds> command and its response.
BacktrackCombatSpikes	The diagnostic check the latency command depends on. If it is missing, the command cannot run.	A message that the diagnostic cannot run.
Transaction synchronization	Confirmation messages exchanged with the client, so the server can match its state to what the client has acknowledged.	The transaction.yml file and provider status messages.
AUTO mode	The default provider mode. It resolves to NATIVE, GRIM, or GRIM_UNAVAILABLE based on which plugin owns handling.	mode: AUTO in transaction.yml.
GRIM_UNAVAILABLE	A resolved state where the chosen provider cannot own synchronization, such as GRIM mode when Grim cannot take it.	A resolved value in status output. NATIVE with Grim present logs a warning.
Probe interval	The time between native probe runs. The documented default is 80 ms.	probe-interval-ms in transaction.yml.
Pending timeout	The wait limit for a pending confirmation. The documented default is 5,000 ms.	pending-timeout-ms in transaction.yml.
Pending size	The number of pending confirmations kept for each player. The documented default is 256.	pending-size in transaction.yml.
Virtual world snapshot	A server-side view of world state used by checks that read snapshots. Coverage is adjustable.	Coverage and capture values in snapshot.yml.
Subchunk radius	How far around a player the snapshot covers, horizontally and vertically. The documented default is one.	Horizontal and vertical radius values in snapshot.yml.
Inactive subchunk expiry	How long an inactive subchunk stays in the snapshot. The documented default is 15,000 ms.	An expiry value in snapshot.yml.
Capture jobs per tick	The cap on snapshot capture work per game tick. The documented default is 60.	A per-tick job limit in snapshot.yml.

How do you read a latency capture in practice?

Run the capture against one player who is online and cooperating, for a short and fixed duration. The command below uses the documented shape with placeholders. Replace the placeholders, and confirm the usage message on your server first.

Confirm the operator has fairplay.command.latency and the root fairplay.command permission.
Confirm the player resolves as online. The command rejects offline targets.
Pick a duration from 1 to 120 seconds that matches the question you are asking.
Read the response as diagnostic records for one check, then compare it with the same player's alerts.
Redact names and output, then record the server version and the sanitized response.

Documented command shape with placeholders.

/fairplay latency <player> <seconds>

Which latency and sync terms are easy to mix up?

These pairs look similar in staff chat but refer to different parts of the system. Check the table before you change a value or report a finding.

Commonly confused latency, transaction, and snapshot pairs.
Pair	The difference	Where to check
Latency vs ping	Latency describes delay in general. Ping is one round-trip reading that gives context only.	Diagnostic output versus status views.
Latency diagnostic vs ping test	The diagnostic captures records for one check. It is not a network benchmark.	The /fairplay latency response.
AUTO vs GRIM mode	AUTO picks a provider based on ownership. GRIM requires Grim to own synchronization or the result is GRIM_UNAVAILABLE.	mode in transaction.yml and status messages.
GRIM_UNAVAILABLE vs DISABLED	GRIM_UNAVAILABLE means a provider could not own synchronization. DISABLED means synchronization is off on purpose.	Resolved provider in status output versus the mode setting.
Probe interval vs pending timeout	The probe interval is the time between native probe runs. The pending timeout is the wait limit for one confirmation.	probe-interval-ms versus pending-timeout-ms.
Subchunk radius vs capture jobs per tick	The radius sets how much area the snapshot covers. The per-tick limit sets how fast capture work runs.	Radius values versus the per-tick job limit in snapshot.yml.

What are the documented transaction defaults?

The transaction group defaults to enabled with AUTO mode. The values below are the documented defaults for its native settings. Confirm the nesting in your generated transaction.yml before you edit.

Documented transaction.yml defaults. Confirm nesting in the generated file.

# transaction.yml, documented defaults
mode: AUTO
probe-interval-ms: 80
pending-timeout-ms: 5000
pending-size: 256

What we have not verified

This page gives no latency thresholds, no detection accuracy, and no performance numbers for snapshots or transactions. Probe and timeout values are documented defaults, and your server may need different ones. Test any change in staging first.

FAQ

Is the latency diagnostic a ping test?

No. The docs describe it as a capture of diagnostic records for one check. Do not use its output as a network benchmark.

What should I do when GRIM_UNAVAILABLE appears?

Check which plugin owns transaction handling and whether your mode matches it. Under GRIM mode, the docs say the result is GRIM_UNAVAILABLE when Grim cannot own synchronization.

Do snapshot defaults matter for every check?

No. Only checks that use snapshot state are affected by coverage. Confirm your target check uses snapshots before you change snapshot.yml.

Can I share latency output with a vendor?

Only after you redact player names and diagnostic output. Keep the server version and the exact sanitized response.

Why does the latency command refuse a player I can see online?

The docs require an online player that resolves correctly, a duration from 1 to 120 seconds, the right permission, and an available BacktrackCombatSpikes check. Check each one in turn before you retry.