The first sign that your game server is down is usually a message in Discord: "server's dead?" followed by three more people confirming it. By then it's been down for however long it took the first player to notice, which on a small server can be most of a day. The host's control panel said "Online" the whole time, because the panel is usually reporting that a process exists, not that anyone can play.

This guide is for people who run a Minecraft server, a modded pack for friends, a small community server for Rust or Valheim or Counter-Strike, or a handful of servers on a VPS. It covers what actually takes game servers down, how to monitor a Java Minecraft server with a TCP port check, what to do about the many games that use UDP and can't be port-checked, how to catch the worst case (running but frozen), and how to put the alert in the Discord your players already read.

How game servers actually die

  • The process crashed. Java ran out of heap on a big modpack, a plugin threw on startup, a world file corrupted, or the host's OOM killer picked the biggest process, which is always the game. If there's an auto-restart, it may be crash-looping; if there isn't, it's just off.
  • It's running but frozen. The tick loop is stuck on a deadlocked plugin, a hung world save, a chunk that won't load, or a garbage-collection pause that never returns. The process is alive, the port is open, the panel says Online, and every player who tries to join times out. This one hides from almost every simple check.
  • The address changed. Home-hosted servers live behind a residential IP that changes when the router reboots. Players connect to a hostname or an old IP that now points at nothing. The server is fine; nobody can reach it.
  • The port forward or firewall broke. A router firmware update reset the rules, the VPS provider's firewall got a new default, or someone "tidied up" iptables. Same symptom: server fine, unreachable.
  • The disk filled. Automatic world backups, crash dumps, and logs on a small VPS fill the disk in a few weeks. The server keeps running until it can't save, then corrupts the world or dies. See the VPS monitoring guide for the inside-the-box checks.
  • A plugin or mod update hung on startup. The server restarted for the nightly backup and never came back up because a plugin is waiting on a download or a config prompt. The port is closed, so a port check catches this one.
  • The host is having an outage. Shared game hosting, a VPS provider, or the home internet. Not yours to fix, but you want to know it's them before you spend an hour debugging your config.

Two kinds of check cover all of these: a check from the outside that the address and port are reachable, and a check from the inside that the game is actually responding. Neither is enough alone.

Minecraft Java: a TCP port check from outside

Java Edition servers listen on TCP, 25565 by default. CronAlert's TCP port monitor opens a connection to your server's address and port every minute and marks it down when the connection is refused or times out. That catches the crash, the failed restart, the port-forward problem, the IP change, and the host outage in one check. It works against a bare IP as well as a hostname, which matters because many game servers don't have a domain. TCP monitors are on the Pro plan at $5 per month.

Setup is the host and the port. Two tips:

  • If you're home-hosting, give the server a hostname through a dynamic DNS service (DuckDNS, No-IP, or your registrar's DDNS) and monitor the hostname rather than the IP. Then an IP change is invisible to players and to the monitor, as long as the DDNS updater is running, and if the updater dies you'll find out because the check fails.
  • Set the failure threshold to 2. Residential connections and cheap VPS hosts drop the odd packet. Two consecutive failures a minute apart means a real problem; one means Tuesday.

If you don't want a paid plan, there's a free path: most Minecraft server panels and several plugins can serve a small web page (a Dynmap or BlueMap web map, a Plan or Votifier status page, a Pterodactyl or Crafty panel). An ordinary HTTP monitor on the free plan tells you the host is up and the web service is running. It doesn't prove the game port is reachable, but for a home server it catches the IP change and the host being down, which are the two most common problems.

Bedrock, Rust, Valheim, CS2, and other UDP games

Most game servers other than Java Minecraft talk UDP: Bedrock on 19132, Rust on 28015, Valheim on 2456, Source engine games on 27015. A TCP handshake can't reach a UDP port, so a port check won't help, and CronAlert doesn't do UDP or ICMP. Flip the direction instead: put a one-minute cron job on the server host that checks the game locally and pings a CronAlert heartbeat URL only if the check passes. The heartbeat monitor alerts when pings stop, so a dead process, a frozen server, a host that went down, or a host that lost internet all produce the same alert. Heartbeats are also on the Pro plan; the ping URL looks like https://cronalert.com/api/heartbeat/<token>.

The "checks the game locally" part is the important design choice. Don't ping because the process exists; ping because the game answered. For Source games, Rust, and most others, a Steam A2S query does it. For Bedrock, an unconnected ping. For anything with RCON, a command that has to return output. A generic version using the gamedig query tool, which supports a long list of games:

# /etc/cron.d/gameserver-heartbeat  — every minute, as the game user
* * * * * steam /usr/local/bin/gameserver-heartbeat.sh

