The RED Method
The RED method instruments every service with rate, errors, and duration — three golden metrics that answer is it up, is it failing, is it slow — for request-driven endpoints.
Definition
RED prescribes the minimal per-endpoint metric set: request rate (throughput), error rate (failed fraction), and duration distribution (latency, never averaged — histogrammed). The three compose into dashboards and alerts covering availability and performance of any request-driven service, complementing USE which targets resource metrics.
Context and scope
Applied as the default service dashboard template in Prometheus-based monitoring. Coined by Tom Wilkie as the service-side counterpart of the four golden signals.
Common misconceptions
- RED covers everything observable — it covers service request health; saturation, capacity, and dependencies need USE and tracing
- Average duration is acceptable — averages hide the tail; duration must be a histogram or the slow-people problem is invisible
- Error rate should count 5xx only — business errors in 200 responses — declined payments, empty results — are user-visible failures worth counting
Anti-patterns
- Averaging latency into a gauge and alerting on a metric that cannot see the tail
- Instrumenting only external endpoints and flying blind on internal service dependencies
- Counting errors without dividing by rate — absolute error counts mislead under traffic changes
Related concepts
Related examples
Authoritative source
What it is
Every service dashboard needs a starting template. RED is that template for request workloads: three metrics, each answering one user-relevant question, composable into error rate per second and latency percentiles.
How it works
Instrumentation emits a request counter (by route and status class), an error counter, and a duration histogram per endpoint. Rate divides the counters over time; the histogram yields p50, p95, p99. Alerts compose: high error rate, rising p99, throughput anomalies. Dashboards stack these three rows per service.
When to apply
As the default for every request-driven service — HTTP, RPC, queue consumers measured in messages processed. Resource-focused components — databases, caches — add USE (utilization, saturation, errors) alongside.
Pitfalls
RED measures the service in isolation: upstream degradation appears as your errors until traces attribute causality. Route label cardinality needs templating — raw paths explode series. Queue consumers need redefining “request” as message batch, or throughput metrics mislead.