Read the infrastructure as a connected system
CPU, memory, disk, load, and network signals are useful when compared with service state, agent freshness, and the asset's history. A reachable server can still have a failed application service; a slow website can be caused by more than host resource pressure.
Separate evidence from assumption
- Select the correct workspace and server.
- Check when the agent last reported and which metrics it supports.
- Choose a time range that includes the reported change.
- Compare related service and website checks.
- Document unknown or missing coverage in the report.
The resource-signals guide gives a practical sequence for investigation.
What to collect before changing infrastructure
Start with the affected host and the observation time. Compare CPU saturation with load, memory pressure with swapping, and disk capacity with disk activity when those signals are available. Then inspect the website or service check that users actually experienced. An agent that last reported an hour ago cannot support a claim about the current minute.
Turn measurements into a response
Record the workspace, target, time range and any missing samples. Check recent deployments or configuration changes with the people who own them. Only then choose whether to scale capacity, investigate a service, roll back a release or wait for another sample. Monitoring is evidence for that decision; it is not automatic authorization to modify a customer's system.
Who benefits? Teams running several servers, services or websites need one review sequence that keeps asset identity and history clear. Read the resource-signals guide or discuss monitoring and response scope.