Game Server Monitoring
Monitor game servers across Quake III-family, Source/GoldSrc, Minecraft, BZFlag, and Armagetron Advanced — track player counts, map rotation, and server availability.
Game Server Monitoring
Game server monitoring in UptimeHunt queries a server's native status protocol and parses the response into a normalized envelope. You get player counts, the current map, game type, and response time — one check type covers all supported engines and flavors.
Configuration
Required Parameters
Service Name — Descriptive identifier for the monitoring service. Example: "ET: Legacy — Helsinki #1".
Game — Pick the specific game from the searchable game picker. This selection sets the underlying engine and protocol automatically. See Supported Games below.
Host — IP address or hostname of the game server.
Port — The query port — the UDP port the server's status protocol listens on. For most games this equals the game port. Notable exceptions:
- Rust: query port = game port + 2 (e.g. game on 28015 → query on 28017)
- Valheim: query port = game port + 1 (e.g. game on 2456 → query on 2457)
The game picker pre-fills the conventional default; override it if your server uses a non-standard port.
Optional Parameters
Project — Project assignment for organization.
Enabled — Toggle to activate/deactivate monitoring.
Check Interval — Monitoring frequency in seconds. Default: 180 s (3 min). Minimum is plan-dependent (Free: 300 s, Pro: 60 s, Team: 30 s, Scale: 30 s, Enterprise: 30 s — 30 s is the platform-wide floor).
Timeout — Time to wait for a query response before marking the check failed. Default: 10 s.
Supported Games
UptimeHunt supports five query protocols. A single "Game Server" check type handles all of them — the game picker sets the protocol automatically.
Quake III Protocol (getstatus)
Uses the Q3 getstatus UDP command via the opengsq library. All games in this family use the same wire format; the flavor selects the correct gametype label mapping.
| Game | Default query port |
|---|---|
| Quake III Arena | 27960 |
| Enemy Territory (incl. ET: Legacy) | 27960 |
| OpenArena | 27960 |
| Urban Terror | 27960 |
| Return to Castle Wolfenstein | 27960 |
| Tremulous | 30720 |
| Unvanquished | 27960 |
| Jedi Knight: Jedi Academy | 29070 |
| Soldier of Fortune II | 20100 |
| Star Trek: Elite Force | 27960 |
Source / GoldSrc Protocol (Valve A2S)
Uses the Valve A2S protocol via opengsq. Auto-detects GoldSrc vs Source packets so one transport handles both engine generations.
| Game | Default query port | Notes |
|---|---|---|
| Counter-Strike 2 | 27015 | |
| Counter-Strike: Source | 27015 | |
| Team Fortress 2 | 27015 | |
| Garry's Mod | 27015 | |
| Left 4 Dead 2 | 27015 | |
| Rust | 28017 | query = game + 2 |
| ARK: Survival Evolved | 27015 | |
| Valheim | 2457 | query = game + 1 |
| Squad | 27165 | |
| Quake Live | 27960 | id Tech 3 game, A2S protocol — see below |
| Counter-Strike 1.6 | 27015 | GoldSrc engine |
Quake Live is monitored over A2S, not the Quake III protocol. Despite being an
id Tech 3 game, Quake Live servers do not answer the getstatus/getinfo queries the
rest of that family uses — they answer Valve's A2S only. Its default port is still
27960, the same as its game port.
A2S_PLAYER roster queries are best-effort. Some servers rate-limit the roster endpoint; a failed player-name fetch does not fail the availability check — only the player count from A2S_INFO is required.
Minecraft (Server List Ping / Bedrock)
| Variant | Protocol | Default port |
|---|---|---|
| Minecraft (Java) | Server List Ping (TCP) | 25565 |
| Minecraft (Bedrock) | RakNet unconnected ping (UDP) | 19132 |
Minecraft Java exposes server name (MOTD) and player counts but has no concept of a map — the map field in the check result will be empty. Minecraft Bedrock has no player roster (only online/max counts).
BZFlag
Uses the native bzfs TCP status query on port 5154. For BZFlag the query port is the game port — there is no offset — but public BZFlag servers commonly run on non-default ports (4011, 4100, 4202, 5155, 5160, and others are all seen in the wild), so enter the port from your own server's configuration (the -p flag passed to bzfs) rather than assuming the default.
| Game | Default query port |
|---|---|
| BZFlag | 5154 |
BZFlag's protocol carries neither the server's title nor a map/world name — a bzfs instance genuinely has no concept of either at the wire level (the title only exists in the server's registration with the public list server). The gameserver_name and gameserver_map assertions are therefore not usable for BZFlag; use gameserver_gametype, gameserver_min_players, and gameserver_responds instead. A full BZFlag server still answers the status query and is correctly reported as up.
BZFlag returns the active game style (Team FFA, Classic CTF, Open FFA, Rabbit Chase), per-team sizes and scores, the connected players' callsigns, and the server's enabled game options (jumping, ricochet, shaking, and so on) as extra detail alongside the standard player count and response time.
Armagetron Advanced
Uses the game's UDP small-server-info query on port 4534. The query port is the game port — there is no +1 offset for Armagetron, despite that being a common assumption; two server instances on one host each answer only on their own distinct port (e.g. :4534 and :4535 are two separate servers, not one server on two ports).
| Game | Default query port |
|---|---|
| Armagetron Advanced | 4534 |
Unlike BZFlag, Armagetron reports the server's configured name and a full player roster. It has no concept of a map/level either, so the map field is empty here too. Beyond the standard fields, results also include the server version and the operator's free-text description.
Coming Soon
Warsow, Warfork, Call of Duty (1/2/4), Medal of Honor: Allied Assault, and Xonotic require custom query transports not yet built. They appear in the game picker as greyed "Soon" entries and cannot be selected.
How It Works
The prober sends the game server's native status query over UDP (or TCP for Minecraft Java):
- Probers distributed across multiple locations send the query to
host:port. - The response is parsed into a normalized envelope containing server name, current map, game type, player count (current and max), and optional player roster.
- Response time is measured from query dispatch to full parse.
- If no response arrives within the timeout, the check is marked unreachable.
- Results are stored and evaluated against any assertions you have configured.
Because there are no default assertions for game servers, a server that responds — regardless of map or player count — is considered healthy unless you add assertions that say otherwise.
Assertions / Response Validation
Game server monitoring has five assertion types. Add them under Expectations on the service page.
Every assertion now supports its full operator set
Each assertion type below lists its default comparison, but the rules builder lets you pick from its whole supported set — a numeric one like gameserver_min_players can also be "at most," "under," "over," or "in range," and a text one like gameserver_map can also be "contains," "does not contain," or a regex. See Expected Results (Rules Builder) for the full operator model.
gameserver_responds — Server responds
The server answered the status query and the response was parseable. Default severity: down.
Use this as your baseline availability assertion. Without it, an unreachable server is still visible in check history but does not trigger an incident.
Type: gameserver_responds
Operator: exists
Value: (none)
Severity: downgameserver_min_players — Players online at least
Alerts when the live player count drops below a threshold. Useful for detecting a stuck or empty server that should have active players. Default severity: degraded.
Type: gameserver_min_players
Operator: >=
Value: 1
Severity: degradedExample: alert if a public server that normally runs 10+ players drops to zero — which may indicate a crash or a network split rather than a quiet night.
gameserver_map — Current map equals
Alerts when the current map changes to something unexpected. Default severity: degraded.
Type: gameserver_map
Operator: equals
Value: et_beach
Severity: degradedThis assertion uses exact string matching. If your rotation includes several maps, use gameserver_gametype to enforce mode instead, or omit the map assertion and rely on player-count assertions.
gameserver_name — Server name contains
Alerts when the server's name no longer contains the expected substring. Default severity: degraded.
Type: gameserver_name
Operator: contains
Value: Clan XYZ
Severity: degradedUseful for detecting an accidental server rename, a config rollback, or an impostor server appearing on the same IP.
gameserver_gametype — Game type equals
Alerts when the active game mode changes. Default severity: degraded.
Type: gameserver_gametype
Operator: equals
Value: Capture the Flag
Severity: degradedFor Quake III-family servers the game type is resolved from the numeric g_gametype field using per-game tables (e.g. Q3A: 4 = "Capture the Flag"; Enemy Territory: 2 = "Objective"). For Source/GoldSrc the game name reported by A2S_INFO is used. For Minecraft the mode string from the server (Bedrock) or a static label (Java) is used.
Examples
Public Enemy Territory server — availability + minimum players
Game: Enemy Territory (incl. ET: Legacy)
Host: et.example.com
Port: 27960
Interval: 120 s
Assertions:
- gameserver_responds exists (severity: down)
- gameserver_min_players >= 1 (severity: degraded)Raises a down incident if the server stops responding entirely, and a degraded incident if it is reachable but empty (e.g. after a crash restart that left no one reconnected yet).
Minecraft Java — availability and MOTD integrity
Game: Minecraft (Java)
Host: mc.example.com
Port: 25565
Interval: 180 s
Assertions:
- gameserver_responds exists (severity: down)
- gameserver_name contains "SurvivalCraft" (severity: degraded)Catches both a downed server and an accidental rename (e.g. a new map pack that reset the server MOTD).
Counter-Strike 2 — mode enforcement
Game: Counter-Strike 2
Host: cs2.example.com
Port: 27015
Interval: 60 s
Assertions:
- gameserver_responds exists (severity: down)
- gameserver_min_players >= 5 (severity: degraded)
- gameserver_gametype equals "Counter-Strike" (severity: degraded)Useful for a hosted CS2 server where the operator wants to know if it slips into a non-standard game mode or drops below a viable player count.
Rust — query port arithmetic
Rust game servers expose their status on game port + 2. If your game server runs on port 28015, enter the query port 28017:
Game: Rust
Host: rust.example.com
Port: 28017 ← game port (28015) + 2The game picker pre-fills this default; adjust if your server uses a non-standard game port.
Troubleshooting
Server shows unreachable but is running
- Confirm the query port, not the game port. Many games use a separate UDP port for status queries (see Supported Games port table, and note Rust +2 / Valheim +1 offsets).
- Check that your firewall allows UDP on the query port from the prober's source addresses.
- Increase the Timeout if your server is slow to respond under load.
Player count is zero but the server has players
- Some Source/GoldSrc servers rate-limit A2S_PLAYER roster queries. The player count comes from A2S_INFO (which is never rate-limited); roster names come from a separate query that is best-effort. The count is always accurate even when the name list is empty.
Map or game type shows an unexpected value
- Q3-family servers report
g_gametypeas a numeric code. UptimeHunt resolves it per game (e.g. Enemy Territory 2 = "Objective"). If the resolved label looks wrong, check whether the server mod uses a non-standard numbering. - Minecraft Java does not report a map name; the
mapfield will always be empty.