Most on-call noise comes from dashboards that grew after the last outage. The useful signals are the ones written down while the system is quiet: what would tell you the product is actually failing, and what you can ignore until morning.
A page is useful when the signal was chosen before the incident, not invented in the thread.
Three signals, not thirty
We ask every embed to name three traces before launch: the user path that must stay fast, the dependency that fails closed, and the queue that hides work. Everything else can wait. A page that lists thirty charts trains people to mute it.
Those three live next to the service, with a latency budget and an error budget. If either budget burns, the page says which signal moved. If neither moved, it is not a page.
Write it before Friday
The record is short: signal, owner, budget, and what “fine” looks like. We add it in the same week as the ADR, so the decision and the way we watch it ship together.
When the incident comes, the thread starts from that note. The team is not inventing a theory from a wall of graphs. That is how on-call stays calm without pretending the system never fails.
