Server logs worth keeping: what to keep and for how long

Keep everything at warning level or above, every start-up banner, every crash report in full, and every administrative action. Delete per-request access logs after a week or two, delete debug output the day the bug is closed, and stop writing anything that prints once per tick. That is the entire policy, and it fits in four lines because the hard part is not deciding what to keep - it is making the decision survive contact with a server that has a disk limit, no log server, and a habit of producing 500 MB a day of chatter nobody will ever read.

Logs are only useful if the interesting line is still present and findable. A server writing a gigabyte a day of routine output fails both tests at once: the disk fills, rotation deletes the oldest file, and the one warning from three days ago goes with it. Everything below is about arranging things so that does not happen.

What logs are actually for#

A log is a record you read backwards from the moment something broke. In practice it only ever has to answer four questions, and any line that does not help with one of them is decoration:

• What was running? Which version, which Java, which mods and plugins at which versions, which config file was read, which ports were bound.
• What changed, and when? A plugin updated, a config was edited, somebody restarted with different flags.
• What did the process say before it died? The last few hundred lines and the stack trace, in order, with timestamps.
• Who did what? Bans, kicks, permission grants, item spawns, world edits, deploys.

Notice that three of the four are about time. The value of a log is almost entirely in ordering and timestamps, not in the wording of the messages. A log with beautiful prose and no timestamp is close to useless; a log of terse machine output with accurate timestamps will tell you what happened. This is also why "the server was slow yesterday evening" is answerable and "the server has been slow lately" usually is not.

Keep these four things#

Everything at warning level and above, for as long as you can afford. Warnings are the cheap early version of the outage you get three weeks later. A repeating warning about a failed database connection, a deprecated config key, or a plugin that cannot find a dependency is the whole diagnosis, delivered free, days in advance.

The start-up output, in full. This is the single most under-valued block in any log file. It records the exact version of the server software, the Java or runtime version, the full list of mods or plugins that actually loaded with their version numbers, the world or database it opened, and the ports it bound. When somebody tells you nothing changed, the start-up banner from before and after is how you prove otherwise in thirty seconds. On a Minecraft server that is the block beginning Starting minecraft server version through to Done (12.481s)! For help, type "help". On a modded server it is the mod list. Keep it even when you throw the rest of the day away.

Crash reports, in full, including the ones you think you understand. A stack trace truncated to "the interesting bit" is a stack trace that has had the interesting bit removed. Minecraft writes them to crash-reports/crash-<date>-server.txt as well as to the console. A JVM that dies at the native level writes hs_err_pid<pid>.log in the working directory, which is the file that tells you it was the kernel's out-of-memory killer rather than your code. These files are small. There is no version of this where deleting them was the right call.

Administrative actions. Bans, kicks, permission changes, price edits, item grants, config deploys. These get disputed, and they get disputed weeks later, by someone with a screenshot. Keep them longer than everything else and keep them somewhere the person being investigated cannot edit.

Delete these, and stop writing some of them#

Per-request access logs older than a week or two. They answer traffic questions, which are real questions, but a fortnight covers every one you will actually ask, and they are usually the largest file on the disk by an order of magnitude.

Debug output left switched on after the debugging finished. This is the most common cause of a log directory that quietly ate the plan. Debug logging is a tool you pick up and put down, not a setting.

Anything printed once per tick. That last category is not logging, it is a performance problem that happens to write to a file. At 20 ticks per second, one line per tick is 1.7 million lines a day, and the write usually happens on the same thread as the simulation, so the cost lands inside your tick budget. If a plugin does this, the fix is the plugin's config, not a bigger disk. See why TPS drops and what to do for how to find which one it is.

Chat logs and IP addresses deserve a separate, uncomfortable paragraph. Both are personal data in most of the world, both are genuinely useful for moderation, and keeping either one forever converts a moderation tool into a liability you are storing on behalf of people who did not ask you to. Thirty to ninety days of chat is enough to settle any argument that is still worth settling. Recent versions of the vanilla Minecraft server added a log-ips toggle in server.properties for exactly this reason; check whether your version has it before assuming addresses are being written.

How long to keep what#

Retention is a budget, not a principle. Here is a split that works on a single server with a normal disk allocation:

The rule behind the table: keep a log for as long as somebody might reasonably come to you with a question about that period. For crashes that is forever, because the same crash comes back. For access logs it is about as long as the last invoice.

Rotation, compression and the disk you have#

