The USE Method is a performance analysis checklist by Brendan Gregg: for every resource, such as CPU, memory, disk, network interface or connection pool, check Utilization (how busy it is), Saturation (how much work is queued or waiting) and Errors (failure events). It quickly narrows down which resource is the bottleneck.
What is the USE Method?
The USE Method is a methodology for analysing system performance, introduced by Brendan Gregg. Its rule fits in one sentence: for every resource, check utilization, saturation and errors. Instead of starting with whichever metrics a tool happens to show, you first list the resources of a system and then ask the same three questions for each one. That turns a vague "the server is slow" into a structured search that rarely misses the bottleneck.
Where the RED Method looks at services from the outside (requests, errors, duration), the USE Method looks inside, at the hardware and software resources that do the work. The two are complementary.
Utilization, saturation and errors
- Utilization is the share of time a resource was busy, or the share of its capacity in use. A CPU at 90 % utilization was busy 90 % of the interval; a memory utilization of 80 % means 80 % of capacity is allocated.
- Saturation is the extra work a resource cannot serve right now and has to queue, such as the run queue length for CPUs, swapping for memory or the wait queue of a disk. Saturation is often the earliest sign of trouble, because latency rises as soon as work starts waiting.
- Errors are counts of error events: disk I/O errors, dropped network packets, failed allocations, rejected connections.
A resource can be a problem even at moderate average utilization. Short bursts at 100 % hide inside one-minute averages, and saturation appears whenever demand briefly exceeds capacity.
Typical resources and metrics
| Resource | Utilization | Saturation | Errors |
|---|---|---|---|
| CPU | Busy time per core | Run queue length, CPU throttling in containers | Machine check errors (rare) |
| Memory | Used vs. available | Swapping, page scanning, OOM kills | Failed allocations |
| Disk | Device busy time | I/O wait queue length | Device I/O errors |
| Network interface | Throughput vs. link speed | Dropped or queued packets | Interface errors |
| Connection or thread pool | Connections in use vs. maximum | Callers waiting for a connection | Timeouts, rejections |
The last row shows that USE is not limited to hardware. Software resources such as thread pools, database connections, locks and message queues have the same three properties and are frequent bottlenecks in cloud-native systems.
Gregg also recommends drawing a simple functional diagram of the system, including buses, interconnects and controllers, before starting. Every box and every arrow is a resource that can be checked. Resources that are hard to measure are worth noting explicitly as "unknown", because an unknown is a finding in itself: it shows where additional instrumentation is needed.
Example: USE checks for a Kubernetes node
With Prometheus node exporter and cAdvisor metrics, an illustrative first pass could look like this:
# CPU utilization per node
1 - avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[5m]))
# CPU saturation: load average per core
node_load1 / count by (instance) (node_cpu_seconds_total{mode="idle"})
# Container CPU throttling (saturation signal)
rate(container_cpu_cfs_throttled_periods_total[5m])
/ rate(container_cpu_cfs_periods_total[5m])
# Network errors
rate(node_network_receive_errs_total[5m])On Linux hosts, the same checks can be done interactively with tools like vmstat, mpstat, iostat and sar. On Linux, the pressure stall information files under /proc/pressure also report how long tasks waited for CPU, memory or I/O, a direct saturation measure.
Best practices
- Start from a resource list, not from available metrics. Gaps in the list show where you are blind.
- Look at saturation first when latency rises. Queues explain slowdowns better than utilization alone.
- Use short intervals for utilization. Bursts disappear in long averages.
- Combine with RED. Alert on user-facing RED signals and use USE to locate the cause.
- Feed results into capacity planning, since sustained high utilization and recurring saturation indicate where to scale.
Common mistakes
- Checking only utilization and declaring a resource healthy because it is "only at 60 %".
- Forgetting software resources such as connection pools, file descriptors or locks.
- Ignoring container limits: a pod can be throttled while the node still has idle CPU.
- Paging on high utilization alone, which often produces noise without user impact.
How Obseria helps
Obseria collects host, container and runtime metrics over OpenTelemetry and Prometheus, so utilization, saturation and error signals for nodes, pods, databases and pools sit next to the service signals that depend on them. Kubernetes monitoring includes throttling and resource limits, and Obseria TopoGraph shows which services run on a saturated resource, which shortens the path from symptom to cause.
