Game server logs explained: where they are, what to search

Every game server writes two kinds of record: the console output, which is what you see scrolling in the panel, and one or more log files on disk, which are what survives a restart. When something goes wrong you want the file, because the console only holds what has happened since the last start. Where the file lives depends mostly on the engine the game is built on - Minecraft and other Java servers write logs/latest.log, Unreal Engine games write <Project>/Saved/Logs/, Source games write nothing at all until you turn logging on, and Unity games write wherever -logFile points. Once you know the file, the search is short: the first ERROR or Exception after the start banner, plus a handful of specific strings that each mean one thing.

This post is the map: where each common game keeps its logs, which of the files matter, and what to search for. How long to keep them and how to rotate them is a separate decision covered in logs worth keeping, and the art of reading a stack trace once you have found it is in how to read a server console.

The console and the log file are not the same thing#

On a panel such as Pterodactyl, the console you see in the browser is the game process's standard output, streamed live. It is the fastest view of what is happening right now, and it has two limits:

• It starts again on every boot. After a crash and restart, the output of the crash is gone from the live view, replaced by the new startup.
• It may not be everything. Many games write some lines only to a file - detailed errors, chat, admin actions - and print a summary to the console, or nothing.

The log file on disk is the durable record. Most games start a new one on each boot and keep the previous one under another name, so the file you want after a crash is usually not the current one but the one before it. That detail alone accounts for a large share of "the log says nothing" reports: the person opened the log of the healthy restart, not the log of the crash.

On RE:NODE the console shows the unfiltered live output with a command line and history, and every log file is reachable through the file manager or SFTP. If you need to search a large file, downloading it and searching locally is often quicker than scrolling in a browser.

Where logs live, by engine#

Most games inherit their logging from the engine they are built on, which makes the location predictable once you know the engine.

Java: Minecraft and its proxies

Paper, Purpur, Velocity, BungeeCord, Forge, NeoForge and Fabric all follow this layout. Plugins often keep their own logs in plugins/<Name>/, and CoreProtect keeps its block history in a database rather than a log. A crash report is the single most useful file in Minecraft - it names the thread, the exception and usually the mod or plugin.

Source engine: CS2, TF2, Garry's Mod, CS 1.6

Source servers keep very little on disk by default. Two switches change that:

• log on in server.cfg (or the console) writes event logs - connections, chat, kills, rounds - to the game folder's logs/ directory, one file per map change named L<MMDD><NNN>.log.
• -condebug on the launch line copies all console output to console.log in the game folder. Useful when chasing a crash, noisy as a permanent setting.

SourceMod adds its own logs in addons/sourcemod/logs/: errors_<date>.log for plugin errors, which is the first file to open on a misbehaving modded server, and L<date>.log for admin actions. AMX Mod X on CS 1.6 does the same in addons/amxmodx/logs/. Metamod and CounterStrikeSharp on CS2 log to the console and to their own folders under addons/.

Unreal Engine: Palworld, Satisfactory, The Isle, Abiotic Factor

Unreal servers write to <Project>/Saved/Logs/<Project>.log, and rename the previous run to <Project>-backup-<timestamp>.log when they start. So Palworld's is in Pal/Saved/Logs/, Satisfactory's is FactoryGame/Saved/Logs/FactoryGame.log. Fatal crashes also leave a folder in <Project>/Saved/Crashes/ with a minidump and a copy of the log. Unreal log lines are tagged with a category such as LogNet, LogWorld or LogOnline, which is the best way to narrow a search.

Unity: Valheim, Rust, 7 Days to Die, Unturned, SCP: Secret Laboratory

Unity servers write wherever the -logFile argument points, or to standard output when it is absent or set to - (behaviour that has varied between Unity versions). Without either, the default on Linux is ~/.config/unity3d/<Company>/<Product>/Player.log. In practice:

• Valheim prints to the console by default; add -logFile to keep a file.
• Rust is normally started with -logfile naming the file, and Oxide or Carbon add oxide/logs/ or carbon/logs/ with plugin errors.
• 7 Days to Die's stock start script passes -logfile with a dated name, so each run gets its own output_log file inside the server's data folder. They accumulate - see disk space.

Unity logs are verbose and often full of harmless shader and asset warnings on a headless server. The useful lines contain Exception, and the most useful part of an exception is the first line of the stack trace that names something other than UnityEngine.

Bohemia: DayZ and Arma 3

DayZ and Arma 3 write into the profiles folder given by -profiles=. The files that matter:

A new .RPT is started on every launch, and they are not cleaned up, which makes the profiles folder a common reason a DayZ disk fills. -nologs turns RPT output off entirely; useful only when you are sure you will never need it, which on DayZ is never. DayZ admin tools and BattlEye RCON covers what reads the .ADM file.

Games with their own layout

Project Zomboid's Logs/ folder is particularly good: separate files for chat, admin commands, player connections, item and PvP events, which makes it the best-equipped game here for settling disputes.

What to search for first#

You do not read a 40,000-line log; you search it. The order that works almost every time:

