RED Method

Tom Wilkie (creator of Grafana Loki, VP of product at Grafana) proposed the RED method because the traditional server-centric monitoring approach doesn't work well for microservices. When your application is a fleet of stateless containers, you don't care about individual server CPU, you care about whether the service is handling requests correctly.

RED stands for Rate, Errors, Duration, three metrics for every service. That's it. No infrastructure metrics, no resource utilization, no complex dashboards. Just the three numbers that tell you whether the service is doing its job from the user's perspective.

RED's strength is its simplicity. A junior engineer can understand and apply it in an afternoon. A senior engineer can use it to build a monitoring strategy for 200 microservices in a week. It's the minimum viable monitoring that actually works.

RED is the golden signals minus saturation. The golden signals include saturation (resource usage). RED intentionally excludes it because, for stateless services behind auto-scalers, saturation is an infrastructure concern, the platform handles it. RED focuses purely on the user-facing behavior.

Apply RED to every service boundary. Each microservice gets its own RED metrics. The API gateway has its RED. The auth service has its RED. The payment service has its RED. When something goes wrong, you look at RED across all services and immediately spot which one is misbehaving.

RED and the golden signals aren't competitors. RED is best for request-driven services (APIs, web apps, microservices). The golden signals (which add saturation) are better when you also manage infrastructure. Many teams use RED for services and USE (next lesson) for infrastructure.