The Server Log Masterclass

7 Days to Die is built on Unity, so its dedicated server log is a Unity-style text log: one line per event, all levels in the same file, ordered by tick. This guide covers where to find the log, the four log levels the engine emits, the patterns you'll see most often when something is broken, and how to use telnet's loglevel command to filter live. The Admin Command Deep Dive covers the live tools (mem, chunkcache, listents) you'll pair with the log when diagnosing.

Where to Find the Log

The log path is set in the dedicated-server's startup script — startserver.bat on Windows, startserver.sh on Linux — via Unity's -logfile argument. Open your startup script first; the absolute path is right there. Common defaults if the script is unmodified:

  • Windows dedicated: alongside the server binary, typically under the install dir. The default startup script writes to 7DaysToDieServer_Data/output_log_dedi__<timestamp>.txt or to a logs folder named in the script.
  • Linux dedicated: alongside the binary or wherever the operator's -logfile argument points. Self-hosted setups often pipe to journalctl via systemd; in that case use journalctl -u <your-service> -f.
  • Hosting panel (CSMM, GTX, Nitrado, Bisect, etc.): the panel exposes the log under "Logs" / "Console" — that's the same Unity log, possibly with a different filename.

A new log file is created on each server start. After a few restart cycles you'll have several timestamped files; the most recent is always the one you want for "what just broke."

The Four Log Levels

Every line is tagged with a level. The dedicated server's loglevel telnet command (see Admin Command Deep Dive) toggles each on or off:

LevelTagWhat it means
InfoINFNormal operation: player join/leave, chunk loads, save events, periodic stats. High volume; usually skim, don't read.
WarningWRNSomething looked off but the server kept running. XML parser warnings, missing optional assets, deprecated config. Most are harmless individually; a flood of warnings is itself a signal.
ErrorERRAn operation failed but the server is still up. Failed save, missing entity ID, XML schema violations that prevented a feature from loading. Worth investigating.
ExceptionEXCAn unhandled .NET exception with full stack trace. May or may not crash the server depending on which thread; either way, this is what to grep for first.

Toggle a level on or off with loglevel <level> <true|false> over telnet — useful to silence INF noise while reproducing a bug.

Patterns You'll Actually See

NullReferenceException

The most common EXC. Means some piece of code tried to use an object that didn't exist. In 7D2D it's almost always one of:

  • A mod referencing a vanilla item/block ID that was renamed in a patch (the mod is out of date).
  • A mod referencing another mod that isn't installed (load-order or missing dependency).
  • A custom POI referencing a block that was removed or renamed.

Read the stack trace — the topmost frame inside a mod's namespace tells you which mod to update or remove. NREs from purely vanilla namespaces are usually transient and harmless unless they repeat tick after tick.

XML parse errors

If you see ERR lines mentioning "XML loading", "XPath patch failed", or "could not find element", a mod's XML config has a typo or is targeting an element that no longer exists in the current version. The mod will fail to apply that change but the server keeps running. Fix or remove the mod, restart.

Connection / authentication failures

If players can't join and you see lines about EOS, Steam authentication, or session registration, the most common causes:

  • Port forwarding is wrong. The default game port is ServerPort=26900 (UDP) and the server uses adjacent ports for game traffic. Confirm your firewall and router NAT rules pass UDP 26900 (and the few above it) through to the host.
  • The control or telnet ports are blocked from the operator but not the player. ControlPanelPort=8080 and TelnetPort=8081 are admin-only — block them at the firewall, but they're not the cause of player join failures.
  • ServerDisabledNetworkProtocols in serverconfig.xml is wrong for your setup. Defaults disable SteamNetworking; if you also disable LiteNetLib, no one can connect. See XML Settings reference.
  • EAC / EOS service outage upstream. Rare, but check the official 7D2D community forum or status pages before tearing down your config.

Memory / GC pressure

If INF lines show GC pauses growing or RAM trending upward over hours, the issue is server uptime, not configuration. Schedule restarts (see Scheduling Automated Restarts). Use mem or memcl over telnet to force a GC if you're trying to stretch to a planned window.

Chunk / world corruption

Lines mentioning "chunk", "region", or "save corrupted" indicate a bad save — usually from a non-graceful shutdown (the OS killed the process mid-write). Recover by restoring from your most recent backup. If you don't have one, the corrupted region is often deletable: the server will regenerate it on next load, with the side effect of losing whatever players built there. Always run saveworld before shutdown.

Useful Grep Patterns

The log is one big text file, so standard tools work:

# Show every exception with the next 3 lines (stack trace)
grep -A 3 "EXC " logs/output_log_*.txt

# Filter to errors and exceptions only (skip INF/WRN noise)
grep -E "(ERR |EXC )" logs/output_log_*.txt

# Find when a specific player joined/left
grep -i "playername" logs/output_log_*.txt

# Watch live (Linux)
tail -F logs/output_log_*.txt | grep --line-buffered -E "(ERR |EXC )"