Server Monitoring: What to Watch on a Single Server
You do not need an observability platform to run one server. You do need four alerts, and one of them prevents most outages.
Monitoring guidance is mostly written for large systems, which makes it
intimidating and largely irrelevant if you run one or two servers. For a small
deployment the useful version is short: a few alerts that reach a person, and
enough history to answer “when did this start”.
The four alerts that matter
Disk space
Put this first because it causes more small-server outages than anything
else, and because it is entirely preventable. A full disk stops the database
accepting writes, stops the application logging, and frequently prevents you
from logging in to fix it.
Alert at eighty percent, which leaves time to act, and again at ninety. The
usual culprits are log files nobody rotates, package caches and old backups
written to the same volume as the application.
The service is responding
Not “the server is up”. A machine can respond to a ping while the application
on it returns errors. Check the thing users actually depend on: request a real
URL, from outside the server, and verify both the status code and that the
response looks right.
Checking from outside matters. A check running on the same machine cannot
tell you that the machine is unreachable.
Memory
Memory is usually the binding constraint on a small server, and exhaustion is
not graceful: processes get killed, or the system starts swapping and becomes
effectively unavailable while still technically running.
Alert on sustained high usage rather than brief spikes, and watch swap
activity, which is often the earlier signal.
Certificate expiry
An expired TLS certificate is a complete outage with a known date. Automated
renewal usually works, and the failure mode is that it silently stops working
months before the expiry. Alert at two weeks remaining, which is enough time to
fix a broken renewal calmly.
Worth watching, not worth paging about
CPU is the metric people instinctively watch first and it is rarely the
problem. High CPU on a web server often means it is working. Look at it when
diagnosing, but do not wake anyone for it.
Request latency and error rates are more useful than resource metrics,
because they describe what users experience. If you only have the appetite for
one application-level metric, make it the error rate.
Backup job success belongs here too. Silent backup failure is the normal
failure mode, which is covered in
backups: what your provider
does not do for you.
Keep some history
Alerts tell you something is wrong now. History tells you when it started and
what changed, which is usually the faster route to the cause.
A few weeks of basic resource metrics is enough. The questions you will
actually ask are “was this gradual or sudden” and “did it begin when we
deployed”, and both need only modest retention to answer.
Where the alert goes
This decides whether monitoring works. An alert to an unread mailbox is
documentation of a failure rather than a warning about one.
Send alerts somewhere a person will see them within minutes: a phone
notification, or a chat channel people actually watch. Have a second recipient,
because one person is always unavailable.
And tune the volume. A monitoring system that cries wolf gets muted, and a
muted system is worse than none because it creates false confidence. If an alert
fires regularly and nobody acts on it, either fix the underlying issue or delete
the alert.
What to use
Most providers include basic monitoring with alerting on CPU, memory, disk
and instance health. For a single server this is frequently sufficient and costs
nothing extra, which makes it the right starting point.
Add an external uptime checker, since several good ones are free at small
scale and they catch the case where the whole machine or its network is
unreachable.
Running your own monitoring stack is a reasonable thing to do and a
substantial thing to maintain. For one server it is usually the wrong trade:
you have added a second system that can fail, to watch the first.
A sensible starting point
- Provider alerts on disk, memory and instance health, pointed at a phone.
- An external check on a real application URL, every minute.
- Certificate expiry monitoring.
- An alert when a backup job fails.
- Log rotation configured, so disk alerts stay rare.
That is an hour of setup and it covers the failures that actually happen to
small deployments.