Monitoring everything produces alerts nobody reads, which is the same as monitoring nothing. Five signals cover almost every outage, and each has a level that leaves time to act rather than telling you it already happened.

The five

  • Disk, at 80%. Not 95. A disk that fills overnight takes the site down until someone wakes up; 80% is a task for the morning.
  • Memory, when swap starts being used. Swap in use means the box is thrashing and everything is already slow.
  • Load, against your core count. Alert at twice the cores sustained for five minutes - a spike is normal, a plateau is not.
  • Certificate expiry, at 21 days. Renewal runs at 30; if it has not happened by 21 something is blocking it.
  • The site itself, from outside. Every service can be green while the page returns 500.

From outside, not from the server

A check that runs on the machine it is checking cannot tell you the machine is unreachable. The most important check is an HTTP request from somewhere else, for a specific string on the page - not just a 200.

curl -fsS --max-time 10 https://yourdomain.com/ | grep -q 'Sign in' || alert

Keep alerts worth reading

An alert that fires every day and is ignored every day is worse than no alert: it teaches everyone to ignore the channel, including on the day it matters. If something fires and you do nothing, either fix the cause or delete the alert.

Watch the trend, not only the threshold

Disk at 60% is fine. Disk that was 40% last week is not - it will be full in a fortnight. A graph answers "when", which a threshold never does.

EGPNL shows CPU, memory, disk and traffic per server with history. Managed plans add the outside check and the on-call response, which is the part that cannot be automated.