Rust servers answer the same A2S query protocol as every other Source-engine game, with one difference that breaks most attempts to check them: the query port is not the game port. Get that wrong and a perfectly healthy server looks dead.
The port that matters ¶
A Rust server binds two ports. The game port, conventionally 28015, carries actual gameplay. The query port, conventionally 28016, answers the A2S requests that server browsers and status tools use.
They are usually adjacent, and the convention is game port plus one — but it is set independently with the +queryport launch argument, and hosts do change it. Checking 28015 when the query listener is on 28016 returns nothing, which is indistinguishable from an offline server unless you know to look.
Use our checker with the query port: address:28016. If that answers with a player count and a hostname, the server is up regardless of what any server list says.
Why the in-game list is not evidence ¶
Rust's server browser is populated from Facepunch's master list, which servers register with periodically. A server can drop off that list while running perfectly: a missed heartbeat, a master-list problem on Facepunch's side, or a filter in the browser you forgot you set.
The reverse also happens. Entries persist for a while after a server actually goes down, so the list shows something that no longer exists. Neither direction is a reliable signal, which is the whole reason to query the server directly.
Wipes look exactly like outages ¶
Rust servers wipe on a schedule, commonly weekly for the map and monthly for blueprints, and a wipe means a restart. During it the server is genuinely unreachable, sometimes for several minutes while the new map generates. Procedural map generation on a large map is not fast.
If a server is unreachable near the top of the hour on a Thursday, check the wipe schedule before concluding anything. This is the single most common false alarm in Rust server monitoring, and it is entirely predictable.
What each result tells you ¶
- Query answers, you cannot join: the server is up and something is refusing you specifically. EAC, a ban, a whitelist, a full server, or a version mismatch after a forced update.
- Query answers with 0 of 0 players: the server is running but likely still starting up. Player slots read zero before the world finishes loading.
- No answer on the query port, game port open: the query listener is misconfigured. Players can join; nothing can see it. Server owners: check
+queryport. - Nothing on either port: genuinely down, restarting, or wiping.
Forced updates ¶
Rust updates on the first Thursday of each month, and the client and server must match. After an update the server may be running while your client refuses to connect, which is not an outage on either side. The fix is updating the client, and the symptom is a version error rather than a connection failure.
For server owners ¶
Two things make a Rust server checkable, and both are frequently missed:
- Forward the query port as well as the game port, in UDP. Forwarding only the game port produces a server nobody can find.
- Keep
+queryportstable. Changing it silently breaks every status page, monitor and Discord bot that watches the server.
Once the query port answers, you can point a monitor at it and be told when it stops, rather than finding out from the players. Our A2S smoke test guide covers what the query returns and how to read it.
Finding the real query port ¶
The plus-one convention holds often enough to assume and often enough to be wrong. Three ways to find the actual value:
- The server's own console:
queryportprints it. - The startup command line, where
+queryportis set. - A hosting panel's allocation list, which is authoritative if you did not write the command line yourself.
If none is available, try game port plus one first, then 28016 regardless of the game port, then the game port itself. Two of those three cover almost every configuration in the wild.
Oxide and Carbon change the startup profile ¶
A modded Rust server loads its plugin framework and then every plugin before it starts answering queries, and on a large plugin set that is minutes rather than seconds. A monitor with a short timeout will report an outage on every restart, and alerts that fire predictably at restart time are alerts people learn to ignore.
Set the check timeout above the observed cold-start time, and prefer alerting on several consecutive failures rather than one. That is the same debounce reasoning behind not opening an incident from a single failed probe.
Monitoring a Rust server properly ¶
The query response carries more than up or down. Player count against maximum tells you whether a server is empty at peak, which is the metric that actually predicts a community dying, and it is available from the same request that answers the availability question. A server that is up and has been at zero players for a week has a problem no uptime percentage will show.