Match each signal to a response
| Signal | Route | First check | Close when |
|---|---|---|---|
| Customers cannot confirm bookings | Duty responder | Synthetic journey and affected scope | Journey restored and uncertain requests assigned |
| Exception queue growing | Business workflow owner | Age, category and reviewer capacity | Backlog has an agreed handling plan |
| Disk usage trend | Planned operations work | Growth and safe expansion options | Capacity action completed and verified |
| One invalid test record | Test result log | Expected rejection? | Result agrees with the case |
Google’s monitoring guidance distinguishes user-visible symptoms from internal causes and argues for actionable notifications. The routes above are illustrative choices, not universal severity levels. Set thresholds from your workload, coverage and tolerance; a metric crossing a number is not automatically a reason to wake someone.
Test the notification path as well as detection
In a controlled test, verify the named recipient receives the alert, can access its evidence and knows the next check. Check escalation if they are unavailable and send recovery information when the condition clears. Review repeated unactionable alerts before adding more channels.
A CPU alert fires but all agreed customer tasks pass. What is the next decision?
Show the worked answer
Inspect the trend and risk, then choose an operational task or an urgent response based on the agreed policy. Do not invent customer impact; retain the observation for threshold review.