11. Metrics, SLIs/SLOs, and the RED/USE Methods

The tools in §7–10 produce numbers; this section is how those numbers turn into an ongoing practice instead of a one-off report. RED and USE are the two standard lenses for deciding what to measure continuously, not just what to measure during a single load test run.

11.1 RED method (for request-driven services)

• Rate — requests per second
• Errors — failed requests per second (and error rate %)
• Duration — latency distribution (percentiles, §3.1)

11.2 USE method (for resources: CPU, DB connections, queues, disks)

• Utilization — % time the resource was busy
• Saturation — amount of queued work the resource couldn't service immediately
• Errors — count of error events for that resource

Cross-reference RED (what users feel) against USE (why) during every load test: a RED-method latency spike should always correlate with a USE-method saturation signal somewhere (DB connection pool at 100%, CPU pegged, run queue growing) — if it doesn't, you likely have a lock contention or external-dependency issue that plain resource metrics won't show directly.

11.3 Defining SLOs from load test data

SLI: 99th percentile latency of GET /api/products/{id}
SLO: p99 < 300ms, measured over rolling 5 minutes, 99.9% of the time (error budget: 0.1%)

Bake the SLO directly into the load test as a pass/fail gate (k6 thresholds, §7.4) so performance regressions fail CI the same way a broken unit test does, rather than being discovered after a production incident.