Symptom-based versus cause-based alerting

WHAT THIS TESTS Whether you understand the Google SRE guidance to alert on symptoms, the user-visible effects, rather than on every internal cause, and can give clear examples.

A GOOD ANSWER COVERS A symptom is something the user actually experiences: the service is returning errors, responses are slow, or requests are failing. A cause is an internal condition that might lead to a symptom: CPU is saturated, a disk is filling, a queue is backing up, a dependency is degraded. The principle is to page on symptoms because they correlate directly with user pain and your SLOs, which keeps alerts few and meaningful. Cause-level signals are still valuable, but they belong in dashboards and as diagnostic context, or as lower-urgency tickets, not as pages, because many causes self-resolve or never impact users. Alerting on every cause produces noise and fatigue, and you can never enumerate all causes anyway, whereas symptoms catch unknown causes too.

COMMON WRONG ANSWERS Paging on every resource threshold like CPU over 80 percent regardless of user impact. Claiming cause alerts are useless; they aid diagnosis. Believing symptom alerts alone are enough to root-cause; they tell you something is wrong, not why.

LIKELY FOLLOW-UPS How do symptom alerts relate to SLOs and error budgets? When is a cause alert worth paging on? How do you avoid missing slow-burning causes?

ONE CONCRETE EXAMPLE Symptom alert: the checkout API's 5xx error rate exceeds 1 percent over five minutes, directly indicating users cannot buy. Cause alert: a database node's disk is 90 percent full. You page on the symptom because it reflects real impact, while the disk-full cause is a warning ticket and a dashboard panel that helps explain a future symptom, not an immediate page.