Alerts and incidents

One problem is one alert, however many pages it hits. That single rule is what decides whether alerting stays useful past the first week.

Why grouping matters

A theme deploy adds noindex to a template used by four hundred pages. Alerting per page sends four hundred emails, describing one mistake with one fix. Nobody reads the four hundredth, and after a fortnight nobody reads the first either.

Monitor groups related findings into an incident: one notification, with the pattern and the list of affected pages inside it.

What an incident contains

What changed, and what it was before.
How many pages, and which.
When it started — the crawl that first saw it.
Whether it is still happening.

An incident stays open while the condition persists and resolves itself when a later crawl finds it gone. So the incident list is the current state of the site, not a log.

What you are alerted about

By default the things that cost you traffic or money if unnoticed:

Pages becoming unreachable or returning errors.
Pages becoming non-indexable.
Canonicals changing.
Large-scale metadata changes.
A crawl failing to complete.

Medium and low findings accumulate in the reports rather than interrupting you.

Where they go

Email, and Slack if connected. Set recipients per site — the person who owns a documentation site is rarely the person who owns the marketing site.

Keeping it signal

Alert to a channel a person actually reads. An alert routed to a channel nobody watches is a metric, not an alert.
Scope the crawl. Most alert noise is really scope: tag archives and paginated listings generating findings that are true and uninteresting. See adding a site to Monitor.
Mute deliberately. Mute the page or the pattern, not the rule site-wide — a muted rule is silent when it later fires for a real reason.