Compatibility
Minecraft: Java Edition
Platforms
Supported environments
Tags
Creators
Details
GriefWatch
Client-side grief monitoring for hypixel housing, particularly "freebuild" houses. GriefWatch watches for block breaks happening around you and flags the player most likely responsible, so you can react to griefing in busy build areas without staring at chat or players all day.
Spoiler
It's a monitoring aid, not an anti-cheat needed. Don't just go demoting players because 'the mod said so'.
How it works
Whenever a block turns to air within your loaded chunks, GriefWatch:
- Finds the closest other player within range
- Cross-checks whether that player played an arm-swing animation in the last couple of ticks
- Raises one of two alerts:
- Red alert (swing-matched): proximity and swing timing line up. Higher confidence.
- Yellow alert (silent): a break happened near a player but no swing matched. Lower confidence, wider net.
- Teleports you to the player who triggered a red alert and in the case of a yellow alert, it teleports you to the coordinates
- Logs the event with timestamp, coordinates, block type, player, distance, and match status Both alert types can run at the same time or independently, and each can trigger only on rapid "bursts" of breaks (configurable count within a time window) to cut down on noise from normal building. Features
- Dual alert system: independent red (swing-matched) and yellow (silent/proximity) alerts, each with its own radius and burst thresholds
- Beacon beams: exact vanilla beacon beams render at alert locations with configurable colors per alert type, an auto-expire duration, and an optional single-beam mode that keeps only the most recent beam visible
- Alert sounds: separate, toggleable sounds for red and yellow alerts. Pick any sound by registry id, choose from numbered presets, or preview with a test command
- Whitelist: trusted builders can be exempted from red alerts without shrinking your detection range
- /dem keybind: sends /dem <player> for whoever generated the most red alerts within a configurable recent window
- Tab-list teleport cycling: keybinds to step forward/backward through the server tab list running /tp on each player, plus a "teleport to last cycled player" key
Limitations:
Entity render distance and why silent alerts exist:
GriefWatch can only positively identify a suspect (a red alert) when the responsible player's entity is loaded on your client, which means they have to be within your entity render distance. Beyond that distance the server stops sending you that player's entity and swing-animation packets, so there's no one for the mod to match the break against.
When a block break happens outside entity render distance, the break itself is still visible (it's a world/chunk update, which travels farther than entities), but the player who caused it is not. In that situation GriefWatch can't attribute the break to anyone, so it raises a yellow (silent) alert with the suspect logged as "unknown" instead of a red alert.
This gap is the main reason silent alerts were created. Servers frequently cut entity range well below chunk/block-update range, so relying only on swing-matched red alerts would miss griefing that happens just past your entity view. Silent alerts fill that blind spot: they catch break activity in the wider area even when no player entity is close enough to identify, trading certainty about "who" for coverage of "where."
Whitelist:
Whitelisting a player suppresses their alerts by checking whether a whitelisted player is standing near the broken block. But that check only looks at player entities your client actually has loaded, meaning players within your entity render distance. If a whitelisted player is beyond that distance, their entity isn't present on your client, so the mod has no one to recognize as whitelisted near the break.
The practical effect: a whitelisted builder working just past your entity view still triggers yellow alerts, because from the client's perspective the break came from "nobody visible." The block update reaches you, but the trusted player who caused it does not, so the whitelist has nothing to match against and can't suppress the alert.
This is the same underlying gap as the entity-render-distance limitation above. Whitelisting reliably prevents red alerts (which already require a visible, swing-matched player) and prevents yellow alerts only while the whitelisted player stays within your entity render distance. Once they're out of range, neither the identification nor the whitelist suppression can function, and you may see "unknown" yellow alerts from their legitimate building

