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 7 Days to Die, REST API for Palworld, bridge plugin for Valheim, the WindrosePlus status file for Windrose, server-list ping for Minecraft, the Steam query port or BattlEye RCon for DayZ)
• 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 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 its queries in parallel on each heartbeat: process stats (CPU time, memory, threads, handles), TCP connection counts per port, and the game process's network traffic. 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.

Network In and Network Out are the bytes the game process itself sends and receives over the network, measured by the host from Windows' own network events, averaged over the last few seconds. Traffic between the host's own tools and your server on the same machine (for example the player-count query) is left out, because it never crosses the network. If a host cannot take that measurement for a moment, the card shows the process's input/output rate instead, as it did before this measurement existed, so the figures are never left blank on a running server.

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, the server-list ping protocol for Minecraft, and for DayZ the Steam query port, with BattlEye RCon's player list when that does not answer. 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.