A modded Minecraft server, in production
a read-only panel, a measurement journal and a four-fix mod

A supervision panel whose collector is read-only as a property of the code, not an intention: three RCON commands as compile-time constants, an AST test that fails if anything else is sent, a lint that refuses every write symbol, and a systemd sandbox with a read-only filesystem and an empty capability set. It samples the process, the logs, the player list and the tick rate, ships them through a WireGuard tunnel to a worker that rolls them up into PostgreSQL, behind an API with hierarchical roles and a React front end. The collector is deliberately outside the deployment pipeline: nothing automatic ships next to the game server.

A measurement journal: five-minute Spark profiles read by a small tool that decodes the undocumented format, a local bench built from a real backup with ten fake players and a warm JVM, one change at a time, negative results written down. Then a NeoForge mod of four mixins for the four bottlenecks the profiles named: a guard on storage controllers, a binary slot search instead of a linear one, a recipe cache, and a save writer that compresses in memory, writes once, syncs once and replaces atomically. Tick median 120 → 45 ms at four players, watchdog crashes 16 in two days → none, player-file writes 700 → 8 ms, join freezes 6.7 s → 0, auto-save stalls 35 → 6 minutes a day.

That the first version of the guard cut every player off their chests for eleven minutes, because another mod read the controller exactly like the one I wanted to block. So before forbidding a capability, enumerate its legitimate uses, and log every refusal. That a fix worth 14 ms on the bench ejected a player in production. That a reconstructed metric can invert four conclusions, and a profile percentage is not a cost. And that lightening the cluster next door changed nothing at all: hosting contention was not the bottleneck, however much it looked like one.