Server monitoring best practices
A practical guide to server monitoring best practices — what to monitor, how to set thresholds, and how to avoid alert fatigue on your team.
Good monitoring tells you something is wrong before your users do — and stays quiet the rest of the time. This guide covers the monitoring best practices that matter in practice: what to watch, where to set thresholds, and how to keep alerts meaningful so your team doesn't learn to ignore them.
If you haven't set anything up yet, start with Create a monitor — or jump straight in: create a monitor in Servor.
Monitor from the outside and the inside
The two views answer different questions, and you want both.
- Outside-in (uptime) — is the service reachable and responding correctly? These are your HTTP, TCP, ping, DNS and SSL monitors. They catch the failures your users actually feel: a site that's down, an expired certificate, a DNS change gone wrong.
- Inside-out (resources) — is the machine itself healthy? Resource metrics (CPU, RAM, disk) come from the agent and warn you before an outage — a disk filling up or memory pressure building is a problem you can fix on a schedule instead of at 3 a.m.
Rule of thumb
Every public-facing service deserves at least one outside-in monitor. Every server running the agent deserves resource metrics. The overlap is where you get early warning and confirmation of user impact.
What to monitor first
You don't need to monitor everything on day one. Cover the essentials, then expand.
The service your users hit
Add an HTTP monitor on your main URL. Use a keyword
check so a page that returns 200 but shows an error still counts as down.
Your SSL certificate
Add an SSL certificate monitor so you're warned weeks before expiry — not by a browser security warning your customers see first.
The machine behind it
Turn on resource metrics for the server so CPU, RAM and disk trends are visible. See Reading server metrics for what the numbers mean.
The dependencies
Databases, caches, message queues, third-party APIs — a TCP/port monitor on each confirms the thing your app depends on is actually listening.
Setting thresholds that mean something
A threshold that fires constantly is noise; one that never fires is decoration. Aim for the middle.
| Signal | Reasonable starting point | Why |
|---|---|---|
| CPU | Alert on sustained high load, not brief spikes | Short bursts are normal; a pinned CPU for minutes is not |
| RAM | Watch the trend, alert near capacity | A slow climb often means a leak — catch it early |
| Disk | Alert well before full (leave headroom) | A full disk takes services down hard and is slow to recover |
| Uptime check | A short check interval for critical services | Faster checks detect outages sooner |
Duration beats instant
Wherever you can, alert on a condition that persists rather than a single bad reading. "CPU high for several minutes" is a real problem; "CPU high for one check" is often just a cron job. Set server thresholds from the server settings (gear icon → surveillance thresholds).
Avoiding alert fatigue
Alert fatigue is the real failure mode of monitoring: when everything pings, people stop reading pings, and the one that mattered gets missed. Keep alerts scarce and trustworthy.
- Alert on symptoms, not every cause. One clear "the site is down" beats five alerts for each sub-component that went with it.
- Use cooldowns. Notification channels support a cooldown so a flapping service doesn't send fifty messages in a minute.
- Route by urgency. Send critical, wake-someone-up alerts to a channel people actually watch; send informational ones somewhere quieter. Email, Slack, Discord and Webhook are all available as channels.
- Tune, don't mute. If an alert keeps crying wolf, fix the threshold or the underlying flap. Muting a noisy alert trains you to ignore a real one later.
- Review regularly. Every alert that fired and didn't need action is a candidate to loosen. Every incident you found out about from a user is a monitor you were missing.
One channel is a single point of failure
If every alert goes to one inbox and that inbox is muted on the weekend, your monitoring is off on the weekend. Configure at least two notification channels for anything critical. Configure notification channels in Servor
Close the loop with status pages and incidents
Monitoring that only pings your team is half a system. When something breaks:
- A status page with components linked to your monitors updates automatically, so users see the truth without emailing support.
- Automatic incidents can open from a monitor's down transition, giving you a public timeline from the moment things went wrong.
- The AI copilot can investigate a flagged server and propose a fix, which you approve before it runs.