Install ServerStats on FiveM and RedM (Qbox, QBCore, ESX, VORP/RSG)

To install ServerStats on FiveM or RedM, copy the serverstats folder from the zip into resources/, add set serverstats_claim "SS-XXXX-XXXX-XXXX" and ensure serverstats to server.cfg, then run refresh and ensure serverstats. The same resource runs on both games and picks the right metrics on its own; frameworks such as Qbox, QBCore, ESX, VORP and RSG are detected automatically.

It is server-side only, connects out over HTTPS and opens no ports.

Step 1: Check the requirements

• FXServer for FiveM (gamename gta5) or RedM (gamename rdr3), on a recent artifact. The resource uses FXServer's built-in Node runtime; current artifacts ship Node 22, and older ones with Node 16 also work.
• Console access (the txAdmin Live Console is fine). The resource's commands only work from the server console, not from in-game chat.
• Outbound HTTPS (TCP 443) to serverstats.cc. Nothing connects in.
• Framework (optional): see the table in Step 4.
• A ServerStats account. The Free plan covers one server; see pricing.

Step 2: Download and unzip the resource

Download serverstats-fivem-1.3.0.zip. It's the same file for FiveM and RedM. On Linux:

cd /path/to/server-data
curl -fLo serverstats-fivem-1.3.0.zip "https://serverstats.cc/downloads/fivem/serverstats-fivem-1.3.0.zip"
curl -fLO https://serverstats.cc/downloads/fivem/SHA256SUMS
sha256sum -c SHA256SUMS
unzip serverstats-fivem-1.3.0.zip -d resources/

You should end up with resources/serverstats/fxmanifest.lua and a server/ folder. Keep the folder name serverstats: other resources call its exports as exports.serverstats. A bracket folder such as resources/[tools]/serverstats works too.

Step 3: Create a claim code in the dashboard

In the dashboard, open Servers & agents, click Add a server and pick FiveM or RedM (pick the right one: it decides which metric set the server gets). Name it, and the Install step shows the claim code, SS-XXXX-XXXX-XXXX.

The code works once and expires after 30 minutes. On first start the resource generates its own Ed25519 key pair and sends only the public key with the code; every batch after that is signed with the private key.

Step 4: Add two lines to server.cfg

set serverstats_claim "SS-XXXX-XXXX-XXXX"
ensure serverstats

Use set, never sets or setr: sets publishes the value to the server list, and setr replicates it to every client. Load order doesn't matter much: the resource re-detects frameworks whenever one of them starts or restarts, but putting ensure serverstats after your framework is tidy.

What it detects and reads:

Qbox is checked before QBCore, because Qbox also answers as qb-core through its bridge. On RedM, VORP has no native money event, so VORP money flows are sampled balance changes every 60 seconds by default; RSG reports them directly. Standalone servers get the server, player and network metrics without the framework ones.

Optional: VORP currency changes as they happen

For per-operation VORP cash, gold and rol changes, add this line to vorp_core's fxmanifest.lua after its server/class/character.lua entry:

server_script '@serverstats/server/vorp_bridge.lua'

Restart vorp_core and serverstats. The bridge is included in the download, but must run inside vorp_core because VORP's exported character lookup returns a fresh proxy on each call. It observes VORP's server-side currency methods after balances change. ServerStats checks that the event came from vorp_core and that the new balance matches the current server-side character. The one-minute sampler remains as a fallback; changes recorded by the bridge are not counted a second time. The bridge records amounts and timing, not why a payment happened. Test it with a small known cash change on your installed VORP build, and re-add the manifest line if a framework update replaces that file.

Optional convars (all go in server.cfg with set):

Step 5: Start the resource

In the server console:

refresh
ensure serverstats

Or restart the server. The resource enrols, prints the key fingerprint (SHA256:...) and starts sending. The dashboard shows the same fingerprint under the server's settings. Once the server appears, you can delete the serverstats_claim line; a used code is never sent again.

Step 6: Check that data is arriving

serverstats status

This shows enrolment and fingerprint, the link state, what ingest accepted, the offline buffer, moderation state, the thread-timing source, the detected frameworks, and the resource's own server-thread cost per tick. serverstats flush sends a batch immediately.

Server-thread, sync-thread and network-thread times come from FXServer's own /perf/ endpoint on loopback, the same source txAdmin uses. If serverstats status says it's using the Lua fallback instead, /perf/ couldn't be read: set serverstats_perf_url to your real port (and serverstats_perf_auth if you use Prometheus basic auth). In the dashboard wizard, the First data checklist completes within about a minute. Per-resource CPU time isn't collected: FXServer only exposes it through its manual profiler, so for that use resmon and see the resource CPU guide.

Chart events from your own resources

Once ServerStats is running, another server resource can record a completed action:

exports.serverstats:track('heist_complete', source, { heist = 'fleeca', payout = 42000 })

The second argument is the player's server ID. Version 1.2.2 also records the calling resource under a source such as resource:heists. In Custom tracking, choose Make chart for heist_complete; set Event source to that resource if several resources send the same event. Use only short, flat properties and never pass player names, IP addresses or chat text. The custom plugin chart guide shows the calculations and filters.

Verify your download

Every release is signed. SHA256SUMS lists the hash of each published file and SHA256SUMS.sig is its Ed25519 signature, made with the ServerStats release key. To check the signature and your copy of serverstats-fivem-1.3.0.zip:

curl -fLO https://serverstats.cc/downloads/release-signing-key.pub.pem
curl -fLO https://serverstats.cc/downloads/SHA256SUMS
curl -fLO https://serverstats.cc/downloads/SHA256SUMS.sig
openssl pkeyutl -verify -pubin -inkey release-signing-key.pub.pem -rawin -in SHA256SUMS -sigfile SHA256SUMS.sig
grep " fivem/serverstats-fivem-1.3.0.zip$" SHA256SUMS
sha256sum serverstats-fivem-1.3.0.zip

The first command prints Signature Verified Successfully; the last two hashes must be identical.

Troubleshooting

• Link errors in serverstats status: outbound HTTPS is blocked. Test with curl -sI https://serverstats.cc on the host and allow TCP 443 out. While offline, batches go to disk (50 MB, 7 days at most) and are sent when the link returns.
• "Refused" claim (expired, used or invalid): a refused code is reported once and not retried. Codes last 30 minutes and work once. Get a new one from the server's settings (New claim code), put it in serverstats_claim and run ensure serverstats, or run serverstats claim SS-XXXX-XXXX-XXXX in the console. If a re-claim is refused, the resource keeps its old key.
• Framework not detected: run serverstats status to see what it found. Resource names must be the standard ones (qbx_core, qb-core, es_extended, vorp_core, rsg-core, ox_inventory).
• Key rejected after a move: a newer claim replaced the key. Claim again with a new code; buffered data is then sent.

Updating and uninstalling

Update: replace the resources/serverstats folder with the new one and run ensure serverstats (or restart). The key, state and buffer live in serverstats-data next to resources/, not inside the resource, so updates keep the server enrolled.

Uninstall: remove ensure serverstats from server.cfg, run stop serverstats, delete resources/serverstats and the serverstats-data folder (or wherever serverstats_data_dir points). Then open the server's settings in the dashboard and click Remove server….

What the resource sends

Server and thread timings, hitches, player counts and sessions, disconnect categories, and framework counters. It never collects chat text, command arguments, drop-reason text, IPs or endpoints, tokens or HWIDs, and names only if you opt in. Money reasons from other scripts are trimmed and masked before sending. Player identifiers travel over TLS only and are replaced with a keyed hash at ingest, a pseudonymous ID. More on the security page, the FiveM page and the RedM page.