Monitors (scheduled scans)
Re-capture and re-analyze a saved flow on a schedule, with quotas and overlap protection.
What a monitor is#
A monitor re-runs a saved capture flow on a cron schedule in the timezone you pick, then ingests and analyzes the result like any other run. Each tick lands on the page's project timeline, so trends and regression alerts happen without anyone remembering to re-test.
The monitor's page shows its run history — when each tick fired, whether it captured successfully, and a link to the resulting analysis.
Quotas & guard rails#
- A per-organization daily run quota (
SCHEDULE_MAX_RUNS_PER_DAY, default 50) stops an over-eager cron from burning capture capacity — over-quota ticks are recorded as skipped, never silently dropped. - An overlap guard ensures a schedule never runs twice at once: if a tick fires while the previous run is still going, it skips.
- How many monitors you can enable is set by your plan — see the plan matrix.
Pick a cadence that matches how often the page actually changes — for most teams that's hourly or daily, not every minute. Regressions are compared run-to-run either way.
Alerting on a regression#
Alerts ride on the project the monitor feeds: set a score-drop or payload-growth threshold and a webhook and/or alert email on the project, and any monitored run that regresses posts or emails a message — see regression alerts. A monitor attached to a project (the default "Track trends & alerts" option) adds every scan to that project's trend and fires its regression alerts automatically; it also sends its own monitor-health notification on a failure or a recovery, independent of any regression.