The game loop

Every night is the same four movements repeated until sunrise. Learning the game is learning to run them faster, not learning more of them.

Watch

Logs scroll and the meters move. Most of what you see is normal: a fleet under load produces traffic lines, cron jobs start and finish, latency wobbles. The skill being trained here is noticing the line that does not fit — a request rate no client produces, a resident set that only ever grows, a temperature that has stopped coming back down.

Diagnose

The symptom is rarely the cause, and the game is built around that gap. A saturated CPU could be a flood arriving from outside, a process that has run away locally, or a machine that is throttling because it is too hot.

Diagnostic commands are free and instant — there is no cost to being sure. status gives the fleet at a glance, top names processes, netstat shows who is connecting, df shows disks, db_stat shows locks.

Act

The fix is a command. The syntax is gamified Unix: real command names, common flags accepted, and the names stay English in every language because a terminal is English. If you type something that does not exist you get bash: xyz: command not found, and if the game can guess what you meant it says so — did you mean: block_ip?

Confirm

Metrics recover, the machine returns to OK, and a resolution line appears in the log. That confirmation matters: an incident is resolved when the world says it is, not when you have typed something plausible. Some incidents accept more than one resolution, and a partial fix can close them at a worse cost.

The macro loop

Around that thirty-to-ninety-second cycle sits the shift itself: incidents are injected on a tempo that rises with the night, several can overlap, and the pressure compounds. See incidents at a glance for how that scheduling works.