Resource metrics (CPU, RAM, disk)

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.

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.

Beyond metrics: what's running and the machine's health

The Monitoring tab isn't just charts. When the agent is up to date, it also reports a server snapshot — shown as widgets that only appear when the thing is actually present, and that you can rearrange (see Compose your board):

• System: OS and version, kernel, architecture, vCPU, RAM, disk, connection mode.
• Network exposure: what the machine exposes, and what is meant to stop it. Listening ports (port, protocol, process, a service label for well-known ports) — the ones reachable from outside first — alongside the firewall's state (ufw, firewalld, nftables), its rules as the tool printed them, and its toggle for administrators. The firewall and the port list used to be two separate cards, each telling half the story: the firewall says what is allowed, the port list what is actually listening. The useful answer is where they meet — a service bound to 0.0.0.0 behind an inactive firewall is reachable; the same service bound to 127.0.0.1 is not, whatever the firewall says. Servor compares that list against the previous reading and alerts you when a port becomes reachable from outside — either it appeared, or, more insidiously, a service already running moved from 127.0.0.1 to 0.0.0.0. In that second case nothing "opened": the service was up, it merely stopped being private, and that is exactly the kind of drift you find out about the day somebody else finds it. A port listening only on loopback raises nothing, and neither does a machine's very first reading — otherwise every new server would alert on its entire surface.
• What's running: Docker/Podman containers (state, health, published ports), pm2 processes (status, restarts, CPU/memory), and detected services (nginx, PostgreSQL, Redis… — active/inactive + version). After an action taken from this screen — stopping a container, restarting a service, toggling the firewall, applying updates — the agent sends a fresh reading without waiting for its interval, and the screen updates itself within seconds. No need to reload the page.
• Server health: a traffic-light summary of the signals — failed systemd units, reboot required, firewall active, clock in sync, CPU/RAM/disk pressure.
• TLS & domains: detected certificates with their days remaining, and the domains attached to the server. k3s and self-hosted tools (Coolify, Portainer) show up when present.

Act on a container

Containers aren't only listed — each tile carries its own controls: start, stop and restart apply immediately, while update image (pull) and remove ask for confirmation first, since one changes what comes up next and the other destroys the container.

Removal is deliberately not forced: Docker refuses to remove a container that is still running, and Servor keeps that refusal rather than overriding it. Stop the container first if you really mean it.

A running container's tile also carries a shell button, which opens an interactive session inside the container, right there in the page. It runs sh rather than bash, because sh is the one shell essentially every image ships — alpine and slim images routinely have no bash, and aiming for it would close the session the moment it opened. Type bash once inside if the image has it.

Every one of these is a command like any other — signed in your browser, recorded in your command history and in the audit log. To read what a container is printing, use Follow logs live.

Rebooting or powering off

From the Monitoring tab, the Power card offers to reboot or shut the server down. It is admins only, protected by step-up MFA, and confirmed by typing the server name — not by a single click.

That friction is deliberate: it is the one action in Servor that no remote access can walk back. If the machine does not come back, neither the terminal nor the agent can switch it on — that takes your host, or physical access.

Acting on a service

The Detected services card works the same way: start, stop, restart and reload configuration apply immediately, while enable and disable at boot, mask and unmask ask for confirmation — the first two change what comes up at the next boot, and masking makes a unit impossible to start at all, including as another service's dependency.

Those buttons only appear for services systemd actually supervises. Servor also detects services started by pm2, supervisord or a container: those are listed, but without buttons, because systemctl does not speak for them and the command would fail every time.

Compose your board

The Customise button at the top of the tab puts the page into arranging mode. Each widget then gets a bar where you can:

• move it, by dragging the handle, or from the keyboard (Tab to the handle, Space to lift, arrows to move, Space to drop);
• change its width — 1, 2 or 4 columns. A widget whose content stops being readable below a certain width refuses the narrower sizes;
• remove it from the board.

Removed widgets collect below the grid and go back with one click. Reset restores the default arrangement.

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.

Two settings sit next to each threshold and decide when the alert goes out:

• Consecutive samples — how many readings in a row must sit above the threshold before an alert fires. A one-second spike during a backup is not an outage.
• Recovery margin — how many points the metric must fall back below the threshold before a new alert can fire. With a 90% threshold and a margin of 5, the alert only re-arms once the value has been at 85% or lower for that many consecutive samples.

The recovery margin is what stops a machine that permanently hovers around its threshold from notifying you on every swing. Set it to 0 if a single reading below the threshold should be enough to re-arm the alert.

Metrics vs. monitors

The two work together:

• Monitors answer "is this service responding?" — see monitor types. The agent metric type bridges the two: it puts a threshold, and therefore an alert, on the values shown on this page.
• 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.

Next steps