Q: Users are reporting slowness, but CPU and memory look normal. What will you check next?

Open APM distributed traces (OpenTelemetry, Jaeger, Datadog). Look at the trace waterfall: is time spent inside application processing, waiting on an external HTTP call, or waiting on a database query?

# Look for spans with high duration but low CPU time

If the application's HTTP worker thread pool (e.g., Tomcat, Gunicorn, Node.js event loop) or database connection pool (HikariCP, PgBouncer) is exhausted, incoming requests are queued. Queued requests accumulate latency without consuming any CPU.

# Check JVM thread states or connection pool active vs max metrics:
# Example: hikaricp_pending_threads > 0
# Example: nodejs_eventloop_lag_seconds > 0.1

If processes are waiting on slow disks or EBS volume IOPS limits, CPU utilization appears low because the CPU is idling waiting for data. Check the 'wa' (iowait) column in vmstat and %util in iostat.

vmstat 1 5
# Check the 'wa' column (I/O wait)
iostat -xz 1 5
# Check %util and await (>10ms indicates storage throttling)

DNS timeouts (like the Linux 5-second glibc / CoreDNS race condition) or TCP packet loss cause requests to hang without CPU consumption. Check network metrics and packet drop counters.

netstat -s | grep -i retrans
# Test CoreDNS resolution latency:
dig +time=2 +tries=1 @<CoreDNS_IP> api.service.internal

Check if an external payment gateway, third-party authentication API, or database row-level locking (e.g. pg_stat_activity showing 'exclusive lock') is serializing requests.

# In PostgreSQL:
SELECT pid, state, wait_event_type, wait_event, query FROM pg_stat_activity WHERE wait_event IS NOT NULL;