RED vs USE vs Golden Signals: When Each Wins
Three monitoring frameworks compete for attention: RED (Rate, Errors, Duration), USE (Utilisation, Saturation, Errors), and the Four Golden Signals. They aren't competitors, they're three views of three different things.
Three frameworks, three views
RED is for services. USE is for resources. Golden Signals is RED with one extra (saturation). They overlap deliberately because at the boundary "service health" and "resource health" affect each other.
The mistake. Teams treat the three as competing options and pick one. They don't compete; they cover different things. RED at the service level + USE at the resource level + Golden Signals when leadership asks for "the four numbers" is the right combination.
The overlap is intentional. RED's "duration" overlaps with Golden's "latency"; both measure user-facing slowness. RED's "errors" overlaps with USE's "errors"; both measure failure rate. The frameworks are deliberately redundant because the same signal at different levels is useful.
RED, for services
Rate (qps), Error rate, Duration (latency). Apply to every service. If you measure these three and graph them, you can answer "is this service healthy?" in under 10 seconds.
The simplicity is the strength. Three numbers per service. Multiplied across 50 services, that's 150 numbers, manageable on a single dashboard. Compared to "every internal metric we can measure," it's a fraction of the cardinality and answers the same questions.
Per-service implementation. Instrument every service with rate (request count per minute), error rate (% of requests that fail), and duration (p95 latency). Most service frameworks give you these for free; the work is mostly making sure they're consistently labelled and exported.
The RED dashboard. One row per service: rate sparkline, error rate sparkline, duration sparkline. 50-row dashboard for 50 services; one screen of data; instant overview of "what's healthy, what's not."
USE, for resources
Utilisation, Saturation, Errors. Apply to CPUs, disks, network interfaces. Catches "the box is unhappy" before it becomes a service-level RED problem.
The leading-indicator value. CPU utilisation rising over time is a leading indicator that the service will eventually saturate. The RED metrics are still healthy at this point; USE catches the trend before it becomes a problem.
The application. Every host: CPU utilisation, CPU saturation (load average), disk utilisation, disk I/O saturation (queue depth), network utilisation, network errors. Six numbers per host. For a 100-host fleet, 600 numbers, too many for a service dashboard but right for a host dashboard.
The relationship to RED. USE alerts the platform team; RED alerts the service team. Both are necessary; the platform team fixes resource issues before they become service issues.
Golden Signals, RED + saturation
Latency, traffic, errors, saturation. Adds saturation to RED. Saturation is the early-warning of capacity problems before they become latency problems.
The framework's origin. Google SRE Workbook. Designed to be the "four signals leadership needs to know about." Slightly more cumbersome than RED (four signals instead of three), more useful for capacity-aware monitoring.
What "saturation" means at the service level. The service's most-saturated resource. For a database: connection pool. For a worker queue: queue depth. For a stateless service: thread pool. Each service has a different saturation metric; teams pick the most relevant one.
The leadership pitch value. "Latency, traffic, errors, saturation" is a phrase leadership recognises. RED feels like jargon; Golden Signals has been in tech press for years. When pitching for monitoring investment, Golden Signals carries more recognition.
Which one when
Use RED for every service-level dashboard. Use USE for every host or resource-level dashboard. Use Golden Signals when leadership asks for "the four numbers that matter", the framework name is more recognisable.
The combined approach. Most mature teams use RED on service dashboards (engineer audience), USE on infra dashboards (platform team audience), and present Golden Signals to leadership for the company-wide reliability conversation. Three audiences, three frameworks, deliberate overlap.
The common confusion
Teams think they need to choose. They don't. RED on services + USE on resources is the right answer. Golden Signals is essentially RED with a spotlight on saturation, used at the same level as RED.
The pathology of choosing. Team picks "Golden Signals because it's the newest." They apply it everywhere, even to hosts where USE would be more useful, even to leadership pitches where simpler RED would land. The choice was political (newest = trendiest), not functional.
The honest framing. Each framework solves a different problem. Use them where they fit. The team's monitoring is stronger with all three than with any one applied universally.
Common antipatterns
The framework war. Engineers debate which is "best." None is best; they're complementary. Choose by audience and level.
RED with custom interpretations. Some teams interpret "errors" loosely (every 4xx) or strictly (only 5xx). Inconsistency across services makes RED dashboards misleading. Standardise the definitions.
USE without action. Resource-level metrics that nobody acts on. Either tie USE alerts to capacity-action runbooks or stop measuring; uninstrumented metrics are noise.
Golden Signals as the only framework. Team adopts Golden Signals universally; the saturation signal is duplicated effort on RED-style dashboards. RED is sufficient at the service level; reserve saturation for capacity-aware contexts.
What to do this week
Three moves. (1) Audit your service dashboards. Are they consistently RED-instrumented? Most teams find a few services missing one metric. Fix the gap. (2) Confirm your platform team has USE dashboards. If not, that's their next investment, service teams shouldn't be the first to know about resource saturation. (3) Adopt the framework matching your audience: RED for engineers, USE for platform, Golden Signals for leadership.