Game Server Monitoring and Uptime: A Guide

Most people who run a game server find out it is broken the same way: someone tells them. A message in Discord, a post on a forum, a friend saying they tried to connect last night and got nothing. By then the server has usually been unreachable for hours, and whatever momentum you had built up has quietly drained away. Monitoring exists to close that gap. Done properly, it means you know before your players do. Done badly, it means you get a hundred notifications a week and stop reading any of them.

This is about the practical side of keeping a server up: what to actually watch, how to be told about it, when automation helps and when it makes things worse.

The process is running and nobody can join

The simplest check you can write is whether the process exists. On Linux you look for the PID; on Windows you look in the task list. It is easy, it costs nothing, and it is close to useless on its own.

A game server process can be alive and completely unable to accept players. The main thread can deadlock while the process sits there consuming its slice of CPU. The listening socket can be bound but the game logic behind it stalled. A plugin can throw on every connection attempt and reject each player while the process itself carries on happily. On a Minecraft server, a stuck world-save or a plugin caught in a loop can leave the JVM running with nothing behind it. On FiveM, the server can hold its process while a resource error blocks the connection handshake entirely.

The question you care about is not "is the process alive". It is "can a player, from outside my network, reach this and get in". Those are different questions and they need different checks.

Query the port, not the process

Nearly every multiplayer game exposes a query interface — a small protocol that answers a simple request with the server name, map, player count and a few other fields. Source games answer the A2S protocol on their query port. Minecraft answers a server list ping on its game port. FiveM exposes an HTTP endpoint that returns its info and player data. Whatever the game, there is usually something that will answer a well-formed request with real state.

That is what you want to monitor. A query response is proof that the process is listening, that the game layer is responding, that the firewall is passing traffic and that the routing between you and the machine works. One check covers the whole path.

Run it from outside the machine. A query that succeeds from localhost tells you almost nothing about whether the outside world can reach you — it skips the firewall, the NAT rules, the host's own network filtering and everything upstream. If you can, run it from a different network entirely, on a small box or a service somewhere else. That is the view your players have.

Two things worth recording alongside the pass or fail. First, the response time: a query that answers in a few milliseconds and then starts taking a second or more is telling you the server is struggling well before it stops answering at all. Second, the player count, because a server that answers but sits at zero for a long stretch is a different problem — usually a discovery or reputation one rather than a technical one, and worth reading up on separately in why nobody joins your server.

What a server list is actually measuring

If you have your server listed on a directory like JoinGG, the status badge next to it comes from the same kind of query. The list queries your address on a schedule, and if it gets a valid response it marks you up. That is worth understanding properly, because it explains most of the confusion people have when their listing shows offline while they are standing in the game.

The list is checking one address and one port, from one place, at one moment. Any break in that chain produces an offline mark even when the server is perfectly healthy for the players already on it.

The common causes, in rough order of how often they turn out to be the answer:

The wrong port is listed. Games frequently split the game port and the query port, and people list the one they connect with. For Source-engine servers the two usually match, but not always, and if you have shifted the query port for a CS2 or Team Fortress 2 instance the listing needs to know.

The firewall passes the game port but not the query port. Traffic on the two is separate; opening one does not open the other. Same for UDP versus TCP, which trips people up more often than it should.

The server is genuinely saturated and dropping query packets. Under heavy load, query responses are often the first thing to suffer, since they are the lowest-priority work the server does.

The query protocol changed underneath you. This one is specific and it catches out a lot of FiveM operators after an artifact update, when the endpoint a list depends on starts behaving differently and a perfectly healthy server drops off directories overnight. How FiveM artifact updates affect server queries goes through what actually changes and how to confirm which side is at fault.

Rate limiting. Some setups, and some anti-DDoS layers, will throttle repeated identical requests from the same source. A monitoring service polling on a fixed interval can look exactly like something worth throttling.

If your listing shows offline, query the server yourself from an outside network before assuming the list is wrong. Most of the time the list is reporting something real that your players inside the server would never notice.

Alerts you will actually see

The purpose of an alert is to change what you do in the next few minutes. If it does not do that, it is not an alert, it is noise, and noise trains you to ignore the channel it arrives in.

