Monitoring your server

Module 8: Backups and monitoring · Reading time: 10 minutes

Learning objective: After this lesson you can decide what to monitor on your server (from the outside and from the inside), which thresholds make sense, and how to make sure an alert really reaches you without drowning in alerts.

Key concepts: external monitoring, internal monitoring, uptime, http check, port check, certificate expiry, disk space, memory, load, heartbeat (dead man's switch), threshold, alert channel, alert fatigue, your provider's graphs

Why monitor?

Without monitoring, you hear about problems from your customers, or not at all. A website that has been down since Saturday, a certificate that expired, a disk that filled up, a backup that has been failing silently for three weeks: all things you could have spotted in time. Monitoring means a program watches continuously and warns you when something is wrong.

Good monitoring answers two questions:

1. Does it work for the user? You measure that from the outside.
2. Is something about to go wrong? You measure that from the inside: disk, memory, updates, backups.

From the outside: what the user sees

External monitoring runs on a different machine from your server, preferably at a different provider. That makes sense: if your server is down, it can no longer warn you itself.

The certificate deserves extra attention. Let's Encrypt certificates are valid for a short time and are renewed automatically (lesson 7.3), but if renewal fails silently, you only notice when visitors get a warning. Since June 2025, Let's Encrypt no longer sends reminder emails about expiring certificates, and recommends monitoring instead. A certificate check that warns when less than 14 days of validity remain is therefore no luxury.

A common program for doing this yourself is Uptime Kuma, which you will install in a container in lesson 9.4. Preferably don't put it on the same server it is supposed to monitor, or combine it with a second, external check. There are also third-party services that do the same; choose one that suits you, and check where they are based if your customers' data could end up in alerts.

From the inside: what is about to go wrong

Some problems are only visible from the outside when it is too late. You measure those on the server itself:

You can do this with a simple script and a timer (lesson 6.3) that sends an alert when a threshold is exceeded, or with a monitoring program that runs an agent on the server (well-known open-source examples are Netdata and the combination of Prometheus with node_exporter). Start small: disk, failed services and backups catch most problems.

The graphs in your provider's control panel (processor, memory, network, disk over a day up to a year) are a fine addition for spotting trends: if your disk grows by a few per cent every month, you know when it will be full. At WebOké you find them on the VPS screen; other providers have something similar. They usually don't send alerts, so they don't replace monitoring.

The heartbeat: alerting when nothing happens

Some things you need to monitor precisely for the absence of a signal. Last night's backup is the best example: if the script doesn't even start (timer off, server off, script broken), there is no error message either.

The solution is called a heartbeat or dead man's switch: your monitoring expects a signal every day. At the end, and only if everything succeeded, the backup script sends a small http request to a fixed, secret URL of your monitoring:

restic backup ... && restic check && curl -fsS -m 10 https://status.example.com/api/push/Xyz123abc?status=up >/dev/null

If the signal doesn't arrive one day, you get an alert. Uptime Kuma has the Push monitor type for this; there are also self-hostable programs such as Healthchecks. With a single line, you monitor whether your backup really ran.

Alerts that arrive, but not too many

An alert that nobody reads is not monitoring. Sort out three things:

1. An alert channel you really see: a push notification on your phone, a chat channel, a text message. Email is possible, but only if your server can send mail reliably, and email is easily overlooked. Use two channels for the most important alerts.
2. Not dependent on what you are monitoring. If your server sends the email about a full disk itself, that email won't arrive when the disk is full. External monitoring and a heartbeat cover this.
3. Few, but justified. If you get ten alerts a day that you do nothing with, you will start ignoring them, including the one that matters. That is called alert fatigue. Set thresholds so that an alert means: you need to act. Only trigger an alert after several failed checks in a row (three, for example), so that a single lost packet doesn't wake you up.

Test your alerts: briefly stop a service and see whether the alert arrives, and how long it took.

What not to do

• Monitoring pages open to everyone showing internal names and addresses. A public status page is fine, but only show what visitors are allowed to know.
• An admin account for your monitoring without a strong password and 2FA. Anyone who gets into your monitoring can switch alerts off.
• Agents with more privileges than needed. A monitoring agent usually doesn't need to be root.

Summary

• Monitor from the outside whether it works (http, port, certificate, DNS), from a different machine, and from the inside whether something is about to go wrong (disk, memory, services, updates, backups).
• Certificates deserve their own check: since June 2025, Let's Encrypt no longer sends reminder emails.
• A heartbeat alerts you when a signal fails to arrive; ideal for backups and scheduled tasks.
• Choose an alert channel you really see, independent of the server itself, and set thresholds so that every alert calls for action.
• Your provider's graphs show trends, but usually don't send alerts.

Quiz

Exercise

Exercise O8.3: Your monitoring list. Make a monitoring list for your own server: which external checks (at what interval and from where), which internal checks (with thresholds), which heartbeat(s), and which channel the alerts come through. Set up at least one external http or certificate check and one heartbeat (for your backup, for example), and test the alert by briefly stopping a service. Write down how long it took for the alert to arrive.

Further reading

• No access to your VPS anymore: what now?
• Let's Encrypt, Expiration Notification Service Has Ended: https://letsencrypt.org/2025/06/26/expiration-notification-service-has-ended
• Uptime Kuma (GitHub): https://github.com/louislam/uptime-kuma