URL monitoring
Re-analyse tracked pages daily or weekly, without being there.
URL monitoring re-analyses a tracked page on its own, daily or weekly, so a regression is something you are told about rather than something you discover months later. Available from the Pro plan.
Not to be confused with Website uptime, which is the other watching feature. URL monitoring re-runs the full analysis of one page and tells you when its findings change. Uptime asks every five minutes whether the site answers at all. One is about what a page contains, the other about whether it is there.
Daily or weekly
| Cadence | Suits |
|---|---|
| Daily | Pages that matter commercially and change often: pricing, key landing pages, anything a deploy touches regularly. |
| Weekly | Everything else. Enough to catch a regression well before it costs anything, at a seventh of the allowance. |
Two options rather than a cron expression, because the useful answer is almost always one of them. A page that changes more often than daily is one you should analyse from your deploy pipeline over the API, where it can run against the change that caused it.
Schedules spend your allowance
Each scheduled run is one report against your monthly limit, exactly like one you ran by hand. Twenty pages daily is roughly six hundred reports a month, which is more than Basic allows and most of Pro.
Start weekly on everything and move the handful of pages that genuinely need it to daily. Running every tracked page daily is the usual way to exhaust a month of allowance in the first fortnight.
When a schedule stops itself
A schedule can stop on its own. It is never silent: the dashboard says which schedule stopped and why.
| Reason | What happened | What to do |
|---|---|---|
| Kept failing | Three consecutive runs could not complete. The page is unreachable, behind a login, or refusing us. | Open the URL yourself. When it is fixed, start the schedule again. |
| No allowance | The plan no longer includes scheduled audits. | It resumes on Pro or Agency. A month whose reports have run out is different: runs are skipped, not stopped, and carry on when reports are available again. |
Being told
The point of a schedule is not the report it files, it is the message it sends when something breaks. Each run is compared with the run before it, and the workspace is told when either of these happens:
- a check becomes critical: a noindex tag added, the canonical sent to another page, the page answering with an error;
- the score falls by 10 points or more.
Only the change is sent, never the state: an issue still there on the next run is not new, so it is not sent again. Improvements and small movements are not sent either; speed results vary a little between runs, and an alert for every point would soon be ignored. History shows all of it.
The alert goes to the notification bell of everyone in the workspace, and by email to each of them who wants it. Turn the emails off under Account settings, Notifications, where SSL and uptime alerts have a switch each too.
Scheduled runs go into history like any other, so the comparison between two of them names exactly which checks changed. See History.