Some behaviour a cheat produces can also happen innocently: a laggy connection can look like teleporting, and a scripted stunt can look like a boosted vehicle. Banning on the first sign of these would punish ordinary players.
A strike is a recorded warning for those cases. It disconnects nobody, but strikes add up, and enough in one session results in a ban.
This page covers severity levels, when strikes lead to a ban, and how to issue or exempt them.
Severity
Every strike is low, medium or high, depending on how strongly it indicates cheating. Severity sets how many strikes lead to a ban and how much the player’s risk score rises.
| Severity | Strikes needed for a ban | Risk added |
|---|---|---|
| Low | 5 | +2 |
| Medium | 3 | +5 |
| High | 2 | +10 |
Strikes reset when a player leaves
The count that leads to a ban is per session and returns to zero on disconnect.
The count exists to catch someone cheating right now. A player who triggered one detection months ago should not be one step from a ban today.
The strikes themselves are kept permanently. Review them on the Strikes page, where you can also see a player’s full history and mark old entries resolved.
Risk score
Separately from the session count, every strike raises the player’s risk score, which runs from 0 to 100 and does not decrease.
Risk score punishes nobody by itself. It exists so you can sort the Players page by risk and see which accounts have triggered the most detections over time.
Reaching the limit
When a player reaches the strike limit for any severity, Asphyxia bans them automatically. The reason is Maximum Strikes Reached, and the details record which severity caused it.
From there it behaves like any other ban: it appears in your ban list, on the dashboard, and in your Discord webhook.
Issuing a strike yourself
From the server console:
asphyxia strike 12 high Suspected aimbotFrom another resource:
exports.asphyxia:strikePlayer(source, "Suspicious behaviour", "Details here", 2)Exempting a player
If a detection repeatedly strikes someone it should not — a developer testing something, or one of your own scripted events — whitelist that player rather than disabling the detection for everyone. See Whitelisting.