When a Project Zomboid dedicated server crashes, refuses to load a mod, or a player accuses someone of random-deathmatching, the answer is almost always already written down somewhere. Your server logs are the single most useful diagnostic tool you have, and most admins never open them until something is on fire. This guide walks through exactly where Project Zomboid writes its logs, what each file is for, and how to read them to debug crashes, trace mod-load failures back to a specific mod ID, moderate chat and PVP disputes, and interpret anti-cheat kicks.
Everything here applies to Build 41 (B41.78), which is still the stable default branch on Steam as of mid-2026, and carries forward to Build 42, which remains on the opt-in “unstable” beta branch (latest release in our sources is Build 42.17.0, around April 2026). The log file layout, folder structure, and admin workflow are identical across both builds, so you can use this regardless of which branch your server runs.
Where Project Zomboid keeps its logs
A Project Zomboid dedicated server writes all of its files into the user-level Zomboid/ folder. On Windows that is C:\Users\; on Linux it sits in the home directory of the account running the server. Inside that folder you will find three subfolders that matter:
Server/— your config files (servertest.ini,servertest_SandboxVars.lua,servertest_spawnregions.lua).Saves/— the actual saved worlds and player databases.Logs/— the timestamped, archived log files from previous sessions.
There are two distinct things people mean by “the logs,” and it is worth being precise about both:
- The live console output — the file
server-console.txt, which lives directly in theZomboid/folder at the same level asServer/. This is the running stdout/stderr stream: the startup sequence, mod-load output, player connects and disconnects, and any errors thrown while the server is up. - The archived per-session logs — when the server restarts, the previous session’s logs are moved into
Zomboid/Logs/and timestamped (often zipped). These split the activity into separate files by type so you can jump straight to the category you care about.
If you are on a managed host, your control panel almost always exposes server-console.txt as a live “Console” or “Logs” tab, and gives you a file manager view of the Logs/ folder. The file names and contents are the same whether you read them through a panel, FTP, or directly on disk.
The live console: server-console.txt
Start here for almost every problem. server-console.txt is the first thing to read when a server won’t boot, hangs on startup, or won’t let players in. On a healthy launch you should see Java initialize, the world load, the Workshop items download and resolve, the mods load in order, and finally a line indicating the server is up and listening on its port (by default UDP 16261).
Read it top to bottom. The most common failure is a mod-load error during the “loading mods” phase — the console will print which mod it was working on when the error occurred. Player connection problems also show up here: you will see the connect attempt, and if the player is rejected (whitelist, anti-cheat, version mismatch) the rejection reason is logged right next to it.
The Zomboid/Logs/ folder: what each file covers
Inside Zomboid/Logs/, each archived file follows a
| Log file | What it contains | Use it for |
|---|---|---|
*_DebugLog-server.txt | Detailed internal game logic, Lua execution, and stack traces | Mod Lua errors and crash debugging — your single best file |
*_coop-console.txt / server-console.txt | Main console output — startup, mod loading, player connections | Confirming a clean boot, catching mod-load failures |
*_chat.txt | All in-game text chat (Global, Safehouse, Faction) | Moderating language, harassment, scam disputes |
*_pvp.txt | Player-on-player damage events | Resolving RDM and combat-logging accusations |
*_user* / *_safety* | Player actions and anti-cheat flags/kicks | Investigating anti-cheat kicks and bans |
*_perf* | Performance metrics over the session | Diagnosing lag and tick-rate problems (lightly documented) |
The *_perf* file is the least documented of the set; treat it as a rough record of how the server was performing over time rather than a precisely specified format. If you are chasing lag, it is worth opening, but the console and your host’s resource graphs will usually tell you more.
Debugging a crash with DebugLog-server.txt
When the server crashes or behaves erratically and the console doesn’t make the cause obvious, open the most recent *_DebugLog-server.txt. This is the detailed internal log — it captures the game’s Lua execution and prints stack traces when something throws. A typical crash investigation goes like this:
- Sort
Zomboid/Logs/by modified time and grab the newestDebugLog-serverfile (or the live one if the crash just happened). - Scroll to the bottom — the fatal error is usually the last thing written before the process died.
- Read upward from the error to find the stack trace and any “attempted index”, “nil”, or “callframe” lines that name a function or file.
- Look for a mod identifier near the error. Lua errors thrown by a mod almost always reference that mod’s files or ID in the trace.
That last point is the key to fixing the vast majority of server crashes: the error text points at the culprit. Once you have a suspect mod ID, the fix is to remove it from the Mods= line in servertest.ini and restart. If the crash stops, you’ve found it. The mechanics of how mods are listed — and why a single mod needs two separate entries — are covered in the next section.
Diagnosing mod-load failures
Mod problems are the most common reason a Project Zomboid server fails to start, and almost all of them trace back to the two-key Workshop system. Adding a Workshop mod requires two separate entries in servertest.ini, and getting one without the other is the number-one mod gotcha:
WorkshopItems=— the numeric Steam Workshop IDs (the number from the Workshop URL), semicolon-separated. This tells the server what to download.Mods=— the internal Mod IDs (text identifiers inside each mod, not display names), semicolon-separated. This tells the server what to activate.
WorkshopItems=624489512;972954692;670807387
Mods=CraftableAxes;Katana;MREMeal;NecroForgeA Workshop ID alone downloads the package but never loads it; a Mod ID alone won’t download anything. The console will tell you which side broke. The classic symptoms in server-console.txt or the coop-console log:
- “Mod not found” / load fails near a specific ID — usually a typo in
Mods=, or you used the mod’s display name instead of its internal Mod ID. Note that one Workshop item can contain several Mod IDs. - Download succeeds but the mod isn’t active — the Workshop ID is in
WorkshopItems=but the corresponding Mod ID is missing fromMods=. - A crash mid-load after a mod loads — an incompatibility or a bug in the mod’s Lua. The mod named just before the error in the console (or in the
DebugLog-serverstack trace) is your suspect. Load order is left-to-right inMods=, and later entries can override earlier ones, so a conflict often shows up as the second of two mods that touch the same thing.
The fastest way to isolate a bad mod is the binary-search approach: comment out half your Mods= list, restart, and see if the server boots. Repeat on the failing half until you’ve found the one. For a full walkthrough of finding internal Mod IDs and the download flow, see our guide on installing Steam Workshop mods on a Project Zomboid server, and the broader servertest.ini settings reference for everything else in that file.
Moderating chat and PVP disputes
Once your server has real players, the logs become a moderation tool. Two files do almost all the work here.
chat.txt — language, harassment, and scam disputes
The *_chat.txt log records all in-game text chat across the Global, Safehouse, and Faction channels. When someone reports harassment, a slur, or a “they promised X and didn’t deliver” trade dispute, this is your evidence. Search it for the usernames involved and the rough time the incident happened — the timestamped filename helps you grab the right session.
pvp.txt — RDM and combat-logging accusations
The *_pvp.txt log records player-on-player damage events. On a PVP server this is how you settle “he killed me for no reason” and combat-logging claims: you can see who damaged whom and in what order, which usually makes it obvious whether a kill was retaliation, an ambush, or genuine random deathmatch. Cross-reference it with chat.txt for the full picture — players often announce their intentions (or their disputes) in chat right before or after the fight.
Note that whether PVP damage even occurs depends on your config. PVP=true ships as the default, and the SafetySystem toggle (also true by default) governs the safety/duel mechanic that gates accidental friendly fire. If players say they “can’t hurt each other,” that is a config question, not a log question.
Once you’ve gathered the evidence, you act with admin commands. Useful ones for moderation: /kick removes someone (they can rejoin unless banned), and /banid or /banuser ban by Steam ID or username with the true flag persisting the ban. The full set is covered in our Project Zomboid admin commands guide.
Anti-cheat kicks: reading the user and safety logs
When a player is silently kicked and swears they did nothing, the *_user* and *_safety* logs are where the anti-cheat system records its flags. Project Zomboid’s anti-cheat is built from a family of independently toggleable protection types — in servertest.ini these appear as numbered keys AntiCheatProtectionType1 through AntiCheatProtectionType24, each set to true or false, rather than as one single switch.
Each protection type catches a different class of suspicious behavior, and when one triggers, the kick is logged with the type number. For example, a “Type 12” flag corresponds to a Lua checksum mismatch — which, importantly, is frequently caused by a legitimate mod/version desync between client and server, not by actual cheating. That is the key insight for admins: an anti-cheat kick is a starting point for investigation, not a verdict.
If many players are getting kicked with the same type right after you changed mods or the server updated, the cause is almost certainly a mod or version mismatch, not a wave of hackers. Make sure clients are on the same build (B41 stable vs. B42 unstable matters here) and have the same Workshop mods synced. If a specific protection type is producing constant false positives with a known-good mod list, server owners sometimes disable just that one numbered type — but do so deliberately, because each one is a real protection.
A practical admin log workflow
Putting it all together, here’s the routine that resolves most incidents:
- Server won’t start or just crashed? Read
server-console.txttop to bottom to find where it stopped, then open the latestDebugLog-server.txtfor the stack trace and the mod ID near the error. - A mod broke it? Confirm the mod has both a
WorkshopItems=entry and a matchingMods=entry, then remove or reorder the suspect inMods=. - Player behavior report? Pull the matching timestamped
chat.txtandpvp.txtfor the session, find the usernames, then act with/kick,/banuser, or/banid. - Mystery kicks? Check
*_user*/*_safety*for the anti-cheat type number and rule out a mod/version desync before assuming foul play.
For faster reading of large or zipped DebugLog-server files, the community maintains a Project Zomboid Log Analyzer on Nexus Mods that parses the output and highlights errors — handy when a session log runs to thousands of lines.
One more tip: if you can reproduce a player-specific problem (a corrupted character, an item exploit), remember that player data lives in a separate SQLite database, not in the logs. Multiplayer saves sit in Zomboid/Saves/Multiplayer/, and each character is a row in the NetworkPlayers table of players.db. Editing that database is destructive — always stop the server and back up players.db first — and the full safe procedure is in our guide on resetting a broken character without affecting other players.
If you’d rather skip the file-hunting entirely, a managed Project Zomboid server hosting plan surfaces the live console and the full Logs/ folder in your control panel, so reading server-console.txt or downloading a DebugLog-server file is a couple of clicks. You can also follow our step-by-step Project Zomboid server documentation for setup and configuration details.
Frequently asked questions
Where is the Project Zomboid server log file located?
The live log is server-console.txt, located in your Zomboid/ user folder (on Windows, C:\Users\) at the same level as the Server/ folder. When the server restarts, the previous session’s logs are archived into the Zomboid/Logs/ subfolder, timestamped and often zipped. Managed hosts expose both through the control panel’s console and file manager.
Which log file shows mod errors and crashes?
The *_DebugLog-server.txt file in Zomboid/Logs/ is the best place to look. It captures detailed internal game logic, Lua execution, and stack traces. When a mod throws an error, the trace usually names the mod’s files or ID — that tells you which entry to remove from your Mods= line. The startup-level mod-load failures (download errors, missing IDs) appear in server-console.txt instead.
How do I tell who started a PVP fight on my server?
Open the *_pvp.txt log for the session in question. It records player-on-player damage events, so you can see who damaged whom and in what order. Match the timestamps and usernames against the *_chat.txt log to see what was said before and after. Together these resolve most random-deathmatch and combat-logging disputes.
What does an anti-cheat “Type 12” kick mean?
Type 12 is a Lua checksum mismatch — the client’s mod/Lua state didn’t match the server’s. It is logged in the *_user*/*_safety* logs. Despite the alarming name, it is most often caused by a legitimate mod or game-version desync (for example, a client on Build 42 unstable trying to join a Build 41 server, or a mod that hasn’t synced) rather than actual cheating. Confirm everyone is on the same build and mod list before treating it as a ban-worthy offense.
Why is my server-console.txt empty or not updating?
If server-console.txt is empty, the server process likely never started — check that your start script (StartServer64.bat on Windows, start-server.sh on Linux) launched successfully and that Java is allocating memory via the -Xmx flag. If it stopped updating mid-session, the server may have crashed; the last lines written are your clue, and the matching archived logs in Zomboid/Logs/ will hold the final stack trace. On a managed host, restart from the panel and watch the console live as it boots.
Do Build 41 and Build 42 use different log files?
No. The log file types, names, and the Zomboid/Logs/ folder structure are the same across Build 41 (the current stable branch) and Build 42 (the unstable beta branch as of mid-2026). What differs between the builds is the world content, crafting, basements, and some SandboxVars.lua settings — and crucially, saves are not cross-compatible between the two builds. The way you read and use logs is identical regardless of branch.
Ready to play?
Run your own Project Zomboid server with XGamingServer
Spin up an always-on Project Zomboid server your friends can join in minutes — no port-forwarding, no tech headaches.
