Schedules (recurring scans)

What a schedule is#

A schedule re-captures a page on a cadence, then ingests and analyzes the result like any other run. Point it straight at a URL, or pick a saved capture flow when the page is behind a login. You choose the cadence from a builder (hourly, daily, weekly — or a raw cron expression) and the timezone it runs in, with a preview of the next few fire times before you save. Each tick lands on the page's project timeline, so trends and regression alerts happen without anyone remembering to re-test.

A schedule lives inside the project it feeds: each project's Schedules card on the Projects page lists the schedules re-capturing that page, and each row expands to show its run history — when each tick fired, whether it captured successfully, and a link to the resulting analysis. Creating one there attaches it to that project automatically.

Run now captures a schedule once, immediately, without waiting for its cadence — handy for trying a new schedule before you switch it on (it works on a disabled one) or for re-checking a page straight after a deploy. The run is identical to a scheduled one: same capture, same analysis, same place in the run history and the project trend. To keep it from becoming a way around the quotas below, each schedule can be run manually once an hour.

Quotas & guard rails#

• A per-workspace daily run quota stops an over-eager schedule 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.
• Run now is limited to once per hour per schedule, and still counts against the daily quota and the overlap guard — it's a shortcut past the cadence, not past the cost controls.
• How many schedules 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 schedule feeds: set a score-drop or payload-growth threshold and a webhook and/or alert email on the project, and any scheduled run that regresses posts or emails a message — see regression alerts. Every schedule is attached to a project, so each scan joins that project's trend and fires its regression alerts automatically; a schedule also sends its own health notification on a failure or a recovery, independent of any regression.

Each schedule's Alerts button shows what it will actually send — the thresholds, the channels, which events post, and whether the last webhook delivery worked — with a link through to where those settings are changed.