The four golden signals of monitoring

Quick reference

Status: What good monitoring measures

Explained

Latency: how long requests take. Measure it at a percentile, like p95 or p99, not an average, because averages hide the slow tail that real users feel. And separate successful from failed requests, since a fast error is still an error.

Traffic: how much demand the system is under, such as requests per second. On its own it is just a number, but next to the others it gives meaning. A spike in latency during a traffic spike is capacity; a spike in latency with flat traffic is a problem.

Errors: the rate of failed requests, as a share of the total. This is the most direct signal that something is broken. Watch both obvious failures, like HTTP 500s, and silent ones, like wrong responses with a 200 status.

Saturation: how full the system is, the resource closest to its limit, whether that is CPU, memory, disk or a connection pool. Saturation is a leading indicator: it climbs before latency and errors do, giving you warning.

Why four and not forty: a wall of CPU and memory graphs tells you how the machine feels. These four tell you how the user feels, and that is what an alert should be about.

The practical rule: alert on symptoms users notice, like latency and errors against your SLO, and use saturation to see trouble coming.

In one line

The four: latency, traffic, errors, saturation