"RED Metrics" is a framework for monitoring the health of request-driven services using three signals: Requests, Errors, and Duration.

Background

Introduced by Tom Wilkie in 2015 at Weaveworks, RED shifts the focus of monitoring from infrastructure to the experience of service consumers. Where the older USE method (Utilisation, Saturation, Errors) asks "is my infrastructure healthy?", RED asks "is my service serving users well?".

Each signal points to a different class of problem. A spike in Requests with stable Errors and Duration suggests healthy growth. A spike in Errors alone points to a bug or dependency failure. A spike in Duration with stable Requests and Errors suggests a performance regression.

RED is service-agnostic — the same three signals apply equally to an HTTP API, a gRPC service, a message queue consumer, or a database query handler, making it a natural fit for microservices architectures.

The Three Signals

Signal	Question it answers	Typical unit
Request	How many requests per second is this service handling?	Requests/s
Errors	What fraction of those requests are failing?	Error rate (%)
Duration	How long are requests taking?	Latency (ms), as percentiles

Relationship to Other Methodologies

RED is complementary to other observability frameworks rather than a replacement for them.

Method	Signals	Best for
RED	Rate, Errors, Duration	Request-driven services
USE	Utilisation, Saturation, Errors	Infrastructure resources (CPU, disk, network)
Four Golden Signals	Latency, Traffic, Errors, Saturation	Full-stack observability (RED + saturation)

Google's Four Golden Signals, from the Site Reliability Engineering book, are essentially RED with saturation added. When a RED alert fires, USE metrics on the underlying infrastructure help determine whether the root cause is a service-level issue or a resource constraint.