It's Saturday morning. Your Discord is quiet, which is either a good sign or a bad sign. A message comes in: "Hey, is the Valheim server down? We've been getting connection refused for like two hours." You check your monitoring dashboard. Everything is green. The host is up, ping is responding, no alerts fired. But your players can't connect — because the game daemon crashed overnight, and your monitor has been happily pinging the machine's IP ever since.
This is the gap that ICMP monitoring leaves in game-server operations. The host stays up. The ping stays green. The server process is gone. Your players find out before you do.
Why a Ping Isn't Enough
An ICMP ping tells you that a machine is reachable on the network. Nothing more. The operating system responds to pings; it doesn't care whether any of your application processes are running. A crashed game daemon, a hung process eating 100% CPU, a port collision that prevents the server from binding — none of these show up in an ICMP check. The host says "I'm here," and your monitor says "great," and your players are stuck in limbo.
What you actually need to check is whether the game service itself is responding on its port — and ideally, whether it's responding in the way a real game client would expect. That's what TCP and UDP port checks give you.
Minecraft Java: TCP Check on Port 25565
Minecraft Java Edition is a TCP service. When a client connects, it opens a TCP socket to the server on port 25565. If that connection succeeds, the server is alive and accepting connections. If it fails, the server process isn't listening — regardless of what the host's dashboard says.
In Nines, add a TCP check pointed at your server's hostname and port 25565. The check attempts a TCP connection on each poll. If it completes the handshake, the check passes. If the connection is refused or times out, the check fails and your alert fires.
One thing worth knowing for Java specifically: Minecraft Java and Minecraft Bedrock are completely different protocols on completely different ports. Java is TCP/25565. Bedrock is UDP/19132. Players on a Java server can't connect with a Bedrock client, and the monitoring approaches are different too. Don't assume they're interchangeable.
See the full TCP check reference at the monitor types documentation.
Steam Games: UDP Check with A2S
Valheim, ARK: Survival Evolved, Rust, Counter-Strike 2, and most other Source-engine or Steam-native games use a query protocol called A2S — the Source query protocol that Steam itself uses to populate the server browser. When a client looks for available servers, it sends an A2S_INFO packet and waits for a response. If the server is healthy, it responds with server metadata: name, map, player count, game version.
This is exactly what Nines checks with the source_a2s_info preset. A UDP check with
this preset sends the real A2S_INFO query packet and validates that the response starts with the
correct magic bytes. If the game daemon is running and serving players, the check passes. If the
daemon is crashed, hung, or not yet finished booting, the response never comes and the check fails.
In Nines, add a UDP check, select the source_a2s_info preset, and
enter your server's query port. For most Source-engine games — CS2, Rust, TF2 — the query port is
the same as the game port. Valheim is a notable exception: the A2S query port is game port + 1.
If your Valheim server runs on port 2456, the query port is 2457. (If you use the default Valheim
port, that's valheim.example.com:2457 for the query.) Missing this offset is the most
common misconfiguration when setting up Valheim monitoring — add the +1 and the check will work.
The A2S check gives you genuine end-to-end game-daemon verification. It's the same packet your Steam client sends. A passing check means the server is actually ready to accept players.
Minecraft Bedrock: UDP Check with the Bedrock Preset
Minecraft Bedrock uses a completely different query protocol — it doesn't speak A2S at all. Bedrock servers listen on UDP port 19132 by default and respond to a specific ping packet with a status string containing server name, MOTD, player count, and protocol version.
Nines ships a minecraft_bedrock_query preset for exactly this. Add a UDP check, select
the preset, point it at your Bedrock server on port 19132, and you'll get a real protocol-level check
against the game daemon — not just a port scan.
Quake3 and Other Classic Games
Running an older game server? If it uses the Quake3 network protocol — which covers the original
Quake III Arena, OpenArena, Urban Terror, and a long tail of Quake-derived games — there's a
quake3_status preset too. It sends the standard getstatus query and
validates the response prefix. Same idea: real protocol, real daemon check.
Beyond Gaming: DNS and NTP
The same UDP preset registry that covers gaming protocols also includes dns_a_query
and ntp_query presets. If you're running your own DNS resolver or an NTP server —
common in homelab and small-infrastructure setups — you can monitor those services with the same
UDP check mechanism. A DNS check that verifies your resolver is responding to real queries is
considerably more useful than a ping at a machine that happens to have port 53 open.
What Nines Doesn't Cover Yet
To be honest about the current state: Nines validates that the game daemon is responding with the correct protocol signature — the magic bytes that identify a valid A2S, Bedrock, or Quake3 response. It doesn't yet parse the response payload to surface things like current player count or server name in your dashboard. That's useful data and something that could come later, but it's not there now.
What you do get is binary: the server responded correctly, or it didn't. For uptime monitoring and alerting, that's the signal that matters.
Setting Up Alerts
A monitor without an alert is just a dashboard you have to remember to look at. Connect a notification channel in Nines and you'll get a message the moment a check fails — Discord, Slack, email, or webhooks. When your Valheim daemon crashes at 2 AM, you want your phone to buzz, not to find out from your players at noon.
See the notifications documentation for how to wire up your first alert channel. The setup takes about two minutes and works with the same monitors you've already configured.
It's also worth setting check intervals intentionally. The free tier polls at 5-minute intervals, which means a crashed game daemon might be down for up to 4 minutes and 59 seconds before your alert fires. If you're running a server where that gap matters, paid plans unlock 1-minute intervals. The tradeoffs are laid out in what 5-minute check intervals actually miss.
Start Monitoring Your Server
The free plan covers 7 monitors — enough for a game server, your host's HTTP panel, and a few other services you care about. No credit card required.
Sign up for Nines, add a TCP check for your Minecraft Java server or a UDP check with the A2S preset for Valheim, and you'll know within minutes if the daemon crashes — instead of hearing about it from your players.