Project Zomboid Server Monitoring: The Port, the Mods and the Memory

Project Zomboid asks for more patience than almost any other survival game. A character who survived four in-game months is dozens of real hours of careful play, and every one of those hours lives on one machine. When that machine stops, everyone is thrown out at once - and if the crash happened mid-write, the world can come back broken.

Which is why it is worth knowing, within a minute, that the server stopped. Not from a message in Discord an hour later.

The port that answers

A dedicated Project Zomboid server listens on UDP 16261 by default, and that is the port that replies to a status query. Ask it, and a live server tells you its name, the map it is running and how many survivors are connected:

name    After the Fall - PvPvE | Economy | Car Claims
map     Muldraugh, KY
players 70/130

Hosting panels reassign that number constantly, because several servers share one box: 16000, 16270, whatever was free. The port from your host is the one to use. Our Project Zomboid server checker assumes 16261 if you leave it out and keeps your number if you type one.

Note the protocol: UDP, not TCP. A TCP check against a healthy Zomboid server fails, because there is nothing listening on TCP to complete a handshake with.

Mods are the usual cause of death

Ask any long-running Zomboid community what killed the server last time and the answer will almost always be a Workshop mod.

The mechanism is unglamorous. Steam updates a mod on its own schedule. The server has an older copy, or a newer one that no longer matches what clients download. Depending on what changed, the server either refuses connections or fails to start at all - and it happens without anyone touching the machine. You go to bed with a working server and wake up to a dead one because a modder pushed a fix at three in the morning.

There is no clever prevention here, only speed of detection. A monitor that notices within a minute turns a lost evening into a five-minute update.

The other cause is memory

The server runs on Java with a fixed heap size. A large map, a long-lived world with thousands of moved objects, a dozen players spread across the county and a heavy mod list all push against that ceiling. When the heap is exhausted the process dies, usually without a graceful shutdown.

This failure has a signature: it does not happen at launch. It happens days in, and it happens more often on the busiest evening. If your uptime history shows a server that runs fine for four days and then dies at peak population, you are looking at memory rather than mods.

The fix is to raise the heap or trim the mod list. The point of monitoring is that the pattern becomes visible at all - without a record of when the crashes happen, every one of them looks like bad luck.

What to watch

• UDP on your real port. 16261 unless the host says otherwise. TCP checks are meaningless here.
• Silence means down. UDP has no handshake, so only a reply proves anything. A check that reports up because nothing complained is not a check.
• Check from several countries. Zomboid servers gather regional communities; a broken route from one continent will not show up if you only look from one place.
• Note the player count over time. A server that answers happily with zero players for a week is technically up and practically finished.
• Correlate crashes with the clock. Nightly at the same minute is a scheduled restart. Days apart at peak hours is memory. Right after a Steam update is mods.

Before you restart anything

When someone reports they cannot connect, check the server from outside first. If it answers, the problem belongs to that player - their port, their mods, their ISP - and restarting the server punishes everyone else for one person's issue.

If it does not answer, look at the console before restarting. A mod error names the mod. An out-of-memory kill leaves its own trace. Restarting first destroys the evidence and guarantees the same crash tomorrow.

The short version

• Project Zomboid answers on UDP 16261, and hosting panels move that number often.
• A TCP check on a healthy server always fails - wrong protocol, not a dead server.
• Workshop mod updates and an exhausted Java heap cause almost all unplanned downtime.
• When crashes happen matters more than that they happened: the timing tells you which of the two it was.