Page a person when something users or data can feel is going wrong, a symptom, and keep cause-level signals as debugging aids. Google's monitoring guidance makes this distinction central. In security terms: page on confirmed misuse or loss, not on every precursor that might lead there.
What and why
The SRE book says monitoring should answer two questions: what is broken, and why. It calls that distinction one of the most important in good monitoring. A symptom is the what. A cause is the why.
Causes are everywhere in security telemetry. A failed login, an odd process, an outbound connection to a new address. Each could be a precursor. Most are nothing.
Translating to detections
- Symptom (page candidate): Data leaving to an unknown destination in volume; Cause (investigation aid): One odd outbound connection
- Symptom (page candidate): A privileged account used from two places at once; Cause (investigation aid): A single failed login
- Symptom (page candidate): Production build artifacts differ from source; Cause (investigation aid): A new dependency appearing in a lockfile
The left column often needs human judgment quickly. The right column is context that helps once you are looking.
It depends on the layer
The book points out that what counts as a symptom depends on where you stand. A slow database is a symptom to the database team and a cause to the front end team. Likewise, a compromised workstation is a symptom to the endpoint owner but a cause for the data team. Decide ownership, and let each owner page on their own symptoms.
Why this reduces fatigue
The book warns that paging is expensive. It interrupts work, personal time and sleep, and too many pages lead people to skim. Humans can only respond with urgency a few times a day. Paging on symptoms means fewer pages that each carry more meaning.
Do not drop the causes
Keep cause signals. Send them to a dashboard, a ticket queue or a search index. When a symptom fires, they tell you where to look. The book allows paging on causes only when the cause is definite and imminent.
Getting started
Pick your three noisiest paging alerts and ask of each: is this a symptom or a cause? If it is a cause, find the matching symptom and see whether it already has an alert. If it does, demote the cause alert to a ticket. If not, write the symptom alert first, then demote.
Do this for a month and watch the page count. The goal is not silence. It is that when the pager sounds, the person who answers knows something definite is wrong and has the cause signals ready as clues.
Quick check
Does this mean ignoring early warnings?
No. Early warnings still go somewhere with an owner. They just do not wake anyone unless they point to something definite and imminent.
Sources
Last reviewed: 19 October 2026.
