Resource metrics (CPU, RAM, disk)
Read CPU, RAM and disk metrics from the Servor agent on connected servers and set thresholds to catch resource problems early.
For any server you've connected, Servor collects resource metrics — CPU, RAM and disk usage — straight from the agent running on the machine. This gives you a live picture of a server's health next to its uptime, so you can spot a disk filling up or a runaway process before it becomes an outage.
Resource metrics need a connected server. If you haven't installed the agent yet, start with add a server. Monitoring a plain URL (an HTTP monitor) doesn't collect these — they come from the machine itself.
Where to find them
Open a server from the Servers list — open Servers in Servor — to see its resource metrics: current usage and trends over time. Because the metrics come from the agent, the server must show as connected. If it's unreachable, metrics stop updating — see repair the agent.
Read-only viewers can see metrics
Viewing metrics is read-only, so anyone on the team — including the viewer role — can look. Running commands to investigate needs write access and an unlocked vault.
What each metric tells you
| Metric | What it measures | Watch for |
|---|---|---|
| CPU | Processor load, as a % of capacity | Sustained high usage — an overloaded or runaway process |
| RAM | Memory in use vs. total | Consistently near 100% — risk of swapping or the OOM killer |
| Disk | Storage used vs. available | Filling up — a full disk breaks apps, logs and databases |
CPU
CPU usage shows how hard the processor is working. Brief spikes are normal — a build, a backup, a traffic burst. Sustained high CPU is the signal: it means the machine can't keep up, requests slow down, and the service may drift into degraded before going down.
RAM
Memory shows how much RAM is in use. When a machine runs consistently near full, the OS starts swapping to disk (slow) or, in the worst case, kills processes to reclaim memory. Rising memory that never comes back down often points to a leak worth investigating.
Disk
Disk usage is the one that most often causes a surprise outage. A disk quietly fills with logs, uploads or database growth, and when it hits 100% applications fail to write and can crash. Watch the trend, not just the current number — a disk climbing 1% a day tells you when you'll run out.
Disk full is a classic outage
A full disk breaks writes for everything on the box at once — databases, logs, the app. Set a disk threshold and act on it well before you reach 100%.
Set thresholds
Each server's settings (the gear icon) include surveillance thresholds for its resources. Set a level — for example warn when disk passes 85% — so a metric drifting into dangerous territory becomes something you're told about rather than something you discover during an incident. Combine thresholds with alerts and notification channels so the warning reaches you.
Investigate right there
When a metric looks wrong, jump into the web terminal or
run a command on the same server to dig in — df -h for
disk, top for CPU and memory. Or ask the AI copilot to
take a look.
Metrics vs. monitors
The two work together:
- Monitors answer "is this service responding from the outside?" — see monitor types.
- Resource metrics answer "is the machine itself healthy inside?"
A server can be fully up to an HTTP monitor while its disk is at 98% — the resource view is what catches that before it turns into an outage.