Exercise 3: What to Check Before Trusting a Flat, Healthy Graph — Possible Solution
====================================================================

WHAT THIS CHAPTER SAYS TO CHECK
------------------------------
Per this chapter's warn-box, "check the time range before trusting a
healthy-looking graph." The specific thing to verify is whether the
dashboard's currently-selected time window actually covers the period
the user is complaining about.

WHY A DEFAULT TIME RANGE CAN HIDE THE INCIDENT ENTIRELY
------------------------------
Per this chapter, "a dashboard defaulting to 'last 6 hours' (or
whatever the tool's own default happens to be) can make an incident
that happened yesterday invisible - not because nothing happened, but
because the currently-selected window simply doesn't include it." If
the user's complaint was from yesterday and the dashboard is still
showing only the last 6 hours, the graph will look flat and healthy
regardless of what actually happened yesterday - not because CPU was
fine, but because the relevant data isn't even on screen.

WHY THIS IS AN EASY MISTAKE TO MAKE
------------------------------
A flat graph looks like conclusive evidence at a glance, and it's easy
to interpret "nothing shown" as "nothing happened" without first
confirming the window being viewed actually corresponds to the
timeframe in question.

WHAT TO DO INSTEAD
------------------------------
Per this chapter's own reasoning, adjust the dashboard's time range to
explicitly cover the period the complaint refers to before drawing any
conclusion from what the graph shows - only once the correct window is
selected does a flat line actually mean CPU was healthy during the
relevant period.

WHY THIS WORKS AS AN ANSWER
------------------------------
It names the specific check (the time range) the chapter identifies,
explains the exact mechanism by which a default window can hide a real
incident, and states what to actually verify before concluding CPU was
ruled out.