How to monitor a Linux server
A step-by-step guide to monitoring a Linux server — track CPU, RAM and disk, watch uptime, and get alerts when something breaks, using Servor.
Monitoring a Linux server means knowing two things at all times: is it up, and is it healthy? This guide walks through both — the metrics that matter, how to track uptime, and how to get alerted the moment something goes wrong — and shows how to set it all up in Servor in a few minutes.
What "monitoring a Linux server" actually covers
There are two complementary jobs, and a complete setup does both:
- Availability (uptime) — can people reach the services on the box? This is an outside-in view: HTTP requests, open ports, ping, DNS, SSL certificates.
- Resource health — is the machine itself under strain? This is an inside-out view: CPU load, memory usage, disk space. These warn you before an outage.
On a bare Linux box you'd stitch this together from tools like top, htop,
df -h, uptime, plus something to check the service from the outside and something
to alert you. Servor gives you all of it in one place.
The classic command-line snapshot
On the server itself, a quick health check is still useful: uptime for load
averages, free -h for memory, df -h for disk, and top for what's eating CPU.
Servor turns those one-off snapshots into a continuous, alertable history.
Monitor a Linux server with Servor
Add the server
Add your server by pasting the one-line install command into its shell. This installs the lightweight agent; once it's running the server shows as connected. This is the only step that touches SSH — see what is SSH if you're curious why. Add a server in Servor
Turn on resource metrics
With the agent connected, resource metrics (CPU, RAM, disk) start flowing automatically. Open the server to see live and historical graphs. See reading server metrics for what the numbers mean.
Add uptime monitors for the services
Create a monitor for each service the box runs. Use an HTTP monitor for a website or API, a TCP/port monitor for a database or cache, and an SSL certificate monitor so you're warned before a cert expires. Create a monitor in Servor
Set alerts and a notification channel
Configure alerts so a status change actually reaches you, and add a notification channel — Email, Slack, Discord or Webhook. Set a cooldown so a flapping service doesn't spam you. Open alert settings in Servor
Set resource thresholds
In the server settings (gear icon → surveillance thresholds), set sensible limits for CPU, RAM and disk so you're warned about a machine under strain, not just one that's already down.
What to watch on a Linux server
| Signal | Why it matters | In Servor |
|---|---|---|
| CPU load | Sustained high load means the box can't keep up | Resource metrics |
| Memory (RAM) | A steady climb often means a leak; near-full causes swapping | Resource metrics |
| Disk space | A full disk takes services down hard and recovers slowly | Resource metrics |
| HTTP response | Confirms the actual service — not just the machine — is working | HTTP monitor |
| Open ports | Confirms a database, cache or app is listening | TCP/port monitor |
| SSL expiry | Prevents the certificate warning your users would see first | SSL monitor |
| Uptime % | The one number that summarizes reliability over time | Monitor status |
Use a keyword check for real health
An HTTP monitor that only checks for a 200 can be fooled by an error page that
still returns 200. Add a keyword check so a page that loads but shows an error
correctly counts as down.
Reading the statuses
Every monitor reports one of three states: up, degraded, or down. A degraded state (slow responses, partial failures) is your early warning — treat it seriously before it becomes a full outage. See monitor status for exactly how each state is determined and how uptime % is calculated.
Close the loop
Detecting a problem is only half the job. Once monitoring is in place:
- Publish a status page with components linked to your monitors so users see the truth automatically.
- Let automatic incidents open from a monitor's down transition, giving you a public timeline from the moment things broke.
- Ask the AI copilot to investigate a flagged server and propose a fix — which you approve before it runs.
If the server shows 'unreachable'
Resource metrics come from the agent. If the server goes unreachable, the agent isn't connected — metrics pause until it's back. Use Repair the agent rather than reconnecting over SSH.