1. The start banner. Find the most recent start of the server - in Minecraft Starting minecraft server version, in Unreal the first LogInit lines, in Source the build number. Everything above it is a previous run.
2. The first error after it. Search for ERROR, Exception, FATAL or Error: and take the first match after the banner, not the last match in the file.
3. The last lines before the end. If the file ends abruptly with no shutdown message, the process was killed from outside - memory, a kill button or the host - and the log will not explain it.

Then the specific strings, which are worth more than any general search because each one has a single meaning:

Each of these has a section somewhere on this blog, but the point is that you rarely need to understand the log as a whole - you need to recognise one line.

Searching logs with and without a shell#

With a shell - your own machine, a VDS, or a downloaded copy of the logs - grep does the work:

# first errors in the current Minecraft log, with line numbers$ grep -n -E "ERROR|Exception" logs/latest.log | head -20# the same across every compressed older log$ zgrep -l "OutOfMemoryError" logs/*.log.gz# five lines of context around each match$ grep -n -C 5 "Segmentation fault" console.log# follow a log as it is written$ tail -f Pal/Saved/Logs/Pal.log

zgrep reads the .gz files directly, so there is no need to unpack a week of Minecraft logs to search them. -l prints only the names of files that match, which is the fastest way to find which day something started.

Without a shell - which is the normal case on a panel - the options are the file manager and SFTP. Open a small log in the file manager's editor and use the browser's find; for anything large or compressed, download it over SFTP and search on your own machine. Any decent text editor can search a 100 MB file, and most can open .gz files or will once unpacked. SFTP and the file manager covers connecting.

Logs that are not logs: chat, admin and audit records#

Several of the files above are less about errors than about people. Source's log on output, DayZ's .ADM, Zomboid's chat and admin logs, SourceMod's admin log and Minecraft's chat lines in latest.log are the record of who did what. They matter when a player says they were banned unfairly, when a base is destroyed and nobody admits to it, or when an admin account was used by someone it should not have been.

Two practical points:

• Turn them on before you need them. -adminlog on DayZ and log on on Source games are off unless you ask for them, and you cannot reconstruct last week's kill log after the event.
• They contain personal data. IP addresses, Steam IDs and chat are personal data in the eyes of the GDPR. Keep them as long as moderation needs, not forever, and limit who on your staff can read them. On RE:NODE, subuser permissions let you give a moderator console access without file access, or file access without billing.

Server-wide moderation built on these logs is covered in server rules, moderation and staff.

Turning logging up, and back down#

When a problem is hard to pin down, more logging helps for a while. Each engine has a way:

• Minecraft: plugins often have a debug: true option in their config; Paper has replaced its old /timings system with spark, which recent builds bundle - but spark is a profiler, not a log.
• Source: -condebug and log on as above; developer 1 prints more to the console.
• Unreal: log verbosity per category, set with -LogCmds="LogNet Verbose" on the command line or in DefaultEngine.ini under [Core.Log].
• Factorio: --console-log for a file of the multiplayer console.
• BepInEx: BepInEx/config/BepInEx.cfg sets the log levels written to LogOutput.log and the console.

Turn them back down afterwards. Verbose logging on a busy server writes gigabytes a week, fills disks and slows the server it is meant to diagnose, because writing to disk is not free on the main thread of a game that logs synchronously.

Where the log will not help#

Some failures leave no trace in any log the game writes:

• An out-of-memory stop. The kernel ends the process from outside, so the game never gets to write a line about it. The log simply stops. The memory graph in the panel is the evidence; reading a server load graph shows what the shape looks like.
• A kill from the panel or a host-level stop. Same signature: the log ends mid-sentence.
• Network problems on the player's side. The server log may show a timeout or a disconnect reason, but not why their connection dropped.
• Lag. A slow server rarely logs anything except, on Minecraft, Can't keep up. A profiler, not a log, finds lag - see the spark profiler for Minecraft.

When the log ends without an error or a shutdown message, stop searching it and look at the graphs.

FAQ#

Where is the log file for my game server?

It depends on the engine. Java servers use logs/latest.log, Unreal servers <Project>/Saved/Logs/, Bohemia games the profiles folder, and Unity games whatever -logFile names. Source games keep only what you enable with log on or -condebug. The tables above list the common games.

Why is the log empty after my server crashed?

You are probably reading the log of the restart that followed the crash. Look for the previous file: the .gz in Minecraft's logs/, the -backup- file in Unreal, the older dated file in Bohemia and 7 Days to Die. If even that ends with no error, the process was killed from outside.

Is it safe to delete old log files?

Yes, with the server stopped or for files the server is not currently writing. Logs are never needed for the game to run. Keep the last week or two for diagnosis, and longer for admin and chat logs if you rely on them for moderation.

Can I see logs from the panel without downloading them?

Yes, the file manager opens text files in the browser, and the console shows the live output. For large or compressed files, downloading and searching locally is faster.

Why does my log mention passwords?

Some games print the full startup line, including passwords passed as arguments, and some plugins log their database connection string. Treat log files as sensitive, remove secrets before sharing them, and rotate any password that appeared in a log you posted publicly.