# 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.

Source: https://openobserve.ai/glossary/four-golden-signals/
Published: 2026-07-08
Term: Four Golden Signals
Category: Metrics & Monitoring
Related terms: slo-sla-sli, what-is-observability, mttr-vs-mttd, what-is-apm

---

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](/glossary/slo-sla-sli/).

**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](/blog/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](/metrics/) automatically, and its [dashboards](/visualization-and-dashboards/) and alerting let you standardize a golden-signals view across every service - with [SLO-based alerting](/blog/slo-based-alerting/) on top.