Live Resource Usage Monitor - Real-Time Metrics

Metrics at a Glance

The Overview tab of your server panel shows a "Resource Usage" card. Every figure on it is the game server PROCESS, not the machine it shares — so a busy neighbour does not inflate your numbers.

• CPU usage - per-process CPU percentage with a visual progress bar
• Memory - the process’s memory in MB, with a bar drawn against the memory allowance the host reports for your instance
• Players - the current player count, asked of the game itself (telnet for 7DtD, REST API for Palworld, bridge plugin for Valheim, the WindrosePlus status file for Windrose, server-list ping for Minecraft)
• Network In - inbound network throughput in bytes/sec
• Network Out - outbound network throughput in bytes/sec
• Uptime - time since the server process started, in human-readable format
• Threads - number of active threads
• Connections - TCP connection count

A green "LIVE" badge means these figures were just refreshed. If the badge reads "LAST KNOWN" instead, the host did not answer the most recent request and you are looking at the last values it did send — hover it for the reason. That distinction is the point of the badge: numbers that cannot be refreshed are never shown under a LIVE label.

The LIVE and LAST KNOWN badges only appear while the server is running; on a stopped server the card shows dashes.

Update Frequency

The host agent collects metrics locally and sends them to the backend on its heartbeat, every 15 seconds. The backend keeps them in a short-lived cache — 5 to 7 seconds — so a figure is never served long after it stopped being current. The panel polls that cache every 10 seconds, for both the Resource Usage card and the status bar at the top of the page.

So the freshest a figure can be is about 15 seconds old, and polling faster would only ask a question whose answer cannot have changed. If a heartbeat fails the agent backs off and retries, up to two minutes apart — which is when the card switches to "LAST KNOWN".

How Metrics Are Collected

The host agent runs three queries in parallel on each heartbeat: process stats (CPU time, memory, threads, handles), TCP connection counts per port, and process I/O rates for network throughput. A stopped instance reports zeroes rather than being left out, so a server that is simply switched off is not confused with one the host cannot see.

CPU percentage is computed from the change in processor time between successive heartbeats — the same approach Windows Task Manager uses. Collection is non-blocking, so it does not compete with the game.

The player count is asked of the game itself where the game offers a way to ask: the telnet console for 7 Days to Die, the REST admin API for Palworld, the bridge plugin for Valheim, the WindrosePlus status file for Windrose, and the server-list ping protocol for Minecraft. Every supported game reports a real player count.

History, and where it is not

The panel shows the current picture only. There is no graph of the last hour or the last week in your control panel, and no history endpoint on the Customer API — GET /servers/{id}/metrics returns the current sample, and /metrics/export returns that same sample as CSV.

The platform does keep a time series behind the scenes, downsampled as it ages: full-resolution samples for 6 hours, one-minute rollups for 7 days, and one-hour rollups for 180 days. It is what our support team looks at when you report a performance problem, so a ticket about lag that happened yesterday can still be answered.

If you want your own history, poll GET /servers/{id}/metrics on a schedule with a key holding metrics:read and record the answers. See Customer API Reference.