Valheim server log explained: start-up, joins and errors

The Valheim server log is the only place the server explains itself. By default it goes to standard output - the terminal, the panel console, docker logs or the systemd journal - and -logFile /path/to/file.log sends it to a file instead. A healthy start-up reads in a fixed order: Unity and Steam initialise, the world loads or is generated, the server registers, and on a crossplay server a line with the six-digit join code appears. After that, every player who connects leaves a short trail of lines with their ID, their character name and, eventually, a closed socket. Most of the rest is noise. The handful of lines that matter - version mismatches, wrong passwords, refused IDs, failed saves, missing libraries - are what this post teaches you to find.

The exact wording of log lines shifts between game versions. The examples below are typical of current builds; match on the distinctive part of a line, not on every word.

Where the log goes#

Valheim does not keep a log file of its own unless you ask for one. Without -logFile, output goes to whatever started the process:

-logFile is a Unity player argument rather than a Valheim one, written with a capital F:

$ ./valheim_server.x86_64 -nographics -batchmode \    -name "Ravenhold" -port 2456 -world "Midgard" \    -password 'herring-barrel-42' -logFile /home/valheim/logs/valheim.log

Use it whenever output would otherwise vanish - most of all on Windows, where a server that dies at start-up takes its console window and the reason with it. On systemd or Docker it is usually better left off, because the journal and the container runtime already keep the output, rotate it and timestamp it. One catch: a file given to -logFile is typically overwritten on the next start. If the server crashed, copy the file before you restart it, or the only evidence goes with the next launch.

The client has its own log too. On Windows it is Player.log in %USERPROFILE%\AppData\LocalLow\IronGate\Valheim\. When a player says they cannot join, their log and the server's log read side by side usually settle it in a minute.

A normal start-up, in order#

A start-up that works produces a long burst of output. You do not need every line; you need to know the landmarks, because the place where they stop is where the problem is. Heavily abridged, with hundreds of lines left out between these, a start-up looks something like this:

Fallback handler could not load library .../libdl.soLoad world: Midgard (Midgard)Zonesystem StartDungeonDB StartGame server connectedSession "Ravenhold" with join code 483920 and IP 203.0.113.10:2456 is active with 0 player(s)

Read top to bottom, this says:

1. Unity initialised. The subsystem and graphics-device lines come first. On a headless server, messages about no graphics device are expected.
2. Steam's game server API loaded. Without it the server cannot authenticate players or register anywhere. On Linux, a failure here is nearly always steamclient.so not being found.
3. The world loaded, or was created. Load world: Midgard with your world name is the line to look for. If the log talks about generating a new world when you expected an existing one, the -world name does not match the file name - including capitals - and the server has created a fresh world beside your old one.
4. The zone system and dungeon database started. These come after the world loads; a stop between world load and these lines points at a damaged world file.
5. The server connected to Steam and registered. "Game server connected" or similar means the backend has accepted it. On a crossplay server, PlayFab lines appear around here too.
6. The session line. On a crossplay server this carries the join code; on any server it confirms the name, address and player count.

On a mature world the gap between "Load world" and the session line can be tens of seconds. That is the world file being read from disk and the zone data being built, and it grows with the size of the world. Players who try to join during that gap get "Failed to connect", which is why a server that "is running" according to the process list may not be ready yet.

The join code and the session line#

On a server started with -crossplay, the join code is printed in a line like this:

Session "Ravenhold" with join code 483920 and IP 203.0.113.10:2456 is active with 0 player(s)

The line repeats while the server runs, and the player count in it changes as people come and go, which makes it a cheap way to see occupancy at a glance. The code is generated at start-up and changes after every restart. If you publish it in a Discord channel, update it after each restart, or pick a fixed restart time so the group knows when to look.

If a crossplay server never prints a join code, it did not register with PlayFab. The usual causes are a server that cannot reach the internet outbound, a PlayFab outage, or a start-up that failed earlier and was missed. Steam players can still join by address in the meantime. Crossplay and Xbox players covers the relay side.

On a Steam-only server without -crossplay there is no join code, and the session line may be absent or shorter, depending on version. Look for the Steam registration line instead.

Connect, join and disconnect lines#

Every player who connects leaves a recognisable sequence. On a Steam-only server it looks roughly like this:

Got connection SteamID 76561198012345678Got handshake from client 76561198012345678Server: New peer connected,sending global keysGot character ZDOID from Sigrid : 1234567890:1

And when they leave:

Closing socket 76561198012345678

What each part tells you:

• `Got connection SteamID ...` - the network connection arrived. This is the earliest proof that the port is open and the player reached the right server. If a player says "Failed to connect" and this line never appears for them, the problem is the address, the port or the firewall, not anything inside Valheim.
• `Got handshake from client ...` - the client spoke the game's protocol. Version, password and list checks happen around here.
• `Got character ZDOID from Name : ...` - the player passed every check and spawned. This is the line that tells you who actually entered the world, with their character name. It is the line join-notification scripts and Discord bots watch for.
• `Closing socket ...` - the connection ended, for any reason: a normal logout, a crash, a kick, a timeout.

A ZDOID of 0:0 in that character line is the well-known marker of a player dying, not joining; tools that announce joins to Discord filter it out.

On a crossplay server the connection lines carry platform-prefixed IDs - for example Steam_76561198012345678 or Xbox_... - and PlayFab socket lines, and the plain SteamID form may not appear. Whatever form the log shows is the form the list files need. This is the reliable way to get a player's ID for adminlist.txt or permittedlist.txt: have them connect once and copy the ID from the log. The list files explains the formats.

