USE metrics

USE (Utilization, Saturation, Errors) describes resources: CPU, memory, disks, network, connection pools, and thread pools. It complements RED when the bottleneck is infrastructure capacity rather than per-request logic.

| Letter | Question | |--------|----------| | Utilization | How busy is the resource? (e.g. CPU %, pool in-use) | | Saturation | Is work queueing? (run queue, disk await, pool wait) | | Errors | Hardware/driver/pool errors |

					API RED says "slow checkout"
USE on DB pool says "all connections busy, wait queue growing"
				

Watch saturation early—it often precedes user-visible latency spikes. For Node.js, also track event-loop lag and GC pauses as utilization signals.

On interviews: when USE beats RED, interpreting saturation vs utilization, and capacity planning from queue depth.

Common pitfalls: CPU alone without saturation; ignoring connection pool metrics; alerting on utilization without trend context.

The trade-off is comprehensive capacity views versus metric sprawl on small teams.

Checklist:

• Monitor pools, disks, and queues—not only CPU.
• Alert on saturation before hard failures.
• Correlate USE spikes with RED latency.
• Document ownership per resource class.