What is the RED method for monitoring microservices?

The RED method, introduced by Tom Wilkie, defines three golden signals specifically suited to request-driven microservices:

R — Rate: The number of requests per second the service is receiving. This tells you about load and traffic patterns. Sudden drops can indicate that upstream services stopped calling — often a sign of their own failure.

E — Errors: The number of failed requests per second (or as a percentage of total requests). This directly reflects user impact. Separate 4xx client errors from 5xx server errors because they have different root-cause implications.

D — Duration: The distribution of latency for requests — specifically, percentiles (p50, p95, p99). Averages hide tail latency; the 99th percentile often reflects the experience of your most valuable users or the slowest database queries.

The RED method maps naturally to HTTP services, gRPC endpoints, and message consumers. It complements the USE method (Utilization, Saturation, Errors), which is better for resource-level monitoring (CPU, disk, network). In a mature microservices setup, you apply RED at every service boundary and USE to every infrastructure resource they depend on.