A Grafana dashboard with thirty panels helps nobody at three in the morning. The problem is almost never a lack of metrics: Prometheus already exposes thousands per service. The problem is the absence of a structure that says which order to look at them in when something breaks. RED and USE are two answers to that question, each for a different kind of component, and mixing them up produces exactly the kind of dashboard people close within ten seconds mid-incident.

RED: for anything that serves requests

RED applies to any component that answers requests: an HTTP service, an API, a gRPC endpoint. Three signals, in reading order:

  • Rate: requests per second. Tells you whether traffic matches expectations, not whether the service is healthy on its own.
  • Errors: the fraction of requests that fail. This is the signal that should jump out first on an incident dashboard.
  • Duration: the latency distribution, in percentiles (p50, p95, p99), never as an average. An average hides exactly the 1% of slow requests that are causing the incident.
# Rate: requests per second, by status code
sum(rate(http_requests_total[5m])) by (status)

# Errors: error rate as a percentage
sum(rate(http_requests_total{status=~"5.."}[5m]))
/ sum(rate(http_requests_total[5m])) * 100

# Duration: p95 latency
histogram_quantile(0.95, sum(rate(http_request_duration_seconds_bucket[5m])) by (le))

Those three queries fit on a single row of panels, readable in five seconds. That is the test: if a RED dashboard cannot be read at a glance on a laptop screen, it has too many panels, or the wrong ones.

USE: for anything that gets consumed as a resource

USE applies to resources that do not answer requests but get consumed: CPU, memory, disk, network, a connection pool. Three different signals:

  • Utilization: the percentage of time the resource is busy doing useful work.
  • Saturation: the backlog of work the resource cannot absorb right away (processes waiting for CPU, a queue’s depth).
  • Errors: hardware or software errors from the resource itself (dropped network packets, failing disk sectors).
# CPU utilization per node
100 - (avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)

# Saturation: run queue (load average normalized by core count)
node_load1 / count without (cpu, mode) (node_cpu_seconds_total{mode="idle"})

# Network errors
rate(node_network_receive_errs_total[5m])

The classic mistake is applying RED to a resource: CPU has no meaningful “request rate” or “request latency”, it has utilization and saturation. A dashboard showing average CPU latency is a sign someone copied a template without thinking about what it measures.

Why the mix-up costs real time mid-incident

A well-built dashboard answers a specific question without anyone having to phrase it: “what changed right before users started complaining?” A RED dashboard at the top of a service answers that for the application layer. A USE dashboard right below it answers it for the infrastructure carrying that layer. Stacking both on the same panel, or worse, mixing metrics (HTTP latency next to CPU utilization with no clear hierarchy) forces whoever is on call to rebuild that hierarchy mentally under pressure, exactly when they have the least capacity to do it.

A dashboard structure that holds up under pressure

An effective incident dashboard follows a reading order, not a list of available metrics: RED first on the affected service (are users impacted, and how), then USE on the resources that service directly depends on (the node, the database, the cache), and only then business-specific metrics. Every row on the dashboard should map to a question someone actually asks while walking toward the incident, in the order they ask it.

That same measure-before-you-act principle runs through everything observability touches: a dashboard is only useful if it shortens the path from symptom to cause, not if it displays everything measurable. Golden signals give the base vocabulary; RED and USE are its application organized by component type, ready to become alerting rules once you know what deserves to wake someone up.

What to remember

RED for anything answering requests, USE for anything consumed as a resource. A dashboard mixing the two with no hierarchy forces a mental rebuild mid-incident. The question for every panel is not “does this metric exist” but “what specific question does this panel answer, and in what order do I look at it.” Building an observability setup that actually keeps that promise is part of what a reliability and observability engagement covers.