Performance you can see, over hours and days

Every FiveGateway plan records server performance on a fixed cadence: CPU and memory sampled, network up and down summed, tick rate measured at the server level. The data lands in the dashboard as persistent charts you can scroll back through, not as a live-only gauge that resets on disconnect. A Starter plan keeps 7 days of history, Pro keeps 30, and Premium keeps 90, with CSV export on every tier.

Player counts are charted alongside the resource metrics. That is the combination that matters: a CPU spike during off-peak is a code problem, a CPU spike under load is a capacity problem, and a CPU spike with rising player counts during a donation drive is probably fine. Correlation between the two axes is visible in the same chart, not buried across tools.

Tick rate is the metric FiveM admins care about most, and FiveGateway treats it as a first-class signal. Drops below 40 tick are logged as performance events that flow through your normal webhook routing, so you can get a Discord ping the minute your server stops keeping up, instead of noticing after ten players have rage-quit.

Uptime history lives next to the performance charts. If the server was offline for 12 minutes at 03:40, the timeline shows it, and the events preceding the outage sit in the logs view one click away. That is the shortest path from 'something broke' to 'this is what broke' that you can build without a dedicated observability stack.

Exporting data matters for community operators who want to share transparency reports, for multi-server groups that want to compare fleets, and for anyone doing performance regression testing between versions of a framework or mode. CSV export is available on every chart and every filtered view, with the same column layout so downstream spreadsheets keep working across months.

If you already run an external monitoring tool (Grafana, Datadog, a homegrown Prometheus setup), FiveGateway is not trying to replace it. But the dashboard is where your moderators already live, and the charts they need most are rarely worth setting up a second pipeline for. Start here; keep the heavier stack for the workloads that need it.