Faced with a new service and the question “what should we actually monitor,” it’s easy to end up either monitoring too little (missing real problems) or too much (drowning in low-value metrics, contributing directly to alert fatigue). The four golden signals are a deliberately minimal starting framework for avoiding both failure modes.
Where the framework comes from
The four golden signals — latency, traffic, errors, and saturation — come from Google’s Site Reliability Engineering practice, laid out in the monitoring distributed systems chapter of the SRE book. The book frames them explicitly as a starting point, not an exhaustive list: if you can only measure four things about a user-facing system, these are the four most likely to actually matter.
Latency: how long requests take
Latency measures the time it takes to service a request. The SRE book makes a specific, important refinement here: it’s important to distinguish the latency of successful requests from the latency of failed ones, because a request that fails instantly can pull down an average latency number in a misleading way, making a system that’s actually failing look artificially fast on a naive latency dashboard. Tracking latency percentiles (how slow the slowest 1% or 5% of requests are, not just the average) is generally more useful than a single mean value, since a small share of very slow requests can represent a real, painful experience for real users while barely moving an average.
Traffic: how much demand the system is under
Traffic measures the demand being placed on a system — requests per second for a web service, for example. On its own, traffic isn’t a health signal, but it’s essential context for interpreting the other three: an elevated error rate at unusually high traffic tells a different story than the same error rate at normal traffic, and knowing current traffic relative to historical patterns is often the first clue that something unusual is happening at all.
Errors: how often requests fail
Errors measures the rate of requests that fail, whether through an explicit error response or, more subtly, a response that returns successfully but with the wrong content or an incomplete result — a failure mode that’s easy to miss if “error rate” is defined too narrowly as just HTTP error status codes. This is also the signal most directly tied to the SLIs and error budgets many teams build their reliability targets around.
Saturation: how close to capacity the system is
Saturation measures how “full” a system is relative to its capacity — how close a resource (CPU, memory, disk I/O, a connection pool) is to its limit. Saturation is often the earliest available warning sign of a problem, because a system frequently starts degrading in latency and error rate specifically once it approaches a saturation limit, which makes saturation a leading indicator worth watching, rather than only reacting once the other three signals have already worsened.
Why these four, specifically
The four signals were chosen because, together, they cover the questions that matter most for a user-facing service without requiring exhaustive, low-level instrumentation of every internal component from day one: is the system slow (latency), how much load is it handling (traffic), is it failing (errors), and is it approaching its limits (saturation). A team can meaningfully assess a service’s health from these four alone, and add more specific, deeper instrumentation — the distributed tracing needed to pinpoint exactly where in a multi-service request a problem originates, for instance — once these baseline signals indicate something is actually wrong. How these four signals actually get measured matters too: synthetic monitoring and real user monitoring capture them in genuinely different ways, and a mature setup generally uses both.
A starting point, not a ceiling
The four golden signals are explicitly a floor, not a complete monitoring strategy — plenty of systems need more specific signals beyond these four to fully understand their particular failure modes. Their real value is as a discipline for prioritization: before adding more specific metrics, make sure these four foundational ones are actually covered, well-defined, and tied to something meaningful for the specific service in question.
Key takeaway
Latency, traffic, errors, and saturation form a deliberately minimal, practical starting point for monitoring any user-facing service — covering speed, load, failure rate, and capacity headroom respectively. Treating these four as the non-negotiable baseline, and building more specific monitoring on top of them once they’re solid, tends to produce a more disciplined and more useful monitoring setup than accumulating whatever metrics happened to be easy to collect first.
This article explains a general monitoring framework; specific metrics and thresholds should be tailored to your system. See our disclaimer.