Golden Signals: The Four SRE Metrics That Matter

Golden signals are the four metrics Google's SRE team watches when it can only watch four: latency, traffic, errors and saturation. They describe what a user feels rather than what a server reports, which is why they surface user-facing problems that a CPU graph misses completely.

What do the four signals measure?

The four golden signals are latency, traffic, errors and saturation. Google introduced them in chapter 6 of the Site Reliability Engineering book as the minimum useful set for any user-facing system. Each answers a different question about behaviour under real load.

Signal	Question it answers	Typical unit
Latency	How long does a request take?	milliseconds, p50/p95/p99
Traffic	How much demand is arriving?	requests per second
Errors	What share of requests fail?	percentage of 5xx or failed assertions
Saturation	How full is the constrained resource?	percentage of a limit

Saturation is the one teams skip. It is also the one that predicts the others: a queue at 90 percent depth raises latency long before it raises errors.

Why does latency have to be split by outcome?

Latency must be measured separately for successful and failed requests, because a fast failure flatters your average. A server that returns 500 in 3 milliseconds drags a blended p95 down and makes a degrading service look healthy. Google's own guidance is explicit about this split, and it is the most common mistake in a first dashboard.

Track the success distribution as your service level indicator. Track error latency separately as a debugging aid. If you keep only one, keep the successful-request percentile.

How do the golden signals compare to RED and USE?

RED (rate, errors, duration) drops saturation and aims at request-driven services. USE (utilisation, saturation, errors) is resource-shaped and aims at machines rather than requests. Sysdig's write-up maps all three onto Kubernetes workloads if you need the translation.

We prefer one vocabulary per team and stop there. RED for services and USE for nodes is a reasonable split. Running all three with overlapping dashboards is how alert fatigue starts, and the cure is covered in cross-region quorum confirmation.

Which signals can an external check actually see?

An outside-in check measures latency and errors directly, infers traffic poorly, and cannot see saturation at all. That is an honest limitation. Queue depth, heap usage and connection-pool pressure are only visible from inside the process, so saturation needs an in-process agent rather than an external probe.

What the outside view adds is the user's real latency, including the parts your application never times. An HTTP check reports a full timing waterfall: DNS resolution, TCP connect, TLS handshake, TTFB and content download. A slow result can then be blamed on a certificate chain or a resolver rather than your code.

Turning signals into checks

Latency and errors map onto a single API monitor with a response-time assertion. This one fails when the endpoint stops returning 200. It warns separately when the successful path gets slow:

curl -X POST https://uptimeroom.com/api/v1/monitors \
  -H "Authorization: Bearer urm_live_..." \
  -H "Content-Type: application/json" \
  -d '{
    "name": "checkout api",
    "type": "api",
    "target": "https://example.com/api/checkout/health",
    "intervalSec": 60,
    "regions": ["london", "singapore"],
    "expectedStatus": [200],
    "responseTimeThresholdMs": 800
  }'

Run it from at least two of the six probe regions available as of September 2026. One slow network path should not read as a latency regression. If you need to allowlist the checks at your edge, the probe IPs page lists every region code and its egress address.

Common mistakes

Alerting on all four signals equally. Latency and errors are symptoms users feel. Saturation is a leading indicator for humans to read, not a pager trigger. Page on the first two and graph the rest.

Using an average instead of a percentile. An average hides the tail where your unhappiest users live. Keep p95 and p99; response-time history retains p50, p95 and p99 per monitor.

Treating one failed check as an error rate. A single probe failure is a blip, not an incident. Confirm from a second region before anyone gets paged.

This framework is worth adopting precisely because it is small. Start with success latency and error rate on your most important endpoint, add traffic once you trust the numbers, and leave saturation to whatever runs inside your process. The golden signals that matter most are measurable in a few minutes on the free plan, which includes 10 monitors and cross-region confirmation.