Guide
Monitoring a page over time
An audit tells you what is broken today. A monitor tells you what changed — it re-runs the same scan on a schedule you choose and keeps the history, so a regression shows up as a line moving rather than as a customer complaint.
Last reviewed: 8 August 2026
What a monitor is
A monitor is a URL Mend audits on a schedule without being asked — as often as once a day, as seldom as once a fortnight. Each run is stored as an ordinary audit — the same rows the extension and the API produce — so monitored pages appear on your dashboard alongside everything else and get the same per-rule pages and trend lines.
Add one from the Monitors page. A bare URL is a complete monitor; everything below is optional.
How often, and at a time that moves
You choose the frequency, from every day to every fortnight — daily, every three days, weekly, or fortnightly. Daily is the default and is what every monitor did before the setting existed. Change it under How often on the monitor; it saves immediately and reschedules the next check to match, so shortening the interval takes effect straight away rather than waiting out the old one. Moving between weekly and fortnightly keeps whichever day you had chosen.
On weekly and fortnightly you can also pick the day — a second control appears next to the frequency. Leave it on Any day and the monitor settles onto whatever day its first run landed on; choose one and it holds that day, correcting itself if a run ever drifts. The choice is not offered on daily or every-3-days, because “every Tuesday” and “every 3 days” are contradictory instructions.
Days are UTC, like the rest of the schedule. At a long offset that is worth knowing: a Monday here can be your Sunday evening or your Tuesday morning.
Mend picks the time, and re-picks it after every run. A monitor runs at some random instant inside its due UTC day, so two consecutive runs will not be at the same clock time. You cannot choose the hour, and that one is deliberate rather than missing: a fixed time would mean every monitored site sees a request from us at the same minute, and it would stack every customer's run on whichever hour was most popular.
The first run is always within 24 hours, whatever frequency you choose. Setting up a fortnightly monitor and waiting two weeks to discover the sign-in flow was wrong would be a miserable way to find out, so the interval governs every run after the first.
There is exactly one run per period. If you need a scan at a known moment — after a deploy, say — that is what posting from CI is for. The two work well together: CI covers the moments you care about, the monitor covers the days nobody looked.
Run now scans immediately without disturbing the schedule. A monitor can only have one run in flight, so the button is unavailable while a scheduled run is happening, and a run that dies partway through cannot leave the monitor stuck — the claim expires and the next tick picks it up.
Auditing more than one page
A monitor can drive the browser before it scans: navigate, fill a field, click, wait for something to appear. That exists mainly for pages behind a login, which has its own guide covering credentials and the vault, but the same mechanism covers any page you cannot reach by URL alone — a step in a checkout, a form's success state, anything behind a click.
The steps available are go to a URL, fill a field, click, wait (for a selector, a URL, the network to go quiet, or a fixed delay) and check something is visible. Steps can target elements inside iframes.
By default only the page at the end of the flow is audited. A step can also be marked capture this page, which scores the page as it stands at that point. That matters for anything multi-step: a checkout that fails WCAG on step 2 of 4 used to report nothing at all, because step 4 was the only page the scanner ever saw. The final page is always captured whether or not any step asks for it — it is the page the monitor is named after.
The option is offered on go to, wait and check something is visible — not on fill a field or click. Those two are the moment an interaction is made rather than a moment the page is settled enough to score: auditing straight after a click catches whatever was on screen before the navigation it triggered, which is a result nobody can act on and one that changes between runs for reasons you cannot see. When what you want is “audit what the click produced”, put the capture on the wait or check step that follows it — that is the step that names the settled state.
Each capture is stored as its own audit against the URL the browser was actually on. This is why a Slack message can say “4 pages audited” for something you think of as one monitor.
Pausing, and deleting
Pause stops the scheduled run and keeps everything else — the flow, the settings, and every audit already collected. Resume and it picks up the next day. Use it for a staging environment that is down for a fortnight, rather than deleting the monitor and losing its history.
Delete removes the monitor and its stored credentials. Audits it already produced stay on your dashboard; they are ordinary audits and are not owned by the monitor. If you want those gone too, delete them from the dashboard or use the account-wide controls.
When a run fails
A failed run means the scan could not complete — not that the page has problems. The page failing to load, a selector that no longer matches, an expired credential, a redirect landing somewhere unexpected. The monitor keeps its schedule and tries again tomorrow; a failure never pauses it.
The last error is shown on the monitor, and depending on your settings you are emailed about it — including the rule that waits out a one-off timeout before bothering you. That is covered in email alerts. If you have connected Slack, the failure is posted there as well, with the error text.
The most common cause of a run that fails every time is a flow whose page changed underneath it. Re-record the step that no longer matches; the error usually names it.