USE Method vs RED Method: What They Are and When to Use Each

Last verified on Nov 8, 2026.

Two checklists show up in almost every observability conversation: USE and RED. They are often presented as rivals. They are not. They answer different questions about different kinds of things, and a debugging session usually needs both.

USE: For Resources

Brendan Gregg introduced the USE method as a methodology for analyzing the performance of any system. Its summary line: for every resource, check utilization, saturation, and errors. He defines the terms as follows:

• Resource: a physical server component such as a CPU, disk, or bus. Software resources and limits can count too.
• Utilization: the average time the resource was busy servicing work.
• Saturation: the degree to which the resource has extra work it cannot service, often queued.
• Errors: the count of error events.

Utilization is a percentage over an interval, saturation is a queue length, and errors are a count. Examples from his page: "one disk is running at 90% utilization", "the CPUs have an average run queue length of four", "this network interface has had fifty late collisions".

The method starts from a list of resources and asks the three questions of each, instead of beginning with whatever metrics happen to be available. Gregg says he finds it solves about 80% of server issues with 5% of the effort, and that it is a tool that sits in a larger toolbox. Three of his interpretation notes are worth remembering:

• Averages hide bursts. A five-minute average showing 70% utilization can hide seconds at 100%. He describes a customer with CPU saturation whose tool showed CPU never above 80%, because it reported five-minute averages.
• Any saturation can be a problem. Non-zero saturation is worth a look. 100% utilization is usually a bottleneck, and sustained utilization beyond 70% can begin to cause trouble.
• Check errors first. They are quick to read and easy to interpret, which makes them a cheap first step in his flowchart.

RED: For Services

The RED method is Rate, Errors, and Duration. Grafana's documentation describes it as a consistent framework for monitoring request-driven services: the number of requests per second, the requests that fail, and the time requests take. Tom Wilkie presented it in his GrafanaCon EU 2018 talk, next to USE and the golden signals.

Documentation differs on small details. Grafana's concepts page defines errors as the number of requests that are failing. Another Grafana page calls errors the percentage of requests that fail. Pick one, and say which in your dashboards. A percentage is easier to compare across services with different traffic, while a count tells you the absolute damage.

Side by Side

The two share the word "errors", and they count different things: a hardware or OS-level fault event for USE, a failed request for RED.

How They Connect

Wilkie's slides frame the four golden signals as RED plus saturation, and saturation is the S in USE. Google's SRE book defines the four signals as latency, traffic, errors, and saturation, which is the same set under the names golden signals. The three checklists overlap. This mapping is a rough guide, not an equivalence:

A Workflow That Uses Both

1. Start from RED on each service. A rise in errors or duration points at the affected service, and a rise in rate may explain why.
2. Walk the service's dependencies with RED, one hop at a time, until you find the first service whose own duration or errors are high.
3. Switch to USE on that service's hosts, containers, pools, and queues. Look for the resource at high utilization, with saturation or errors alongside it.
4. Confirm with logs. Saturation shows up as timeouts and retries. See latency spikes and capacity risks.

Cloud environments add resource limits. Gregg notes that hypervisor and container limits for memory, CPU, network, and storage I/O can be examined with USE like physical resources: a tenant's memory usage against its cap is its capacity utilization.

Choosing Between Them

• Request-driven service with an SLO: RED, then derive an SLI from it.
• Database, queue or host showing slowness: USE.
• Starting from nothing on a user-facing system: the golden signals, which cover both views.

Neither replaces logs or traces. They tell you where to look. See performance degradation for what the symptoms look like in practice.

Frequently Asked Questions

What is the difference between the USE and RED methods?

USE looks at resources such as CPUs, disks, and network interfaces: utilization, saturation, and errors. RED looks at services: request rate, errors, and duration. USE explains why capacity is short, and RED shows what users experience.

Who created the USE method?

Brendan Gregg, who describes it on his site as a methodology for analyzing the performance of any system, aimed at quickly finding resource bottlenecks or errors.

Are the four golden signals the same as RED?

Not quite. Tom Wilkie's slides present the golden signals as RED plus saturation. Google's SRE book names the four as latency, traffic, errors, and saturation.

Which one should I start with?

Start with RED when someone reports slowness or errors, to find which service is affected. Then use USE on that service's hosts, pools, and queues to find the constrained resource.

Sources

1. USE method definition by its author: for every resource, check utilization, saturation, and errors; definitions, interpretation, and strategy (accessed Nov 8, 2026)
2. RED method (Rate, Errors, Duration) as a framework for monitoring request-driven services (accessed Nov 8, 2026)
3. RED metrics: number of requests per second, number failing, and time requests take (accessed Nov 8, 2026)
4. Tom Wilkie's GrafanaCon EU 2018 slides on USE, RED, and the four golden signals as RED plus saturation (accessed Nov 8, 2026)
5. The four golden signals of monitoring (accessed Nov 8, 2026)