Changelog

A schedule used to say only how often. Now it can say when:

• scheduleHourUtc. A whole number from 0 to 23 that pins a daily or weekly project to that UTC hour — 3 means 03:00 UTC. Without it the slot still anchors to whenever the first sweep picked the project up, which is unchanged behaviour for every existing schedule. The first run waits for the hour too. On the REST API, in project config, and through update_project. See Scheduled Checks.
• Hours, and UTC. The sweep that starts scheduled runs is itself hourly, so there is no minute setting rather than one that quietly rounds. RegressionBot has no timezone setting anywhere, so there is no local time to convert from — the hour is UTC and says so in its name.
• Rejected where it would mislead. An hour on an hourly schedule is an error, not a silent no-op: accepted quietly it reads as "runs once a day at that hour" to whoever set it. Clearing the schedule clears the hour with it.

One behaviour worth knowing: a pinned hour does not catch up. If a run cannot start at its hour, the project waits for the next one rather than running late — where an unpinned schedule would have been picked up by the following sweep.

A project can now watch itself, and tell you when it stops being able to:

• Scheduled checks. schedule (hourly, daily, weekly) with baselinePolicy: "rolling" runs a project unattended — catching changes no deploy caused, like a third-party script updating itself or an edit in your CMS. Available on the REST API, in project config, and through the update_project MCP tool. See Scheduled Checks.
• Alerts when a check cannot check. Owners were already emailed when a scheduled run found changes. They are now also emailed when a run stops outright, finishes without capturing a single page, or never starts at all — the cases where silence and a healthy site look identical.
• Baseline invalidation is scoped to what it should always have been scoped to. Updating a project used to discard every baseline regardless of what changed, so turning on a schedule cost a full re-prime. Only changes that alter what a capture looks like — origin, sitemap, paths, scans, devices, masks, customCss, gate credentials — invalidate now. Schedule, baseline policy, concurrency and AI options leave baselines intact, and re-sending an identical value is not a change.
• list_projects answers the question people actually ask. It now returns schedule and baseline state per project, including nextRunComparesAgainstBaseline — whether a run right now would detect regressions or capture baselines.

Also in this release: the dashboard's Review tab became Jobs at /admin/jobs, where any job id from an API response can be opened directly, and alert emails now link to the run rather than to the dashboard root.

Cleaner full-page screenshots, plus a new escape hatch for dynamic content:

• Automatic sticky/fixed element handling. Before each full-page screenshot, RegressionBot now un-sticks position: fixed and position: sticky elements (headers, navs, cookie bars) so they render once at their at-rest position instead of floating over — or repeating down — the page. This is automatic; there is no flag to enable.
• customCss — inject arbitrary CSS into the page right before capture, e.g. #chat-widget { display: none !important; } to fully remove a dynamic widget (and reflow the layout, unlike masks, which only blank the region). Because it is applied last, customCss can also override the automatic un-sticking for a specific element. Capped at 4096 characters.

customCss is available on the REST API (POST /run, POST /project/{name}/run), in project configuration (create / update), and via the run_regression_job and update_project MCP tools.

This release introduced two major customer-facing capabilities for faster review and approval workflows: