Given counters, gauges, and histograms as building blocks, the next question is which specific things to actually track — a genuinely open-ended design problem that two small, well-known frameworks answer well enough to use as a default, rather than starting from a blank page every time.
3 min read
A single service could plausibly emit hundreds of different metrics — CPU, memory, every internal function's timing, every dependency's health. Without a starting framework, teams either measure too little (missing the signal that would have caught an incident) or too much (drowning useful signal in noise, and paying real storage cost for metrics nobody ever queries). Two small, well-known frameworks give a solid default answer for most services.
RED targets any service that primarily handles requests (a web API, a microservice) — three metrics, all built from the counter/gauge/histogram types in the previous lesson:
These three, tracked per service (and ideally per endpoint), answer the question that matters most during an incident fastest: is this specific service currently serving requests successfully and quickly? A dashboard built from RED metrics for every service in a system is a genuinely strong default starting point, not a simplification that leaves out something important.
USE targets a different kind of thing — a resource with finite capacity (a CPU, a disk, a connection pool, a queue) rather than a request-handling service:
RED asks "is the thing serving requests behaving well" (an outward-facing, service-level view); USE asks "is the thing a service depends on running out of room" (an inward-facing, resource-level view). A database connection pool at 95% utilization (USE) might not yet show up as elevated request errors or latency (RED) — until it does, suddenly and without much warning, once the last few connections are exhausted. Tracking both together catches problems earlier than either framework alone: USE metrics often show a resource trending toward trouble well before RED metrics show the user-facing symptom.
A checkout API service gets RED metrics (request rate, error rate, p50/p95/p99 duration). The database connection pool it depends on gets USE metrics (connections in use out of the pool's max, queries waiting for a free connection, connection-acquisition failures). A dashboard combining both — the service's own health plus its critical dependency's resource pressure — answers both "is checkout working right now" and "is checkout about to stop working soon," which a RED-only or USE-only view each miss half of.
RED and USE are strong defaults, not an exhaustive checklist — a payments service might genuinely need a business-specific metric (successful charges per minute) that neither framework names directly. The value of starting from RED/USE is having a solid baseline covering the most common failure modes automatically, freeing attention to add the handful of metrics that are genuinely specific to what a particular service actually does.
Check your understanding
A quick comprehension check — not tracked, not graded, just for you.
1. What do the three RED metrics measure, and for what kind of thing?
2. What do the three USE metrics measure, and for what kind of thing?
3. Why can USE metrics catch a problem before RED metrics show any symptom?
Observability & Monitoring