Website monitoring with scheduled scans

Enable a schedule on a project (daily or weekly). When a scheduled or manual scan finishes, Launch Ready evaluates alert rules against the previous completed scan, then delivers to the channels you configured. Free workspaces do not get schedules or monitoring alerts. Pro and Agency do. Workspaces with at least one enabled schedule also receive a weekly digest email (Monday from 07:00 UTC) for owners and admins.

Scheduled scanning does not mean continuous synthetic uptime, multi-step user-journey tests, form delivery verification, or logged-in workflow checks. The crawler does not keep a browser session, submit forms, or click through checkout. Between scheduled runs, silent breakage can happen without an alert.

• No sub-minute or always-on probe loop — only the schedule you set (daily or weekly).
• No SLA for alert latency beyond “after the scan completes and rules evaluate”.
• Incomplete crawls, bot walls, or worker outages can produce missing coverage instead of findings.
• Ignored findings stay suppressed and do not fire alerts.

1. Use a Pro or Agency workspace (monitoring requires the paid entitlements).
2. Open the project → Monitoring. Turn on automatic scans and choose daily or weekly.
3. Add at least one channel: email (up to five recipients), a Slack incoming webhook URL, or a signed HTTPS webhook. Webhook signing secrets are shown once at creation.
4. Confirm the default rules (new launch blocker, score drop of 10 points, homepage unavailable) or adjust them. The “expected tracking missing” rule is available when you mark integrations as expected.
5. After the next completed scan, check deliveries on the same page. Failed webhooks are recorded rather than dropped silently.

Schedules are stored per project. Enabling a schedule for the first time seeds the default alert rules (and a starter email channel when none exist). Re-enabling later does not resurrect rules you turned off. Scans still compete with the plan’s concurrency and hourly scan caps (3 concurrent /60 per hour on Pro; 6 / 200 on Agency).

Each run is a full crawl within the plan’s page limit (300 pages on Pro and Agency today), not a lightweight ping. Queue depth and worker load affect when the run starts after its due time.

Pro and Agency keep scan history. After a run completes, the report can show what is newly found versus the previous completed scan and what resolved. Alert rules use the same previous-scan baseline: a “new launch blocker” is a critical finding whose fingerprint was not present before.

Free keeps a short history window for the product experience but does not unlock schedules or monitoring alerts.

Rules currently implemented in product code:

• New launch blocker — A launch-blocking issue appears that the previous scan did not have.
• Score drop — The readiness score falls by at least this many points since the previous scan.
• Homepage unavailable — The homepage did not respond, or answered with an error status.
• Expected tracking missing — An analytics or tag integration you marked as expected was not found.

Channels: email, slack, webhook. Slack targets must be Slack incoming webhook URLs. Custom webhooks receive a signed payload (X-LaunchReady-Signature) when a secret was created with the channel.

Entitlements come from the workspace subscription. Commercial copy lives on pricing; production overrides of numeric caps are possible via environment configuration.

• Only crawled pages within the plan page cap are judged. Assets fetched afterwards are not extra pages.
• Bot protection, private networks, allowlists, and TLS failures reduce coverage; alerts cannot invent findings for pages the worker never saw.
• Accessibility checks are automated heuristics, not a WCAG certification. Compliance findings are signals, not legal advice.
• Human journeys (checkout, login, email delivery, payment) remain a manual checklist — see the website launch checklist.