48.9k
The RED method (Rate, Errors, Duration) and the USE method (Utilization, Saturation, Errors) are complementary monitoring frameworks: RED, defined by Tom Wilkie in 2015, measures request-driven services from the user's side; USE, created by Brendan Gregg, measures every hardware and software resource from the system's side.
The short answer to "which should I use" is both, scoped differently. RED covers the services users talk to; USE covers the resources those services run on. Neither replaces the other, and the four golden signals from Google's SRE book sit above both as the umbrella set.
RED vs USE at a glance
| Dimension | RED method | USE method | Golden signals |
|---|---|---|---|
| Metrics | Rate, Errors, Duration | Utilization, Saturation, Errors | Latency, Traffic, Errors, Saturation |
| Origin | Tom Wilkie, Weaveworks, 2015 | Brendan Gregg, 2012 | Google SRE book, 2016 |
| Unit of analysis | Each service | Each resource: CPU, memory, disks, network, queues, locks | Each user-facing system |
| Question answered | Are users having a bad time? | Is a resource the bottleneck? | Both, at the service level |
| Best for | Microservices, APIs, anything request-driven | Capacity problems, host and infrastructure diagnosis | Minimum viable paging set |
| Blind spots | Saturation and capacity; batch and streaming jobs | User experience; cross-service request paths | Per-resource detail below the service |
The table is the decision in miniature: pick the row "unit of analysis" and the choice makes itself.
What is the RED method for monitoring?
The RED method instruments every service with three metrics: Rate (requests per second), Errors (failed requests per second), and Duration (the distribution of request latency). Tom Wilkie defined it in 2015 as a microservices-oriented monitoring philosophy, so every service in an architecture exposes the same consistent, user-facing view.
That consistency is the point. In his GrafanaCon talk on the method, Wilkie argued that modelling every service the same way "allows you to scale your operational team, and allows you to put people on call for code they didn't write." He also called RED "a good proxy to how happy your customers will be": high error rate means users see failures, and high duration means the product is slow. Duration should be tracked as percentiles rather than averages, because the mean hides the slow tail users actually feel.
What is the USE method?
The USE method checks three properties for every resource in a system: Utilization (the percentage of time the resource was busy), Saturation (the amount of queued work it cannot service yet), and Errors (the count of error events). Brendan Gregg created it as a checklist-driven way to find resource bottlenecks fast.
Gregg's summary is one sentence: "For every resource, check utilization, saturation, and errors." His USE method page compares it to an aircraft emergency checklist (simple, complete, and fast) and reports that it "solves about 80% of server issues with 5% of the effort." Resources means physical and logical components: CPUs, memory, storage and network devices, but also thread pools, file descriptors, and locks. The method starts from questions and works toward metrics, rather than starting from whatever a dashboard happens to show.
What question does each method answer?
RED answers "are users having a bad time?" from the outside of a service; USE answers "is a resource the bottleneck?" from the inside of the infrastructure. RED is symptom-oriented and maps to what customers experience, while USE is cause-oriented and maps to where the constraint physically sits.
That split explains each method's blind spots. RED says nothing about capacity: a service can serve every request quickly while its disk fills or its connection pool nears exhaustion. USE says nothing about experience: a host can report healthy utilization while a downstream dependency ruins request latency. Wilkie himself noted the fit boundary: in his words, the USE method applies to hardware, networks, and disks rather than to services, and metrics like memory utilization get ambiguous fast. RED, in turn, fits poorly for batch jobs and streaming pipelines, where "requests" are not the natural unit of work.
How does the same outage look through RED and USE?
Consider a checkout service whose p99 latency jumps from 180 ms to 2.4 s at 14:00. Through the RED lens, duration has spiked, rate is flat, and errors creep from 0.1% to 2% as clients start timing out. RED has established that users are affected and roughly how badly, but not why.
Through the USE lens, a sweep of the resources under the service finds the answer: the database host reports 96% CPU utilization, a run queue three times longer than its core count (saturation), and zero hardware errors. Every other resource checks out clean. The bottleneck is database CPU, perhaps an unindexed query shipped at 13:55.
Worked backwards, neither method alone closes the incident. USE without RED finds a busy CPU but cannot say whether users care; RED without USE pages the on-call engineer with no lead on the cause. Wilkie's own recommendation in the GrafanaCon talk was to use the two methods together, as two sides of the same coin.
When should you use the RED method?
Use RED as the default instrumentation pattern for every request-driven service: APIs, web frontends, gRPC backends, message handlers with request/response semantics. It gives each service an identical scorecard, which keeps dashboards uniform and on-call handovers cheap.
- Microservice fleets, where a consistent per-service view matters more than per-host depth.
- Alerting tied to user experience and SLO-style targets, since error rate and duration are the raw material of most service level indicators.
- Teams that page on symptoms, not causes: RED alerts fire only when users are plausibly affected.
When should you use the USE method?
Use USE when diagnosing performance and capacity: an incident with no obvious cause, a host behaving strangely, or a capacity review before a traffic event. It works as a sweep: enumerate the resources, check three properties on each, and the bottleneck has few places to hide.
- Infrastructure and database layers, where the unit of failure is a resource, not a request.
- Capacity planning: utilization and saturation trends predict exhaustion before users notice.
- Batch and streaming workloads that RED models poorly, since throughput bottlenecks show up as resource saturation.
What do RED and USE metrics look like at rest?
The two methods produce differently shaped data. All three RED metrics fall out of a single wide table of request events (one row per request with a timestamp, service, duration, and status), while USE metrics arrive as periodically sampled values per resource: utilization percentages, queue depths, error counters.
USE data is mostly gauges, where RED data starts as raw events or counters; that difference decides how each is stored and queried. For RED over raw events, the SQL looks like this:
-- Illustrative shape: all three RED metrics from one wide-event table
SELECT
toStartOfMinute(timestamp) AS minute,
service,
count() / 60 AS rate_rps,
countIf(status_code >= 500) / count() AS error_ratio,
quantile(0.99)(duration_ms) AS duration_p99_ms
FROM request_events
GROUP BY minute, service
ORDER BY minute;Computing RED from raw events rather than pre-aggregated counters preserves the drill-down: when duration spikes, the individual slow requests are still there to inspect. At fleet scale that means percentile aggregations over billions of rows, which makes the storage engine a first-order choice.
Monitoring RED and USE metrics with ClickStack
ClickStack, the ClickHouse observability stack, ingests both data shapes through native OpenTelemetry pipelines: request-level traces and wide events for RED, and resource metrics from the OpenTelemetry Collector's host and Kubernetes receivers for USE. ClickHouse's columnar engine runs the per-service percentile and ratio aggregations shown above directly over raw events, and HyperDX, the stack's UI, is where teams build per-service RED dashboards alongside per-resource utilization and saturation views, so the 14:00 latency spike and the database CPU behind it sit one click apart.
Frequently asked questions
RED method vs USE method vs golden signals: which should I use?
Use RED for every request-driven service, USE for every resource underneath, and treat the four golden signals as the umbrella: they combine RED's three request-side metrics with USE's saturation. A practical starting point is golden signals for paging, RED for per-service dashboards, and USE checklists for diagnosis.
Can you use the RED and USE methods together?
Yes, and that is the recommended pattern, including by RED's creator Tom Wilkie. In an incident, RED alerts fire first, then a USE sweep across CPU, memory, disk, network, and queues narrows the search to the saturated component.
Does the RED method replace the golden signals?
No. RED is the golden signals minus saturation, scoped to request-driven services. Dropping saturation keeps instrumentation simple but loses the capacity dimension, so teams pairing RED with the golden signals (or with USE on the resources below) regain the early warning that disks, memory, or queues are filling.
Where does the USE method fall short in cloud environments?
USE assumes you can enumerate and measure resources, but managed services hide many of them: a cloud database exposes no run queue, and container limits complicate utilization. Where direct resource metrics are unavailable, the common workaround measures saturation by proxy: throttling events, queue depth, and usage against quota.
Running RED queries over billions of raw request events is the workload ClickStack was built for. It is open source and takes a few minutes to try.