# /usr/local/bin/gameserver-heartbeat.sh
#!/usr/bin/env bash
set -euo pipefail
# gamedig exits non-zero if the server doesn't answer the query within the timeout
gamedig --type valheim --host 127.0.0.1 --port 2456 --socketTimeout 3000 >/dev/null
# Only reached if the query succeeded: the game is answering, not just running
curl -fsS -m 10 -X POST "https://cronalert.com/api/heartbeat/<token>" >/dev/null

Set the heartbeat monitor's expected interval to one minute. CronAlert alerts when no ping has arrived within twice the interval, so a server that stops answering at 2:00 produces an alert around 2:02. Swap the --type for your game; gamedig's list includes minecraft, minecraftbe, rust, csgo, terraria, palworld, and many more. If your host runs several servers, one script per server with its own heartbeat, so you know which one died.

Catching "online but frozen"

The frozen-tick-loop failure is the one that makes players lose faith, because the panel says Online, the port check passes, and a restart fixes it instantly once someone notices. The same heartbeat pattern catches it on Java Minecraft too, and it's worth running alongside the port check. The trick is to query something that requires the server to actually process a request:

  • A status ping (server list ping) has to return the MOTD and player count. A frozen server often still completes the TCP handshake but never answers the status request, or answers after a long delay. gamedig --type minecraft with a 3-second timeout does this.
  • An RCON command like list has to return output. Requires RCON enabled and bound to localhost; mcrcon is the usual client.
  • A plugin that pings from inside the tick loop. Some scheduler plugins can run an HTTP request on a repeating task; if the server thread is stuck, the task never runs and the heartbeat goes quiet. This is the most direct measure of "is the game loop alive" and costs nothing to set up if you already have such a plugin.

With both the port check and the heartbeat in place, the two together tell you what's wrong. Port check down and heartbeat down: the host or the network. Port check up and heartbeat down: the server is frozen or the query is failing; restart it. Port check down and heartbeat up: the server is fine, and players can't reach it because of a firewall, port forward, or DNS problem.

Panels, web maps, and the host itself

Anything with a web interface gets an ordinary HTTP monitor, which is on the free plan: the Pterodactyl or Pelican panel, Crafty Controller, AMP, a Dynmap or BlueMap web map, a Tebex store, a website with the server rules. These are worth monitoring in their own right (a panel that's down is a panel you can't use to restart the server), and they double as a host-level check. If you're on a VPS, the VPS guide adds the checks for disk space and reboots that game servers are especially prone to.

If you're on a managed game host, monitor your server's address, not the host's status page. Their status page says whether their fleet is up. Your check says whether your server is.

Put the alert where the players are

Your players are in Discord, and so should the alert be. Discord is a built-in alert channel on the free plan: create a webhook in a channel (an admin-only one, or a public "#server-status" channel if you'd rather players see it than ask), paste the URL, done. Every down and recovery message posts there with the server name and the duration.

Two refinements. First, keep email or a push notification enabled as well, because when Discord itself is having problems, the Discord alert won't arrive. Second, consider a public status page (free) with the port check and the web map on it. Pin the link in Discord. When the server is down, players check the page instead of pinging you, and when it comes back the page says so. Running a Discord bot for the server too? Monitoring a Discord bot covers that one.

Frequently asked questions

How do I know if my Minecraft server is online?

A TCP port monitor on the address and port (Java Edition) alerts within a couple of minutes when connections stop being accepted. Add a heartbeat from a status query to catch a server that's running but frozen.

What about Bedrock, Rust, Valheim, CS2?

UDP, so no port check. Run a per-minute query on the host with gamedig or RCON and ping a heartbeat on success.

Server shows online but nobody can join?

Frozen tick loop. Only a check that talks to the game (status ping, RCON, in-loop plugin) catches it. Wrap it in a heartbeat.

Can the alert go to Discord?

Yes, free. Keep email or push as a backup for when Discord is down.

Is this free?

HTTP monitors on panels and web maps, Discord alerts, and a status page are free. TCP port checks and heartbeats are on Pro at $5 per month.

Find out before the "server's dead?" message

A port check from outside and a heartbeat from inside cover every way a game server dies, including the frozen one that fools the panel. Send the alert to Discord, pin a status page, and the next outage is a two-minute restart instead of an evening of players drifting to someone else's server. Create an account, add a monitor for your server's address, and hook up the Discord channel. Related reading: how TCP port monitoring works, monitoring a VPS, monitoring Docker and self-hosted apps if your servers run in containers, and heartbeat monitoring.