Index Check Ops → Drop monitoring

Index Drop Monitoring: Thresholds and Alert Cadence

The failure mode of index monitoring isn't missing a drop. It's alert fatigue by week three, after which every notification — including the real one — gets archived unread. Monitoring design is mostly the art of staying quiet correctly.

What to watch: standing samples, not everything

Pages built from one template fail together, so a stable sample per template carries the signal of the whole group. A few hundred URLs per money-template, re-checked on schedule, beats a weekly full-catalog run on both cost and clarity. The sample set stays fixed between runs — trend lines need identical inputs.

Alert rules that survive contact with a team

• Alert on deltas, never absolutes. "Product sample at 91%" is a status. "Product sample fell 9 points since Tuesday" is an event. Only events notify.
• Two severities, not five. Sharp single-cycle drop in a money template → incident, human today. Slow two-cycle decline → ticket, human this week. Everything else → log line.
• Silence is a feature. A no-change run posts nothing. The weekly digest — one line per template — is where "all quiet" gets said, once.
• Cross-check before paging. The Page Indexing report corroborates trends; its documentation is open about data lag and capped examples, so it confirms direction, not line items. Per-URL confirmation comes from re-running the sample.

The incident playbook, four steps

1. Confirm: immediate re-check of the affected sample — one batch task, minutes.
2. Scope: full check of that template only, to size the blast radius.
3. Diagnose: diff against recent deploys; check directives, canonicals, and soft-404 signals on a handful of dropped URLs. The Crawled – currently not indexed guide covers the triage tree.
4. Recover: fix, resubmit through the checker-to-indexing loop, and keep the incident open until the day-14 re-check restores the sample's band.