How to check if a FiveM server is down

FiveM is the odd one out. Where Rust, CS2, ARK and Palworld all answer the binary A2S query protocol, a FiveM server exposes ordinary HTTP endpoints that return JSON. That makes it the easiest game server on this list to check, and the one most people check wrongly by reaching for A2S tools that will never work.

The endpoints ¶

A FiveM server listens on one port, conventionally 30120, and serves several paths over plain HTTP:

• /info.json — server version, resources, and the configured variables including the server name.
• /players.json — the current player list, which is also the live player count.
• /dynamic.json — a compact summary: name, current and maximum players, and the active map or gametype.

Because these are HTTP, our website checker works on them directly. Check http://address:30120/dynamic.json and you get a real answer from the server itself, with the same four probe methods used on any other HTTP target.

What the response tells you ¶

• 200 with JSON: the server is up and its HTTP listener is healthy. If players still cannot connect, the problem is elsewhere — resources, the license key, or the game port.
• 200 but an empty or malformed body: the server process is running and something is wrong inside it, commonly a resource that failed to start.
• Connection refused: nothing is listening. The server is stopped, or the port differs from what you assumed.
• Timeout: the port is not reachable from outside. Firewall, port forwarding, or a host-level block.
• A 5xx: something in front of the server answered. If you have put a reverse proxy in the path, it is the thing responding, not FiveM.

The server list is separate infrastructure ¶

Servers appear in the FiveM browser by registering with Cfx.re's master list, which requires a valid license key and a working connection out to Cfx.re. Two failures follow, and they are frequently confused:

• Your server is fine but missing from the list: a license key problem, or a Cfx.re-side issue. Direct connect by address still works, which is the test that distinguishes them.
• Cfx.re itself is having problems: nobody's server appears, and new players cannot connect even to healthy servers, because authentication runs through Cfx.re. Your own server is up and unusable.

That second case is the one worth internalising. FiveM has a dependency on an external service for player authentication, so a server can be perfectly healthy and still unjoinable through no fault of its own — the same shape as an identity-provider outage on the web.

Resources are the usual cause ¶

Most FiveM downtime is not the server process failing. It is a resource — a script — erroring on start or crashing at runtime, which leaves the server up, the HTTP endpoints answering, and players unable to play. An external check will report everything healthy throughout.

That is a genuine limit of checking from outside, and worth stating plainly: reachability is not playability. The server console is the only place that failure is visible.

For server owners ¶

1. Do not expose the HTTP port publicly if you do not need to; a monitor can check it from a restricted source instead. It reveals your resource list to anyone who asks.
2. Monitor /dynamic.json rather than the base port, and assert on the JSON body rather than the status code. A 200 with a broken body is the failure a status check misses — the same point made in why a site can load while its API is broken.
3. Watch the player count as well as availability. A server that answers with zero players for an hour at peak time is telling you something an uptime check will not.

One port, two protocols ¶

FiveM uses the same port number, conventionally 30120, for both TCP and UDP: TCP carries the HTTP endpoints above, UDP carries gameplay. Forwarding only TCP produces a distinctive and confusing result — the server appears in the list, the JSON endpoints answer, every status check is green, and nobody can actually play.

That is a good example of why a reachability check is not a playability check. Ours would report the server healthy, and it would be telling the truth about the only thing it measured.

txAdmin sits in front and has its own port ¶

Most FiveM servers are managed by txAdmin, which runs its own web interface on a separate port, conventionally 40120. Two consequences worth knowing:

• Checking the txAdmin port tells you the manager is alive, not the game server. They fail independently, and txAdmin staying up while the server under it crashes is the normal case rather than the exception.
• The txAdmin interface must not be publicly exposed without authentication in front of it. It can start, stop and reconfigure the server.

Scheduled restarts are most of the downtime ¶

txAdmin restarts servers on a schedule, commonly every few hours, and a large resource set can take a minute or two to come back. A monitor with a tight timeout will record several outages a day that no player would call one.

Either align the check with the restart schedule or require consecutive failures before alerting. An alert that fires every four hours on the hour is an alert nobody reads by the end of the week.

When the whole platform is the problem ¶

Because player authentication runs through Cfx.re, a Cfx.re outage makes every FiveM server unjoinable at once while each individual server reports perfectly healthy. If several unrelated servers are simultaneously unreachable for players but green on every check, stop looking at the servers. That is the platform, and it is the same shape as an identity-provider outage on the web.