RED Method

Overview

RED was popularized by Tom Wilkie for microservices. It keeps only the three measurements that describe a request-serving service from the caller's point of view: Rate, Errors, Duration. It is a subset of the golden signals, tuned for services rather than infrastructure.

How it works

Middleware or a mesh sidecar wraps every handler and updates three metrics:

http_requests_total{service,route,method,code}      # Rate and Errors
http_request_duration_seconds_bucket{service,route} # Duration

Rate     = sum(rate(http_requests_total[1m])) by (service)
Errors   = sum(rate(http_requests_total{code=~"5.."}[1m]))
           / Rate
Duration = histogram_quantile(0.95,
           sum(rate(http_request_duration_seconds_bucket[5m])) by (le,service))

A single dashboard row per service shows the three graphs. When a RED graph degrades, the on-call engineer pivots to the resources behind the service using the USE method, and to traces for individual slow requests.

Pitfalls

• Using the raw URL as a label. Use the route template such as /users/:id, or the metric explodes in cardinality.
• Counting every 4xx as an error. Client mistakes should not page the service owner; count 5xx and timeouts.
• Measuring duration only inside the handler. Time spent queued before the handler runs is invisible, so measure at the load balancer or mesh as well.
• Using summaries instead of histograms. Summaries cannot be aggregated across instances.

Key takeaways

• RED is the service-level counterpart to USE.
• Provide it by default via middleware so every service has it on day one.
• Use histograms and route templates.
• Pair with USE for diagnosis and with SLOs for targets.
• Alert on RED at the service boundary and keep per-route graphs for diagnosis.