Investigate performance with metrics

Before you begin

You need access to a connected server that supplies the relevant system or game metrics. Metrics differ between game servers, proxies, and standalone hosts.

Establish what changed

1. Open Statistics for the affected server.
2. Check live TPS, CPU, and memory where the runtime supports them.
3. Select a historical view to compare the problem with its earlier baseline.
4. Note the time window, player count, and whether the agent was connected throughout it.
5. Compare related readings before choosing a change.

For example, low TPS with a sudden rise in entities is a different lead from normal TPS with high network traffic. CPU percentages, JVM memory, and host memory describe different resources.

Correlate with other panels

• Console: exceptions, warnings, and plugin messages near the affected time.
• Players and Audience: player activity and population changes.
• Processes: competing host workloads, where supported.
• Info: runtime version, uptime, and host details.
• Events: structured events supplied by the connected agent.

Use a workspace to keep independent readings visible together. Compare equivalent time windows when reviewing multiple servers.

Interpret gaps and unavailable values

A gap means there is no usable sample for that period. It does not mean the resource used zero CPU or the server had zero players.

Kubernetes CPU and memory metrics need the metrics API. Game TPS needs a game runtime that reports it. A plan upgrade cannot supply a capability missing from the agent.

Record the symptom, time, selected server, and supporting readings before changing a setting. Change one cause at a time, then compare the same metrics after the change.

Next: alerts for offline and reconnecting-server incidents, or Ocelot for a guided investigation.