How to Monitor a Server: What to Watch and Which Tools to Use

The worst way to learn that your site is down is from a customer. Monitoring means measuring your server regularly and getting a message when something looks wrong, ideally before it becomes an outage. You do not need an enterprise setup to do this well. A few well-chosen checks, a simple tool and sensible alert thresholds cover most small servers.

What is worth watching

Start with the things that fail most often:

• Availability: does the site respond, from outside your network, with the right content?
• Disk space and inodes: a full disk breaks databases, logs, uploads and package updates. Running out of inodes (file entries) causes the same symptoms even with free space.
• Memory: a server that runs out of RAM starts swapping or has processes killed by the kernel.
• CPU and load: sustained high usage means requests queue up.
• Key services: web server, PHP-FPM or your app, database, mail queue if you run mail.
• Certificates: an expired HTTPS certificate makes browsers block your site.
• Backups: a job that has quietly stopped is invisible until you need it.

Before choosing thresholds, learn what normal looks like for your server. A database host that always uses 70% of its memory for caching is healthy; the same figure on a server where it climbs steadily every day is not. A week of recorded numbers is worth more than any rule of thumb.

Quick manual checks

These commands give an instant picture and are useful when investigating:

uptime
free -h
df -h
df -i
top        # or htop, if installed
sudo ss -tulpn
systemctl --failed

uptime prints three load averages (1, 5 and 15 minutes). Compare them with the number of CPU cores from nproc: on a 2-core machine a sustained load around 2 means the cores are busy, while values well above that mean work is waiting. free -h shows memory; look at the "available" column rather than "free", because Linux uses spare memory for caching. systemctl --failed lists services that crashed.

External uptime monitoring

Checks that run on the server itself cannot tell you that the server is unreachable. Use at least one monitor that runs from somewhere else and requests your site every minute or few minutes. Many hosted services offer free tiers, and you can self-host tools such as Uptime Kuma on a different machine. Configure the check to look for a word on the page, not only a 200 status code, because an error page can still return 200. Send alerts to a channel you actually read, and add a second contact method for serious outages.

Metrics and dashboards

For trends, such as "memory use creeps up every day", install a metrics tool. Common choices:

• Netdata installs quickly and shows detailed live charts with little configuration.
• Prometheus with node_exporter and Grafana is a popular open-source combination that scales from one server to many, with more setup work.
• Zabbix and Nagios-style tools are full monitoring platforms with checks and alerting.
• Your provider's panel may show basic graphs; useful, but they usually do not alert on application problems.

Whichever you choose, remember that the monitoring tool itself uses resources and has its own security surface. Do not expose dashboards publicly without authentication, and keep them updated like any other software.

A simple do-it-yourself alert

A tiny script run from cron can warn you about disk space. This sketch sends an email, so it requires that the server can send mail (a working mail command and a configured relay):

#!/bin/bash
USED=$(df --output=pcent / | tail -1 | tr -dc '0-9')
if [ "$USED" -gt 85 ]; then
  echo "Disk is ${USED}% full on $(hostname)" | mail -s "Disk warning" [email protected]
fi

Schedule it hourly. To read when a site's certificate expires, this command prints the end date (replace the domain with yours):

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -enddate

The same pattern works for memory, certificates and backup freshness, for example by checking that the newest backup file is less than a day old. A script that tells you a backup is missing is more valuable than one that reports success.

Alerts people do not ignore

Too many alerts teach you to ignore all of them. Set thresholds that need action: warn at 80% disk, alarm at 90%, rather than reacting to a one-minute CPU spike. Require a problem to persist for a few minutes before alerting. Write down what to do for each alert (a short runbook), so a 3 a.m. message leads to a clear first step. Review alerts now and then and remove the ones that never lead to action.

Monitoring a site, not just a server

A healthy server can still host a broken site. Add a synthetic check that exercises something real: log in with a test account, load a product page, or submit a search. Check that your SSL certificate is valid and that DNS answers correctly, since a lapsed domain or wrong record takes a site offline no matter how healthy the machine is. Watch response time as well as availability: a page that takes eight seconds to load is "up" but is losing visitors. If you use a CDN, remember that it may serve cached copies while your origin is struggling, so test the origin directly too. The CDN page explains how a CDN sits in front of your site.

Monitoring on Zebra Hosting

On a self-managed server the monitoring setup is yours to choose, and a VPS gives you the access to install any of the tools above. If you want the infrastructure managed for you, our Plesk-based plans handle the server layer.