Do the arithmetic once, because it is not intuitive. A typical log line is around 120 bytes. A server writing 50 lines a second - which is a fairly ordinary busy Minecraft or web server - produces about 6 KB/s, which is roughly 500 MB a day, or 15 GB a month. On a 15 GB plan that is the whole disk in thirty days, and the failure will not present itself as a logging problem. It presents as a world save that fails, a database write that errors, or a backup that will not complete.

Text logs compress by roughly ten to one, so compressing on rotation is close to a free 90 per cent. On Linux, logrotate is the standard tool and a config for an app that writes its own files looks like this:

/home/app/logs/*.log {    daily    rotate 14    compress    delaycompress    missingok    notifempty    copytruncate}

copytruncate copies the file and then empties the original in place, which is what you need for a process that holds the file open and has no way to be told to reopen it. It costs a tiny window where lines written during the copy are lost. The alternative, create plus a postrotate block that sends the process a signal to reopen its log, is cleaner when the software supports it. Most game servers do not, so copytruncate is usually the honest choice.

If the service runs under systemd and logs to stdout, the journal is already doing the rotation and the file on disk is not yours to manage. Cap it in /etc/systemd/journald.conf:

Storage=persistentSystemMaxUse=500MSystemMaxFileSize=50MMaxRetentionSec=1month

Game servers each do something slightly different, and one behaviour catches people out repeatedly. Minecraft and its forks rotate on start-up, not on a timer: the current file is logs/latest.log, and the previous one is compressed to logs/2026-09-20-1.log.gz when the server next starts. A server that runs for six weeks without a restart has a single latest.log that has been growing the whole time, and nothing will rotate it until the restart. That is one more small argument for the weekly restart in restart schedules that help.

Project Zomboid goes the other way and writes a new dated set of files into Logs/ on every start, split by kind: _DebugLog-server.txt, _chat.txt, _admin.txt, _user.txt, _pvp.txt, _map.txt, _item.txt. That is excellent for finding things and terrible for disk, because nothing ever cleans it up. Put a scheduled task on it or the folder will outlive the world.

Turning down the noise at the source#

Rotation manages the symptom. The real win is not writing the line at all.

On nginx, successful requests are almost always the noise and errors are almost always the signal. You can log only the interesting ones:

map $status $loggable {    ~^[23]  0;    default 1;}access_log /var/log/nginx/access.log combined if=$loggable;error_log  /var/log/nginx/error.log warn;

That keeps every 4xx and 5xx and drops the rest, which on a busy site is 95 per cent of the volume. Set error_log to warn and leave it there; debug on nginx requires a build with the debug module and will fill a disk faster than anything else in this post.

In a Node application, use a levelled logger such as pino rather than console.log, drive the level from an environment variable, and never log request bodies by default. In Python, the standard library is enough, and the single most effective line is silencing a library that thinks you care:

import logginglogging.basicConfig(level=logging.INFO)logging.getLogger("urllib3").setLevel(logging.WARNING)logging.getLogger("botocore").setLevel(logging.WARNING)

On a Java game server, the logger is Log4j2 and the level is set by the config file the JVM was pointed at with -Dlog4j.configurationFile=. Changing it is possible but fiddly, and in practice the noise on a Minecraft server comes from one or two plugins with a debug: true in their own config. Find those first. The genuinely alarming line, Can't keep up! Is the server overloaded? Running 2154ms or 43 ticks behind, is not noise however often it appears; it is the server telling you it missed two seconds of simulation.

On a panel, the console is the log. RE:NODE's console shows unfiltered live output with a command line that has history and tab completion, and folds repetitive web-server request noise behind a count you can switch off - which is the same idea as the nginx map above, applied at the point where you are reading. Reading the console covers what the common lines mean.

Finding the line you need#

Searching a log is a small skill that pays for itself the first time a server goes down at midnight. The important habit is to search with context, because a stack trace is useless without the lines around it:

$ grep -n -C 3 -iE "error|exception|warn" logs/latest.log | less$ zgrep -h "Exception" logs/*.log.gz | sort | uniq -c | sort -rn | head -20$ journalctl -u myapp -p warning --since "2026-09-20 18:00" --until "2026-09-20 19:30"

The second line is the one worth memorising. It reads every rotated log, pulls out the exceptions, and tells you how many times each distinct one occurred, most frequent first. Nine times out of ten the answer to "what is wrong with this server" is the top line of that output.

Two things to establish before you trust any of it. First, which clock the log is in: containers usually run UTC, your panel may render local time, and an hour's offset will have you reading the wrong window entirely. Second, read from the top. In a stack trace, the first line that names something which is not the game or the framework is your suspect; the last line is usually the generic handler that caught it. That single habit is most of what to do when a mod update breaks.

Admin actions, and the logs that get disputed#

Moderation records are the one category where the log is evidence rather than diagnosis, and they should be treated differently: kept longer, stored where the accused cannot reach them, and captured by something more structured than a text file.

Most games have a purpose-built answer. Project Zomboid writes _admin.txt and _pvp.txt as described above. On Minecraft, CoreProtect records block and container changes into its own database and answers /co lookup and /co rollback questions weeks later, and LuckPerms keeps its own action log of every permission change, queryable with /lp log recent. FiveM servers running txAdmin get an action log of admin commands attached to named accounts rather than to whoever happened to be in the console.

The panel layer matters here too. If everyone who administers the server shares one login, no log in the world can tell you who did it. Give each person their own account with the permissions they need, which on RE:NODE means subusers, roles and teams with granular permissions and a per-server activity log - subusers and least privilege goes through the split. The same applies to remote console access: RCON safely explains why an open RCON port makes every other log in this post unreliable, because anything can issue a command as nobody.

Getting logs off the machine#

A log that exists only on the server that burned down is not evidence, it is a hope. This does not need a logging stack. In order of effort:

1. Download the interesting ones by hand after any incident, before anything rotates. Five minutes, no setup, and it covers the crash report case entirely.
2. A scheduled task that compresses yesterday's logs and drops the archive somewhere you can fetch it. A cron expression, a console command, and a file you pull over SFTP - scheduled tasks worth having has the patterns.
3. A webhook for warnings only. Not a log stream - a filter that posts errors to a channel. The discipline is that it must stay quiet enough that people still read it. Monitoring that tells you something is entirely about that trade.
4. A database for admin and moderation actions, which is the only category worth the structure. A game database slot or a small managed instance is plenty.

On backups, there is a tension worth naming. A full backup of the server directory includes the log folder, which is helpful after a disaster and wasteful every other day, because logs are the most compressible and least valuable thing in the archive. If your host lets you exclude paths from a backup, logs are the first thing to exclude. And keep in mind that backups live with the server: on RE:NODE, deleting a server deletes its backups, locked ones included, so the copy that matters after a cancellation is the one you downloaded. That is the same argument as backups that actually restore, applied to text files.

One last thing the logs cannot tell you about themselves: a server that restarts repeatedly will rotate away the evidence of why. RE:NODE watches for that - a poll every two minutes for uptime that went backwards, with three unexpected restarts in an hour raising a warning on the server page and opening a ticket automatically - but the log window you need is the one immediately before the first restart, not the last. Grab it early. Why your game server keeps restarting covers the usual causes.

FAQ#

How long should I keep server logs?

Crash reports indefinitely, warnings and errors for 30 to 90 days, admin actions for six to twelve months, access logs for one to two weeks, chat for about thirty days. If you only remember one number, make it fourteen days for the bulky stuff and forever for the small stuff.

Does logging slow a server down?

Normal logging, no. Debug logging on a busy server, yes, measurably, because the write often happens on the thread doing the work and because it competes for the same disk as your saves. A log line printed once per tick is a performance bug regardless of where it is written.

Is latest.log the only file I need?

No. latest.log covers the current run only, and on a Minecraft server it is not rotated until the next start, so it can be both enormous and incomplete. The rotated .log.gz files beside it hold previous runs, and crash-reports/ holds the things that were too bad to log properly.

Can I just keep everything forever?

You can keep crash reports and start-up banners forever, because they are tiny. Keeping raw access logs, chat and IP addresses forever costs real disk, makes searching slower, and means you are storing other people's personal data with no plan for it. Keep the small things and rotate the big ones.

What should I attach to a support ticket?

The full log covering from the last clean start to the failure, the crash report if there is one, and what you changed most recently. Not a screenshot of the console, and not the last twenty lines - the last twenty lines are nearly always the cleanup, not the cause. A panel ticket takes private attachments, so the whole file is fine.

My disk filled overnight. Where do I start?

Sort the server directory by size, and expect the answer to be a log folder, a crash-report folder, or a plugin's own data directory. Delete the rotated archives first, fix the setting that produced the volume second, and only then consider whether the plan is actually too small.