You've probably drowned in dashboards with fifty graphs where nobody can tell you what "healthy" looks like. The RED Method, coined by Tom Wilkes at Weaveworks, cuts through the noise: for every request-driven service, track exactly three things — Rate, Errors, and Duration.

• Rate: requests per second the service is handling.
• Errors: requests per second that failed (5xx, exceptions, timeouts).
• Duration: distribution of how long requests take — measured in percentiles, never averages.

Why these three? Because they cover the two questions users actually ask: "Is it working?" (errors) and "Is it fast?" (duration), plus the context needed to interpret both (rate). An error rate of 100 errors/sec sounds terrible until you learn the service is doing 1M requests/sec — that's 0.01%.

Real-world example: A checkout service starts paging on-call at 2 AM. The old dashboard shows CPU at 60%, memory stable, network fine — nothing wrong. The RED dashboard shows: rate dropped 40% (fewer requests), errors flat, but p99 duration jumped from 200ms to 4s. That points immediately at a downstream dependency slowing down, not the service itself. Users are timing out client-side, which is why rate fell. You'd never see that in resource metrics.

Percentiles matter, averages lie. If p50 is 100ms and p99 is 3s, the "average" is meaningless — half your users are fine, 1% are miserable, and if those 1% are your highest-value customers you have a business problem disguised as a performance one. Always alert on p95 or p99, never on mean.

Rule of thumb — the SLO triangle: pick an availability target (e.g., 99.9% success) and a latency target (e.g., p99 < 300ms), then let your error budget = (1 - availability) × request rate × time window. At 1000 req/s and 99.9% availability over 30 days, you get roughly 2.6M allowed errors per month. If you're burning through that in 3 days, stop shipping features and fix reliability.

RED complements the USE Method (utilization, saturation, errors) — USE is for resources (CPU, disk, memory), RED is for services. Use both: USE tells you what's wrong with the machine, RED tells you what's wrong with the service. Resource metrics without request metrics is like watching a car's fuel gauge without knowing if it's moving.