It stops you getting 100 separate emails after one site-wide deploy, and stops a dead site interrupting you every day for months.
Who is this for
- Teams who need to manage their notification load
- Technical owners who need to know when scans run
Prerequisites
- At least one active URL
- A verified notification email
Step-by-step
- Choose the frequency
manual only runs when you trigger it by hand or through the API. hourly, daily and weekly are scheduled. Each URL is spread across its own minute; the whole site is not scanned at once.
- Grouped notifications
Changes that occur close together in the same project are collected into a single notification in the default 10-minute window (configurable between 2 and 60 minutes).
- Critical notifications do not wait
A robots.txt change, a meta/header change that blocks indexing, and a loss of availability (HTTP status) are sent immediately without grouping. Two more in the same class: a measurement tag (GA4, GTM, Meta Pixel) dropping off the page, and a form disappearing — both stop the job without changing anything on screen.
- AI answer engines are monitored separately
Blocking training crawlers in robots.txt (GPTBot, ClaudeBot, CCBot, Google-Extended) is a legitimate choice and raises no alarm. Blocking answer engines (OAI-SearchBot, Claude-SearchBot, PerplexityBot) raises a critical notification: the page drops out of AI answers entirely. A security plugin’s blanket “block AI bots” rule does exactly the second thing.
- Certificate and domain expiry
The TLS certificate and domain expiry date are checked for every monitored site; you are notified 30, 14, 7 and 1 day ahead, and an expired certificate counts as critical. A certificate that cannot be checked is reported as “unknown”, not as “expires tomorrow”.
- Consecutive-failure policy
The first failed scan sends no notification. Two consecutive failures send one. Five consecutive failures pause the URL automatically. When the site recovers you get a “reachable again” notification and the URL continues on its own.
- Channels
Email and webhooks. If Slack is connected, every change arrives with the page address, class, severity, pixel difference and the evidence link to send the client, and the “Reviewed” or “Ignore” button in the message advances the baseline just like it does in the inbox. Every request coming from Slack is verified by signature; if no signing secret is configured, no button works.
Operational outputs
- Grouped change emails per project
- Immediate notification for critical changes
- Records of paused and reachable-again URLs
- Days left until certificate and domain expiry
- Measurement tags present on the page and the ones that disappeared
Plan availability
- Free: no webhooks, no hourly scans, 10 triggers a day
- Pro: 2 webhooks, 5 hourly URLs, 150 triggers a day
- Agency: 10 webhooks, 3 hourly URLs, 100 triggers a day
Limits and guardrails
- The daily trigger quota counts manual, API and baseline scans; scheduled scans do not consume it
- A notification that cannot be delivered is dropped after 5 attempts and is not retried forever
- No SMS and no mobile push
Expected outcome
- The number of notifications stays at a level you can actually read
- Critical incidents reach you within minutes
- A dead site does not interrupt you every single day
Troubleshooting paths
- If no notification arrives, check the spam folder and whether the URL is paused
- If a scan did not run at the hour you expected, check that the frequency is not manual
- If a webhook is dropped, check that your endpoint returns 2xx