The failure mode is familiar. You set up a webhook into a Discord channel. It fires on every check that fails. A flaky network path produces six alerts an hour. Within a fortnight the channel is muted, and when the server actually goes down for six hours nobody notices — including you.

A few things keep this under control.

Require consecutive failures before alerting. One failed query means very little; UDP packets are lost routinely and a single timeout is normal background noise. Three or four in a row over a couple of minutes is a real signal. This one change removes most false alerts on its own.

Send the alert somewhere that interrupts you. A push notification, an SMS, something that makes a noise on a device you carry. A message in a channel you already have muted is not an alert. If you run with other admins, work out who is actually expected to look and route to them, rather than to a room where everyone assumes someone else has it.

Alert on recovery too. Knowing the server came back on its own three minutes later changes your response completely, and without that message you will drive home to fix something that fixed itself.

Set a tighter threshold for a warning than for an outage. Query response times creeping up, memory climbing past a level you have chosen, disk approaching full — these are things you want to know about during the day, not at two in the morning when the server has already stopped.

Be honest about which alerts you have never acted on. Anything on that list should be deleted or downgraded. An alerting setup you trim regularly stays useful; one that only ever grows becomes wallpaper.

Restarts, and why unconditional ones bite

The obvious next step after detecting a failure is to fix it automatically. A watchdog that restarts the server when the query stops answering will genuinely recover you from a large share of real incidents while you are asleep. It is worth having. It is also worth building carefully, because a naive one can turn a small problem into a much worse one.

The failure to guard against is the restart loop. Something is wrong that a restart does not fix — a corrupted config after an edit, a mod that fails to load after an update, a full disk, a port already held by a process that did not exit cleanly. The watchdog restarts. The server fails to come up. The watchdog restarts again. Now you have a machine burning CPU on a loop, log files growing at speed, and on a game like Rust or 7 Days to Die where the world state is written on shutdown, a real risk of a half-written save if the cycle catches a write in progress.

Sensible guards, none of them complicated:

Cap the attempts. Three restarts in an hour, then stop and alert. If three did not fix it, a fourth will not either, and you would rather have a clean shutdown and a message than a machine thrashing.

Back off between attempts. Wait longer each time. This gives a slow-starting server room to finish coming up before the watchdog decides it has failed.

Give the server a grace period after start. Large worlds take real time to load, and modded Minecraft can take minutes before it answers a single query. A watchdog that expects a response thirty seconds after launch will kill a healthy server forever.

Always alert on an automatic restart, even a successful one. Silent self-healing means a server that has been quietly restarting six times a day for a month, and you will only find out when it finally stops working.

Make sure the old process is really gone before starting a new one. Two instances fighting over the same world files is a data-loss scenario, not an inconvenience.

Scheduled restarts

Restarting on a schedule, rather than in response to a failure, is a different tool and it earns its place in some games more than others.

It helps most where the server accumulates state it never fully releases. Heavily modded Minecraft, long-running Garry's Mod sessions with a lot of spawned entities, and FiveM servers running many resources all tend to degrade slowly over days rather than fail outright. A nightly or twice-daily restart resets that drift and is often much cheaper than chasing the underlying leak.

It helps least on a well-behaved vanilla server with a stable population. There you are just interrupting people for no benefit, and every restart carries a small risk of not coming back.

If you do schedule restarts, do them properly. Pick your quietest hour and check that against your actual player activity rather than your own timezone. Warn in-game on a countdown so people can find a safe place to log out. Skip the restart if the server is above some player threshold, or defer it — an empty-server condition avoids most of the complaints. Verify the server came back and answered a query afterwards, because an unattended restart that silently fails is worse than no restart at all.

Logs: keep some, throw the rest away

Logs are how you answer the question "what happened at 03:40" three days later. They are also how you fill a disk and take the server down yourself.

Worth keeping: crash logs and stack traces, obviously. Connection and disconnection records with timestamps, which let you correlate a crash with what a specific player was doing. Errors from plugins and mods, which are usually where the fault is. Admin actions, so you can reconstruct a config change that broke something. Your own monitoring history, so you can see whether today's outage is the first or the fifth this month.

Worth rotating away aggressively: chat logs beyond whatever retention you need for moderation, per-tick debug output, and anything a mod writes on every single event. These are the files that grow without limit.

