Minecraft anticheat guide

TriggerBot in Minecraft: What It Is and How Servers Respond

What a Minecraft TriggerBot does, how it differs from KillAura and AimBot, and the staff steps for reviewing suspected TriggerBot attacks on a server.

Updated 2026-11-07 · ~5 min read

minecraft triggerbottriggerbot cheatminecraft triggerbot detectionKillAura vs TriggerBotminecraft combat cheats

What is a TriggerBot in Minecraft?

A TriggerBot is a modified client that attacks an entity automatically when the crosshair is on that entity. The player still aims by hand. The cheat removes the timing error of clicking at the right moment, so attacks land at exact points in the fight.

Servers cannot read the client's software directly. They see attack packets, rotation updates, and the outcome of each hit, so review focuses on the timing of those packets against the player's aim.

Because the cheat changes timing rather than aim, a review that only checks rotation can miss it. Compare attack timing with the crosshair state as well.

How TriggerBot differs from KillAura and AimBot

The three cheats share a goal of landing hits, but they differ in who aims and who decides when to attack. Mixing them up leads to the wrong evidence in a review.

TriggerBot compared with other combat cheat types.
Cheat	Who aims	Who decides the attack	Server-side signal to review
TriggerBot	The player	The client, when the crosshair is on a target	Attacks timed to the moment a target enters the crosshair
KillAura	The client, or the player	The client, within a range around the player	Hits on targets the player was not facing
AimBot	The client	The player or the client	Rotation snaps or steady locks toward a target
AutoClicker	The player	The client, on a click timer	Click intervals that are too regular

What signals should staff review for TriggerBot?

No single signal settles a TriggerBot case. A review looks for several things at once, and it compares them against the same player's other fights and against normal input from legitimate players in the same server mode. A signal that appears in one fight is a prompt to look closer, not a finding.

Attacks that consistently follow the frame a target enters the crosshair, rather than a human reaction window.
Hits where the player's rotation was not pointing at the target at the moment of the attack packet.
Attack timing that stays regular across many fights, even when the players around them vary.
Hit outcomes that match the crosshair state and not the target's movement path.
Patterns that disappear when the player is on a stable connection, which suggests lag was part of the pattern.

How should servers respond to TriggerBot alerts?

Start with alerts and debug review, then add mitigation before automatic bans. Mitigation limits the damage from suspicious hits while staff gather more evidence. Use the steps below as a default order, then adjust it to your staff policy. Decide the mitigation policy before the first alert, not during a live fight.

Turn on alerts for the combat checks that cover aim and click timing, and let them run in observation first.
Review the flagged fight with the timeline from 2 to 5 seconds before each attack.
Check ping, teleport corrections, and other corrections that could explain the timing.
Enable mitigation for the flagged behavior, so suspicious hits do less damage while review continues.
Escalate to punishment only after several fights agree, and record each decision with its evidence.

What does the FairPlay reference say about TriggerBot?

The FairPlay check reference we reviewed does not name a TriggerBot check. Its aim and click families, such as AimBot and AutoClicker, are the closest documented areas. Read the current reference before you assume a check exists for TriggerBot in your version.

The reference also lists check families for KillAura and Hitbox. A TriggerBot review that touches those families should still be written as a TriggerBot review, with its own evidence. Confirm check names against the reference for your release, since names and families can change between versions.

What belongs in a TriggerBot case file

A case file should show the pattern, the context, and the decision in that order. Keep the alert, the fight timeline, the player's ping history, and the staff note together so an appeal can be read without rebuilding the review from memory. Note who reviewed each case and when, so the decision trail is clear.

Record the server version, the enabled checks, and the mitigation state at the time of each alert. A finding made under one configuration may not hold under another, so the version record is part of the evidence.

What we have not verified

This article makes no claim about detection accuracy, false positive rates, or how often any anticheat catches TriggerBot. It also does not test any specific client. Run your own staged fights on your server version before you set any threshold, and treat the signals above as review prompts rather than proof.

FAQ

Is a TriggerBot the same as KillAura?

No. A TriggerBot waits for the player to aim at a target, while KillAura chooses targets within a range on its own. The evidence is different, so review them with different signals.

Can one suspicious fight prove TriggerBot use?

No. Lag, unusual input devices, and fast reflexes can produce timing that looks automated. Compare several fights and the player's history before you enforce anything.

Should we ban players on a TriggerBot alert alone?

Treat the alert as a reason to review and, if needed, enable mitigation. Automatic punishment should wait until your staging tests and staff review support the decision.

Related sources and official pages

FairPlay check reference