To pull every join out of a long log on Linux:

$ grep "Got character ZDOID" valheim.log | grep -v ": 0:0"$ grep -E "Got connection|Closing socket" valheim.log | tail -n 40

Lines that explain a refused player#

When a player is turned away, the server usually says why in a single line near their connection. Wording varies; the distinctive phrase does not.

The version line is the most useful of these because it prints both numbers - the server's and the client's - so you know which side to update. After a Valheim patch, expect a string of these lines until the server is updated, and do not update a modded server until its mods have been. Updating the server and version mismatch covers timing.

A player who reaches the handshake and is then refused proves the network is fine. A player who never produces a Got connection line has not reached the server at all. That one distinction resolves most "I can't join" threads; failed to connect errors goes through every message on the client side.

Saves and the periodic status lines#

Valheim holds the world in memory and writes it out every -saveinterval seconds, 1,800 by default. Each save is logged:

World saved ( 412.5ms )

The number in brackets is how long the save took, and it is worth watching over the life of a world. A new world saves in tens of milliseconds; a heavily built, heavily terraformed one can take a second or more, during which the server stalls. If players report a hitch or a disconnect every half hour, line it up against the save lines. The cure is usually a shorter interval (smaller, more frequent saves cost less each), fewer loose items and less terraforming, not a bigger plan. Valheim server performance and lag has the longer list.

The save line also matters on shutdown. A clean stop writes the world before the process exits, and the last meaningful line in the log should be a save. If a log ends without one - cut off mid-line, or ending in ordinary chatter - the process was killed rather than stopped, and anything since the previous save is gone.

Periodically the server also prints a status line close to this:

Connections 3 ZDOS:184211  sent:41 recv:122

Connections is the number of connected peers. ZDOS is the number of world objects the server is tracking - every piece, item, creature and terrain modification. That number only grows as a world is explored and built, and it is a good proxy for how heavy the world has become. A sudden jump of tens of thousands usually means someone has built a vast structure or dropped a mountain of items.

Noise you can ignore#

A Valheim log is mostly noise, and some of it looks alarming. These are normal on a working server:

• `Fallback handler could not load library ...` - Mono probing for libraries under Linux. Harmless and repeated many times at start-up.
• `(Filename: ... Line: ...)` lines after almost every message - Unity's debug-build source references. Ignore them; read the line above.
• Shader, graphics device and audio warnings - the dedicated server has no graphics or sound, and Unity mentions it.
• `Destroying abandoned non persistent zdo ...` and similar ZDO housekeeping - the server cleaning up objects nobody owns.
• Steam API warnings that are followed by a successful "connected" line - the first attempt failed, the retry worked.

The lloesche Docker image and several panel setups filter some of this out by default. That makes the log easier to read but can hide context when something does go wrong, so if a problem is not making sense, look at the unfiltered output. Game server logs explained has general advice on reading noisy logs without missing the one line that matters.

Error lines worth acting on#

These are the lines that mean something is actually broken. Most appear at start-up.

The last-but-one row deserves a second look. A process killed for running out of memory does not get to write a goodbye; the log simply ends. If the log ends abruptly and the machine or panel shows memory at its limit at that time, that is your answer. On RE:NODE a server that reaches its memory limit is stopped and restarted clean rather than left to swap, so a cut-off log next to a memory graph at its ceiling tells you exactly what happened. The full start-up list is in Valheim server crashes on start.

Keeping and searching logs#

A log you cannot search a week later is not much use. A few habits:

• Under systemd, the journal does the work: journalctl -u valheim --since "2 hours ago" and journalctl -u valheim -g "Got character" cover most questions.
• With `-logFile`, rotate it yourself or the file grows forever. A logrotate rule with copytruncate works with a process that keeps the file open.
• With Docker, set log size limits on the container so a chatty server does not fill the disk.
• Before an update or a mod change, note the last version line and save a copy of a clean start-up log. When something breaks, a known-good log to compare against is worth more than any guide.

On RE:NODE the live console shows the unfiltered output, with a command line underneath for the admin commands that vanilla Valheim allows, and the join code appears there after every start. The file manager and SFTP reach any log file you write with -logFile. For a longer discussion of what to keep and for how long, see logs worth keeping.

FAQ#

Where is the Valheim dedicated server log file?

By default there is no file: the log goes to standard output - the terminal, console window, panel console, journal or docker logs. Add -logFile with a path to write it to a file instead, which is the only way to keep it when a Windows console window closes.

How do I find a player's ID in the log?

Have them connect once, even if they are refused. The connection lines carry their ID in the form the server uses - a SteamID64 on a Steam-only server, a platform-prefixed ID on a crossplay one. Copy it exactly into the list file.

Where is the join code in the log?

In the session line printed after start-up on a server running with -crossplay, next to the server name and address. It changes on every restart, so read it again after each one.

Why does the log show the same session line over and over?

The server reprints its session status periodically, with the current player count. It is not an error, and it is a quick way to see how many people are on.

Can I hide the noise in the Valheim log?

Some Docker images and panels filter common noise lines by default, and on your own machine grep -v does the same. Keep an unfiltered copy for troubleshooting, because filtered output can hide the line just before an error.

What does a ZDOID of 0:0 mean in the log?

It is logged when a player's character dies, not when they join. Join-announcement scripts ignore lines ending in 0:0 for that reason.