What to Do When Your Valheim Server Keeps Crashing

A Valheim server that keeps dying almost always tells you why, in a log you haven’t read yet. Start by protecting the world with a backup, then classify the failure: does it die at startup, after a few seconds, at a predictable moment, or randomly hours in? Each pattern points at a different cause — configuration, mods, memory, or the machine — and the fix is nearly always boring once you’ve narrowed it down.

First: protect the world

Repeated hard crashes are how worlds get corrupted, because each one risks a partial write. Before you debug anything, take a copy of worlds_local — the .db and .fwl pair, plus the .old rollback copies:

sudo systemctl stop valheim
cp -a /home/valheim/.config/unity3d/IronGate/Valheim/worlds_local ~/worlds-snapshot-$(date +%Y%m%d)

Now you can experiment freely. If you skip this and the world turns out to be the problem, you’ve lost your only clean reference point.

Read the logs, in this order

The service journal, for the process’s own output and the exit status:

journalctl -u valheim -b --no-pager | tail -n 100

In Docker:

docker compose logs --tail=200 valheim

The BepInEx log, if you run mods — BepInEx/LogOutput.log in the server root. Plugin errors land here and nowhere else.

The kernel log, for the crashes that aren’t the game’s fault:

sudo dmesg -T | tail -n 50

If the kernel’s out-of-memory killer terminated the server, this is where it says so, and no amount of looking at game logs will reveal it.

Classify the crash

Dies immediately at startup. This is configuration, not instability. The usual suspects:

The password is under five characters, or appears inside the server name. The server refuses to start and says so.
A mistyped or stale launch argument.
Wrong library path or missing app-ID environment variable in your own start script — compare against the script that shipped with the install.
Wrong install directory: your script launches from a path SteamCMD didn’t update.

Run the start script by hand in a terminal and read the output. A crash you can reproduce in the foreground is a crash you can fix in five minutes.

Dies a few seconds in, after loading begins. Usually a mod or a damaged install:

Launch without BepInEx once. If vanilla is stable, it’s your plugins.
Re-run the SteamCMD update with validate to repair missing or corrupted files.
Suspect the world file if vanilla with a fresh world name is stable but your world isn’t.

Dies at a predictable moment. A specific player joining, a specific area being entered, a particular event — these are gold. Whatever is reproducible is diagnosable. Note exactly what happens immediately before, and check the logs at that timestamp.

Dies randomly, hours in. This is resources or hardware, not logic. Move to the next section.

Rule out memory and disk

Out of memory is the most common cause of “it ran fine for three hours and then vanished”. The process gets killed by the OS, so the game log ends abruptly with no error at all — the signature is a clean cut with nothing after it.

free -h
dmesg -T | grep -i -E "out of memory|killed process"

If you find an OOM kill, the answer is more RAM or less load, not configuration. See How to Size Hardware for a Valheim Dedicated Server.

Out of disk produces failed saves and then failures cascading from them. Backups are the usual culprit, quietly accumulating:

df -h
du -sh ~/valheim-backups

Prune your archives in the same script that creates them.

Thermal or hardware trouble on a home machine — an old PC in a warm cupboard is a real cause. Random crashes with no pattern and no log evidence are the classic sign of failing RAM; run a memory test before you rebuild anything.

Isolate mods properly

If mods are involved, be systematic rather than intuitive:

Back up the whole BepInEx folder so you can put everything back.
Start with no plugins and confirm the server is stable.
Add them back in halves, not one at a time — you’ll find the culprit in far fewer restarts.
Read LogOutput.log after each round. Errors usually name the offending assembly.
Check dependency versions. A framework mod at the wrong version breaks everything above it in confusing ways.

A plugin that’s fine on the previous game build and crashes on the current one is the single most common modded-server crash. Update order matters: How to Update a Valheim Server Without Breaking Mods.

Suspect the world last, but do suspect it

A corrupted world can crash the server on load or when a particular region is entered. Test it cleanly:

Stop the server.
Change the world argument to a name that doesn’t exist, so the server generates a fresh world.
If the fresh world is stable, your original world is the problem.

To recover, stop the server and try the .old rollback pair — Valheim keeps the previous save alongside the current one. Copy both .db.old and .fwl.old aside, then use them as the active pair. If that fails too, go to a real backup: How to Restore a Valheim World From a Backup.

Stop the restart loop from hiding the problem

If systemd is restarting the service instantly, you may never see the error before it scrolls away, and the loop itself can worsen corruption. While debugging:

Raise RestartSec so there’s breathing room between attempts.
Or sudo systemctl stop valheim and run the start script in the foreground instead.

Unit-file details, including a stop timeout generous enough for the world to save on shutdown: Run a Valheim Server as a systemd Service.

Prevent the next one

Give the server enough memory headroom that ordinary growth doesn’t reach the ceiling.
Run save before every planned restart, so a crash never costs more than one autosave.
Back up off the machine, on a schedule, and prune archives automatically so disk exhaustion can’t sneak up on you.
Update deliberately, checking mod compatibility before patching, not after.
Schedule a nightly restart on a long-running server — it clears creeping memory use and gives you a predictable maintenance moment.

Almost every crash resolves to configuration, a mod, memory, or disk. Snapshot the world, read the journal and the BepInEx log, classify the timing, and work the list — guessing costs more evenings than reading does.