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, Enterprise: 10 s).

Timeout — Time to wait for a query response before marking the check failed. Default: 10 s.

Supported Games

UptimeHunt supports three 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.

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.

Minecraft (Server List Ping / Bedrock)

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):

1. Probers distributed across multiple locations send the query to host:port.
2. The response is parsed into a normalized envelope containing server name, current map, game type, player count (current and max), and optional player roster.
3. Response time is measured from query dispatch to full parse.
4. If no response arrives within the timeout, the check is marked unreachable.
5. 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.

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: down

gameserver_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: degraded

Example: 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: degraded

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: degraded

Useful 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: degraded

For 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) + 2

The 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_gametype as 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 map field will always be empty.

Related Documentation

• Services Management
• Service Details
• Creating First Service
• API Services Endpoints