Fix lag on your Project Zomboid server
Find out which kind of lag you have before changing your world or server. A repeatable before-and-after check gives you more useful evidence than a guess about RAM or mod count.
- Describe what slows down and who sees it
- Capture the first error and available measurements
- Test one recent change safely
- Send support a short comparison if lag remains
Which kind of lag do you see?
Section titled “Which kind of lag do you see?”| What you notice | First check |
|---|---|
| The picture stutters or FPS drops on one player’s computer, while others play normally | Compare that player’s FPS in the same area and situation. This points to a client-side check first; it does not identify a server fault. |
| Movement jumps or a player disconnects, especially when only one player is affected | Compare another player’s connection at the same time and check the connection guide. |
| Several players see delayed actions or world updates at once | Record the time and read the server Console around that moment. Check whether a new area was being explored, more players joined or a mod changed. |
| The server slows or stops around startup or a busy period, while memory use approaches the available limit or a memory error appears | Save the first relevant error and the memory reading if the panel shows one. High usage is a clue, not proof of the cause. |
These symptoms can overlap. One player’s low FPS does not establish server lag, and an average CPU percentage alone cannot identify a cause.
Capture a useful baseline
Section titled “Capture a useful baseline”Open Console in the game panel. Note when the lag began, whether it affects one player or several, and the first relevant error around that time. Keep a short log excerpt rather than only the last line. Record the exact server build, recent mod or settings changes, player count and whether players were entering new parts of the world.
Record any CPU or memory readings the panel actually shows at the time of the problem, along with their time and whether they are current or averaged. If no reading is available, say so. A brief peak can be hidden in an average; a high reading without matching symptoms does not prove a bottleneck. For plan sizing rather than troubleshooting steps, see OXY’s Build 42 RAM and requirements article.
Compare one change at a time
Section titled “Compare one change at a time”Start with the event closest to the first slow period. If mods changed, use Mods not working to check their build support and dependencies. If population or other world rules changed, use Server settings to identify the active profile and change one value. An older, larger world or more simultaneous players may also change what the server has to handle; record those conditions rather than treating world age or player count as proof.
Test on a copy when you can. Otherwise keep a checked, downloadable recovery point and the original mod list or setting. Change one factor, restart if the linked procedure calls for it, then repeat the same action with similar players, area and time of play. Compare the symptom, first error and available measurements before and after. If the test does not help, return to the recorded starting state; use the world restore guide if a broader rollback is needed. A rollback that stops lag narrows the search but does not prove which mod or setting caused it.
Extra tips
Section titled “Extra tips”- Check the right server: compare the address players use with the server shown in the panel before attributing their symptoms to this world.
- Keep the build in view: mod behavior can differ between Build 41 and Build 42; check the author’s support for the build you run.
- Compare like with like: a quiet server and a busy evening are different test conditions.
What should I send support?
Section titled “What should I send support?”Send the server address, build, time and timezone of the first lag, who was affected, the action or area that reproduces it, recent mod or setting changes, the first relevant console error, and any panel CPU or memory readings with their timestamps. Include the before-and-after result and whether you have a verified backup. Leave out passwords, tokens and other credentials. Create a ticket with these details.