Spectating a Suspected Cheater: Staff Procedure

How should staff spectate a suspected cheater?

Spectate only after an alert or report gives a specific reason to look. Start a timed note before you join, watch one behavior at a time, and log each observation with a timestamp. Do not chat with the player, change their gamemode, or teleport them without a second staff member present. End the session with a written summary, even if you saw nothing.

What should you check before you spectate?

Preparation prevents most bad sessions. Complete these steps before you join the player's session:

• Open the alert or report and write the single behavior you are checking, such as reach on one specific combat exchange.
• Confirm you are not the player's opponent or in their party, so you do not judge a fight you took part in.
• Check the player's recent alerts and the server version, so you know whether a known false positive is possible.
• Tell a second staff member which player you are spectating and how long the session should last.

How do you watch and log during the session?

Watch the behavior from the angle the alert describes. Movement alerts need a view of the player's path. Combat alerts need the target and the timing of each hit. Write what you see in a timestamped log, and keep what you saw separate from what you think it means.

If the behavior does not appear inside the expected window, record that too. An empty session is useful evidence when it is written down.

What do you do after the session?

Write a summary within the hour, while the details are still fresh. Attach the alert IDs, the log, and any screenshots or recordings your server rules allow. Mark the case as needs review, cleared, or ready for punishment.

Only the senior reviewer sets the last status. The second staff member signs the log, so the record shows who watched and who decided.

Store the summary where the senior reviewer can find it within a day. A summary that sits in a private message is hard to audit later, and a missing summary is the first thing a dispute will ask about.

What mistakes should staff avoid?

Most spectate mistakes come from pressure to get a result, not from bad intent. Watch for these:

• Joining the fight or the player's base to get a better view.
• Treating a lag spike as a cheat signal without checking ping and TPS first.
• Relying on memory instead of a timestamped log.
• Ending a session because you feel sure, without writing down what did not happen.
• Discussing the player in public channels before the case has a status.

What if the player notices you?

Stop if your presence changes how the player plays, since the rest of the session is no longer useful evidence. Log that you ended early, the time, and the reason. Do not explain the investigation in chat, and do not promise an outcome. Any follow-up goes through the normal case process.

Two staff members should not spectate the same player at once unless the case lead asks for it. A second observer can change how the player behaves, and two overlapping logs are harder to read. If a second view is needed, schedule it as a separate session with its own log entry and its own time window.

If the player leaves the server during the session, keep the timer running while you wait for them to return, and log the time you lost. A gap in the log is normal, but an unlogged gap is not.

What we have not verified

This procedure is process guidance. We have not measured how much spectating improves decisions compared with alert review alone. Check your server's spectator tooling and its permission rules before you give staff access. Test the spectate command on a staging server to confirm it does not change anything the player can see.

For lag-related steps, the latency diagnostics page at /docs/staff/latency-diagnostics describes the FairPlay side of that check.