Exercise 2: "CPU Looks Fine But the App Was Slow" — A Monitoring-Gap Explanation — Possible Solution ==================================================================== A plausible explanation: the monitoring being checked was only INFRASTRUCTURE-LEVEL CPU utilization, which was collected automatically per the chapter's own default behavior -- but the actual slowness the customer experienced was an APPLICATION-LEVEL problem (for example, request latency, a slow database query, or a downstream dependency taking too long to respond) that was never being tracked as a custom metric at all. Per the chapter, "application-level or custom metrics need to be explicitly instrumented and pushed by your own code -- they don't appear on their own." If nobody configured request-latency tracking (or similar application-specific metrics) for this system, then CPU utilization can look completely normal throughout an incident where users experienced real, significant slowness -- because low CPU usage doesn't rule out the application spending a long time WAITING (on a slow database query, an external API call, or a lock) rather than actively computing. A system can be "slow" for reasons that never show up as high CPU at all. This is a direct instance of the chapter's own "why isn't X showing up in monitoring" scenario -- except here, the customer isn't asking why a metric is missing, they're drawing an incorrect conclusion (the app must be fine) from a metric that was never capable of showing the actual problem in the first place, because the RIGHT metric (request latency, or similar) was simply never being collected. WHY THIS WORKS AS AN ANSWER ------------------------------ This applies the chapter's own tip-box directly to a concrete customer scenario, and specifically names WHY low CPU doesn't rule out slowness -- a system waiting on I/O or a downstream dependency can be slow for users while staying CPU-idle the whole time, which is exactly the kind of gap application-level metrics (not the automatically- collected infrastructure metrics) are needed to catch.