What to log on a game server, and what not to

Most servers log either far too much or almost nothing, and both produce the same outcome: when something goes wrong, the answer is not findable.

The useful position is narrow and specific. Log the things that let you reconstruct a decision after the fact, and nothing else.

The four things worth logging

Administrative actions. Every ban, kick, mute, permission change and console command, with who did it and when. This is the category that resolves disputes between staff, and it is the one most often missing because the built-in logging is inadequate and nobody replaced it.

Ownership changes. On any server where players own things (bases, vehicles, inventory, money), a record of what moved and when. Without it, "he stole my stuff" is unanswerable, and unanswerable disputes are how a moderation team loses its authority.

Connections. Who joined, when, from where. Short retention is fine. This is what turns "somebody griefed spawn last night" into a list of candidates.

Errors, once. The first occurrence of anything unusual. Not the four hundred that follow it.

The three things not to log

Chat, by default. It is the largest volume, the most sensitive, and the least useful. If you need it for moderation, log it with a short retention and say so publicly — a server recording conversations without telling anybody has a problem waiting for the day somebody notices.

Routine successful operations. "Player moved", "chunk saved", "tick completed". These fill the disk and bury the four categories above. A log where 99% of lines are normal is a log nobody reads, which means it is a log that does not work.

Anything you would not want to hand to somebody. Logs get leaked, subpoenaed, and read by whoever inherits the server. IP addresses and identifiers are frequently necessary; anything beyond that should have a reason.

Where the logs should live

Not only on the server, for the same reason backups should not. The logs you most want after an incident are the ones covering the incident, and an incident that takes the disk takes them with it.

Shipping them somewhere else is more infrastructure than most community servers want, and there is a cheap middle: include the log directory in the nightly copy that already leaves the machine. It costs almost nothing compressed and it means the record survives the event it was recording.

That also solves the other problem, which is that a moderator inheriting the server has no access to anything from before they arrived, and consistency with precedent is most of what makes enforcement defensible.

Retention is a policy, not a disk setting

Decide how long each category is kept and why.

Admin actions: long, because appeals arrive late and staff disputes arrive later. Ownership: long enough to resolve a dispute, which in practice is a few months. Connections: weeks. Chat, if kept at all: days.

Writing those four numbers down does two things. It makes the disk usage predictable, and it gives you an honest answer when somebody asks what you keep, which they will, eventually, and "I do not know" is the worst available answer.

The retention that has no policy is the one that fills the disk

This is the mechanical consequence and it is the most common way a long-running server dies. Logs grow, nothing prunes them, the disk fills, and the failure surfaces as a world save that could not complete.

The world is the thing that dies, not the logs. That is what makes the connection hard to see, and it is why a disk that is filling on a slope is worth alerting on long before it is worth worrying about.

Make the log quiet at idle

The single most valuable property a log can have is that it says nothing when everything is fine.

A server whose console is full of warnings at idle has trained its owner to ignore the console, which means the one line that matters will be missed. Resolving or silencing every recurring warning takes an afternoon once and pays back the first time something breaks at a bad hour — the same reason knowing what normal looks like beats knowing what an error looks like.

What not to keep, and why it is not caution

There is a category of data that is a liability rather than an asset, and servers accumulate it by default because logging everything is easier than deciding.

Full chat kept forever is the first. Useful for weeks, a problem at years: it is a record of private conversations held by people who did not think about it, and its main practical use after the first month is in arguments about things that were resolved long ago.

IP addresses beyond what you need them for are the second. They are worth keeping for a ban window and for diagnosing a connection problem. Keeping every address any player ever connected from, indefinitely, is a store of personal data with no operational purpose and a real cost if the box is ever compromised.

The third is anything a player asked you to delete. Obvious, and routinely missed, because the deletion happens in the database and not in the six months of logs that also contain it.

The discipline that works is a retention figure per category rather than a single one for everything: long for moderation decisions, medium for connection records, short for chat. Deciding it once is the whole job, and it is the same decision a backup retention policy makes about a different set of files.

Checking your own logging

Pick an incident from six months ago: a ban somebody argued about, a griefing report, a crash. Try to reconstruct it from your logs alone.

If you can, the logging is right. If you cannot, the gap you just found is the thing to fix, and it is almost always one of the four categories above rather than a volume problem. Most servers are logging a great deal and recording almost nothing, which is the expensive combination, and it is the same failure as a backup regime that runs perfectly and saves nothing useful.