So when paged, your first step is look at something that is difficult to look at, and possibly waste time with false correlations? If the metrics are known as

So when paged, your first step is look at something that is difficult to look at, and possibly waste time with false correlations? If the metrics are known as important to your app, monitor specifically on those - that way you're alerted because of low memory or pooled connections or something you're watching, and can lead your team with that info. If the metrics aren't known to be important, why are you wasting your time looking at them on a dashboard? If you're paged - when it's raining is the wrong time to patch the leaky roof - it's the wrong time to debug and fix a problem in code. Those notes and todos should be pulled into next sprint triage. In the moment, just restoring service should be priority. If restoring service requires modifying code, database, routes, etc, then your testing environments and change control policies need improvement.