Set up rotation with both a size cap and a retention period, and compress the old ones. Then test that a full disk does not take the server down — it is a genuinely common cause of an outage that looks mysterious until you check. Watching free disk space is one of the cheapest and highest-value checks you can run.

One habit that pays off: when something breaks, copy the relevant log section somewhere outside the rotation before you restart. Restarts often truncate or roll the file, and the evidence you needed goes with it.

Memory over days, not minutes

Memory is the resource where the useful timescale is completely different from everything else.

CPU spikes matter over seconds. Network matters over seconds. Memory matters over days, because the pattern that kills you is not a spike but a slow upward drift that never comes back down. A graph sampled every minute over an hour tells you nothing. The same metric plotted over a fortnight shows you immediately whether each restart returns to the same baseline or whether the floor is creeping up.

That creeping floor is a leak. In practice you rarely fix it — it is usually in a mod or plugin you do not maintain — but knowing it is there tells you the restart schedule is load-bearing rather than optional, and tells you what to test first after an update.

Watch two things, not one. Total system memory, so you know how close the machine is to the out-of-memory killer. And the game process's own usage, so you can tell whether the growth is the server or something else on the box. For JVM-based servers, heap usage is more informative than the process figure, since the JVM holds memory it is not currently using and the process number will alarm you for no reason.

If you have swap enabled and the server starts touching it, treat that as an outage in progress. A game server paging to disk is not slow, it is unplayable, and it usually looks like inexplicable lag rather than an obvious failure. A server that stutters badly without any obvious CPU load is worth checking against the symptoms in fixing FiveM server lag, which apply well beyond that one game.

Your server, or the whole game

Before you spend an evening debugging, establish whether the problem is even yours.

Games depend on platforms. Authentication services, master server lists, content delivery, anti-cheat backends. When one of those has a bad day, your server can be running perfectly and still be unjoinable, and no amount of restarting will change that. Steam authentication problems will stop people connecting to a Counter-Strike or Left 4 Dead 2 server that is answering queries normally. A FiveM platform issue does the same thing to a server that is fine by every local measure.

The tell is usually the pattern of failure. Queries answer normally but nobody can complete a connection. Existing players stay on happily while new ones cannot get in. Several servers you have no connection to report the same thing at the same time. Your own monitoring shows the server up throughout.

Build the check into your habits: before touching anything, look at whether other servers in the same game are having the same trouble. A directory like JoinGG is useful for this in a way people do not expect — if the whole game's listings dropped at once, it is not your config. Restarting during a platform outage costs you the players who were still connected and fixes nothing.

FAQ

How often should I query my server? Once a minute is enough for outage detection and gentle on the server. Going much tighter mostly buys you false alarms and a higher chance of tripping rate limits. Alert on consecutive failures rather than single ones.

Why does my server show offline on a list when I can play on it? Almost always the query path rather than the game itself: wrong port listed, query port closed at the firewall, packets dropped under load, or a protocol change after an update. Query it yourself from an outside network to confirm which. For FiveM specifically, artifact updates are a frequent cause.

Should I restart my server on a schedule? If it is heavily modded, or you can see memory drifting upward across days, yes — pick a quiet hour, warn players first, and skip it when the server is busy. A stable vanilla server with flat memory does not need one.

Is an automatic restart on failure safe? Yes, with limits. Cap the number of attempts in a window, back off between them, allow a grace period for slow world loading, confirm the old process has exited, and always alert even when the restart succeeds.

What should I monitor besides whether it is up? Query response time, free disk space, memory over a long window, and the player count. Those four catch the majority of problems before they become an outage.

How do I tell the difference between my server failing and the game's platform failing? Look at the shape of it. If queries succeed but new connections fail, if existing players are unaffected, or if unrelated servers report the same thing at the same time, the problem is upstream and restarting will only cost you the players you still have.

Do I need paid monitoring? No. A small script on a machine somewhere else that queries your address, requires a few consecutive failures, and sends you a push notification covers most of what matters. Paid services buy you multiple check locations and history you did not have to build, which is convenience rather than necessity. If you are weighing that against everything else you spend, the hosting cost breakdown puts it in context.