Anticheat Alert Logging Policy and Retention Rules

Log enough to explain each alert later

An alert log should let a reviewer reconstruct why a check fired, what staff did, and which build produced the result. Keep the minimum set of fields that answers those questions, store them in one place, and set a retention window before the first alert is logged.

Notification thresholds and cooldowns are a separate setting from logging. The Discord webhook threshold article covers those values, so this article focuses on what you keep and for how long.

Choose the fields to record

Write a field list and keep it stable across releases. A change in field names makes older logs harder to compare.

Keep chat and location data out of routine logs

Routine alert logs do not need full chat history, exact location trails, or unrelated personal data. Include them only inside an investigation ticket that has a stated reason and a deletion date. A smaller log is easier to protect and easier to delete on schedule.

Set retention by data type

Use separate windows for different kinds of data. The numbers below are examples of an owner's policy, not a recommendation from any anticheat project. Choose windows that match your appeal process and your local data-protection obligations.

• Raw diagnostic output: keep for a short window, such as 7 to 14 days, then delete.
• Routine alert records: keep for a longer window, such as 30 to 90 days, so trends can be reviewed.
• Punishment decisions and appeal evidence: keep for as long as your appeal policy requires, with reviewer and date.
• Investigation exports: keep only until the case closes, unless a legal or policy requirement applies.
• Record the retention rule for each category in the staff handbook, not in memory.

Delete old logs on a schedule

Retention rules do nothing if no one applies them. Preview files that match the window first, then delete them after a reviewer confirms the list. Keep a note of the deletion date and the operator who ran it.

find /srv/mc/logs/anticheat -type f -name '*.log' -mtime +30 -print
# review the list, then rerun with -delete only after approval

Limit who can read the logs

Read access and punishment access are different permissions. Give reviewers read access to the alert records they need, and keep configuration and deletion rights with administrators. Build those groups in LuckPerms with the staff-group layout described in the staff bypass section above.

Redact before sharing evidence

When you share evidence outside the staff team, such as with a player, a developer, or a support channel, remove details the recipient does not need. Keep the check identifier, the time window, and the relevant measurement. Remove chat, addresses, and other players' identities unless the recipient has a specific need for them.

Store the redacted copy separately, and record who received it.

Treat webhook URLs as secrets

A webhook URL lets anyone post into the channel it belongs to. Keep it in the server configuration only, never in a public repository, screenshot, or support thread. Rotate the webhook if it appears in any public place.

Post a summary to the channel, not raw evidence. Use a private channel for staff alerts, and limit who can mention roles from automated messages. The Discord webhook threshold article explains the notification settings for FairPlay's webhook feature, and the setup article covers delivery troubleshooting.

Review thresholds against logged outcomes

A notification threshold decides what reaches the channel. It does not decide whether a player is punished. Review the outcomes of notified alerts every month. If most notified alerts are dismissed as false positives, raise the notification threshold or tune the check, and record the change.

What we have not verified

This article does not state how any anticheat formats or stores its logs, and it does not confirm that the examples in the retention table match any specific tool. Confirm the log location, format, and rotation settings on your own server before applying the policy.