Upcoming Webinar:

Getting Started with OpenObserve

July 16, 2026
11:00 AM ET

What are the Four Golden Signals?

The four golden signals — latency, traffic, errors, and saturation — are Google SRE's recommended minimum set of metrics for monitoring any user-facing system.

Metrics & Monitoring

The four golden signals are the four metrics Google’s Site Reliability Engineering book recommends as the minimum viable monitoring for any user-facing system: latency, traffic, errors, and saturation. If you can only measure four things about a service, measure these.

The signals

1. Latency — how long requests take. Track the full distribution (p50/p95/p99), not averages, and track failed-request latency separately: a fast error storm and a slow success path are different incidents.

2. Traffic — how much demand the system is serving: requests per second, messages consumed, sessions, streams. Traffic contextualizes every other signal — an error-rate change means something different at 10x normal load.

3. Errors — the rate of failed requests: explicit (HTTP 500s), implicit (wrong content, degraded responses), and policy failures (responses slower than the SLO). Errors are the signal most directly tied to user pain and to your SLOs.

4. Saturation — how “full” the system is: memory pressure, connection-pool usage, queue depth, disk. Systems degrade before hitting 100%, so saturation is your leading indicator; the other three are trailing.

Golden signals vs RED vs USE

  • RED (Rate, Errors, Duration) — golden signals minus saturation; the standard for request-driven microservices. See RED metrics monitoring.
  • USE (Utilization, Saturation, Errors) — for hardware and infrastructure resources.
  • Golden signals — the union: user-facing symptoms plus capacity pressure.

Putting them into practice

Instrument every service so the four signals exist per endpoint (OpenTelemetry auto-instrumentation gives you this nearly free), build one standard dashboard per service, and alert on symptoms (latency, errors) rather than causes — a saturation alert should page only when it predicts imminent user impact.

Golden signals in OpenObserve

OpenObserve derives all four signals from OTLP traces and metrics automatically, and its dashboards and alerting let you standardize a golden-signals view across every service — with SLO-based alerting on top.

Frequently asked questions

What is the difference between the four golden signals and RED metrics?

RED (Rate, Errors, Duration) is a simplification of the golden signals for request-driven services — it drops saturation. USE (Utilization, Saturation, Errors) covers infrastructure resources. The golden signals combine both perspectives; RED is usually the practical starting point for microservices.

Why is saturation the hardest signal to monitor?

Latency, traffic, and errors can be measured directly from requests. Saturation requires knowing each resource's capacity limit — connection pools, memory, queue depth, disk — and how close you are to it. Systems often degrade before reaching 100%, so good saturation monitoring uses leading indicators like queue depth or p99 latency inflection.

Related terms

Keep reading

See these concepts in action

OpenObserve unifies logs, metrics, traces, and frontend monitoring in one open-source platform — at a fraction of the cost of legacy tools.

Book a DemoBook a Demo