It is 3 am and you are pulled into an incident on a service you have never seen. Users report slowness. You have a metrics dashboard, a log search and an on-call channel. In an interview, how do you structure your first ten minutes, and where do RED and USE each fit?

What the interviewer is testing

Whether you have a method that works without knowing the system, can say what each tool is for, and avoid the two failure modes: staring at dashboards without a hypothesis, and guessing a cause from a familiar pattern.

Clarifying questions that change the answer

• Is it all users or a segment (region, tenant, client version)? A segment points to a change or a dependency; everyone points to a shared resource.
• When did it start, and what changed in that window (deploys, flags, config, traffic)?
• Is the slowness in latency, errors, or both, and which endpoint?

A strong answer's arc

1. Scope first (1 minute). Who, what, since when. Check the change log before any dashboard.
2. RED on the service's own endpoints. Rate, Errors, Duration, per endpoint, measured from the request side. RED is about the work the service does for its callers. It tells you whether the symptom is real, which endpoint, and whether it correlates with traffic.
3. USE on the resources behind the slow endpoint. Utilisation, Saturation, Errors, per resource: CPU, memory, disk, network, thread pools, connection pools, queues. USE is about the machinery. The word that matters is saturation: queue depth, pool wait time, run-queue length. It shows up before utilisation reaches 100%.
4. Follow the dependency. If RED shows duration up and USE shows nothing saturated locally, the time is spent waiting. Take one slow trace and read where the time is, then check the callee's RED.
5. Mitigate before explaining. Roll back the change, shift traffic or shed load; understanding can wait until users are fine.

Where each fits, in one line

RED asks "is the service doing its job for callers"; USE asks "which resource is the reason". Start with RED because it matches the user complaint, then use USE to localise.

Common weak answers

• "Check CPU first." CPU is one USE line and is often unremarkable when the real saturation is a connection pool.
• "Read the logs for errors." With no errors in the logs, which is typical for slowness, that finds nothing and costs ten minutes.
• A tour of dashboards with no stated hypothesis.

What a strong answer adds

The honest limits: RED misses failures of work that never arrives (a client that cannot connect), so check the traffic rate for a drop as well as an error rise. USE needs saturation metrics to exist already; if the pools are not instrumented, say that the first follow-up action item is to add them. And mention the human layer: assign one person to communicate, so the investigator is not interrupted, and write down what you ruled out.

When not to use it

For a batch or streaming pipeline, replace RED with throughput, lag and freshness; request-shaped metrics do not describe it.