FiveM Server Monitoring

Two ways to monitor FiveM

Push is the recommended setup: the data is richer, and it catches the failure mode FiveM owners actually care about — the server being "online" while a critical resource has crashed.

You do not need our script for this. The shxrk-monitor resource below is just a reference implementation — any Lua resource (or any external process) that can POST JSON to the push endpoint works the same way. Build your own if you want different metrics, a different interval, or an integration with your existing framework.

Quick start: the shxrk-monitor example resource

1. Download the resource files:

   • fxmanifest.lua
   • server.lua
   • README.md

2. Create a game-server monitor in the dashboard with game_type: fivem and query_method: push — copy the push key shown at creation

3. Drop the shxrk-monitor folder into your server's resources/ directory

4. Add to server.cfg:

   ensure shxrk-monitor
   set shxrk_push_key "YOUR_PUSH_KEY"
   

   Optional tuning:

   set shxrk_push_interval "60"
   set shxrk_push_endpoint "https://api.shxrk.systems/api/v2/uptime/game-server/push"
   

5. Restart the server — the first push lands ~15 seconds after boot

The monitor flips up on the first push and down when pushes stop within expected_interval — a crashed or frozen server is caught even though it can no longer report.

What it reports

Alerting on crashed resources

The resources payload includes every resource with its state. With an event rule you can fire an alert when es_extended, ox_inventory, oxmysql or any other critical resource leaves the started state — the exact moment roleplay breaks, not when players start complaining.

Build your own push script

The push endpoint is a plain authenticated POST — write your own resource with the metrics you care about:

POST https://api.shxrk.systems/api/v2/uptime/game-server/push
Authorization: Bearer <push_key>
Content-Type: application/json

Every field is optional — push any subset, as often as makes sense for your setup:

custom_metrics is the escape hatch: queue length, player whitelist status, economy stats, txAdmin-derived data — whatever your framework can compute, you can chart and alert on.

A minimal custom resource looks like this:

CreateThread(function()
    while true do
        PerformHttpRequest("https://api.shxrk.systems/api/v2/uptime/game-server/push",
            function() end,
            "POST",
            json.encode({
                player_count = GetNumPlayerIndices(),
                custom_metrics = {
                    queue = GetConvarInt("sv_queueSize", 0),
                },
            }),
            {
                ["Authorization"] = "Bearer YOUR_PUSH_KEY",
                ["Content-Type"] = "application/json",
            }
        )
        Wait(60000)
    end
end)

The shxrk-monitor source in the quick start above is a fuller reference — it adds tick-rate measurement and iterates all resources. Fork it, strip it, or ignore it entirely; the endpoint only cares about the JSON.

External senders work too — a cron job, a txAdmin plugin, a panel daemon. The monitor flips up on the first push and down when pushes stop within expected_interval, regardless of who sent them.

See Game Server Monitoring for the full field reference.

Security

• The push key identifies your monitor — anyone holding it can push metrics to it. Keep it out of shared server.cfg copies
• If it leaks, regenerate it in the monitor settings — rotation only affects this one monitor
• shxrk_push_interval below 15s is clamped to 15s