What is Golden Signals?

#What each signal measures

Latency is how long requests take, measured at percentiles and split between successful and failed requests, since fast failures can otherwise flatter the number. Traffic is demand: requests per second, transactions, or connections.

Errors is the rate of failed requests, including explicit failures, wrong responses, and successes that violated a latency requirement. Saturation is how full the constrained resource is, whether that is CPU, memory, connections, or queue depth, and it is the leading indicator among the four.

#Why the golden signals work

They cover the space of what can go wrong with a request driven service without requiring you to anticipate specific failure modes.

• Symptom oriented: they measure what users experience rather than internal causes.
• Universally applicable: the same four apply to any request serving system.
• Small enough to act on: four signals fit on one dashboard and in one mental model.
• Alerting foundation: alerting on these four produces far less noise than alerting on causes.

#Limits

The golden signals describe request driven services well and fit other workloads poorly. Batch pipelines, streaming systems, and asynchronous queues need different signals such as lag, throughput, and freshness.

They also describe symptoms rather than causes. Elevated latency and errors tell you something is wrong and not what, so they are the right basis for alerting and an insufficient basis for diagnosis, which needs traces, logs, and dependency detail.

#Golden signals vs the RED and USE methods

The RED method covers rate, errors, and duration, which is the golden signals minus saturation, and it is oriented toward request driven services. The USE method covers utilization, saturation, and errors, and it is oriented toward resources such as CPUs, disks, and network interfaces.

The golden signals effectively span both: latency, traffic, and errors describe the service, saturation describes the resource. In practice teams apply RED to services and USE to the infrastructure underneath them, which reaches the same coverage from two directions.

#Key takeaways

• The four signals are latency, traffic, errors, and saturation, and they cover request driven services well.
• Latency should be split between successful and failed requests, since fast failures otherwise flatter the number.
• Saturation is the leading indicator, since it rises before the other three degrade.
• They are the right basis for alerting and insufficient for diagnosis, which needs traces and logs.

#Frequently asked

If you can only measure one signal, which one?

Error rate. It most directly indicates that users are not getting what they asked for.

Why split latency by success and failure?

Failed requests often return quickly. Including them pulls the latency figure down and can hide a genuine slowdown in successful requests.

Do the golden signals apply to batch systems?

Poorly. Batch and streaming workloads need lag, throughput, and data freshness instead.

#Sources

• Google SRE: monitoring distributed systems