See where your website actually stands—no email, no URL crawl, score in two minutes. Run the free System Review →
Client-owned web systems
Plan my system

SITEBORNE SIGNAL MODULE

SiteSentinel — automated website verification

Checks a narrow critical path for page availability, expected content, form visibility, metadata, and screenshot changes.

Try the demonstrationAdd to a project brief

BUSINESS OUTCOME

What this capability changes.

  • Detect breakage
  • Preserve critical journeys
  • Create evidence for Care

Best for

All maintained websites, Agencies

AI: noneProduction pattern: available

From $1,500

Module-only monitoring: from $150/monthA narrow add-on scoped to this module alone—checking its allowance, fallback, and failure state. It is separate from and smaller than a full Care plan, which covers the whole website.

Launch allowance statusAvailable

PLAIN LANGUAGE, TECHNICAL PROOF

What SiteSentinel does.

Checks the few website journeys that would hurt the business most if they broke.

Why it is valuable

The team learns about a missing form, broken call to action, or incorrect page before a customer has to report it.

Example workflow

A daily check confirms that the homepage loads, the project brief is reachable, the canonical URL is correct, and the main action remains visible.

FOR TECHNICAL READERS

How the control model works

Fast HTTP assertions run first; a tightly scheduled Browser Run check is reserved for visual or interaction evidence. Failures require confirmation before alerting.

Failure path: HTTP checks, static assertions, and manual QA checklist.

INTERACTIVE WALKTHROUGH

Use SiteSentinel before discussing it.

Choose a live SITEBORNE route and run a same-origin critical-path check in your browser.

The interaction uses your input and identifies whether it runs locally, checks this live site, or previews a production control. It does not disguise seeded output as intelligence.

Interactive demonstrationYour input stays in this browser unless the control says “live.”

System view

Required

Cloudflare Browser Run, Cloudflare Workers, Cloudflare Queues, Cloudflare D1, Cloudflare R2, Resend

Optional

None

Fallback

HTTP checks, static assertions, and manual QA checklist.

Provider dependencies

Cloudflare Browser Run, Cloudflare Workers, Cloudflare Queues, Cloudflare D1, Cloudflare R2, Resend

Last verified

2026-08-02

Provider limits, terms, model availability, and pricing may change. Production accounts remain client-owned.

Data classification

  • Public page snapshots
  • Test-mode form results

LAUNCH ALLOWANCE

Browser verification

Narrow critical-path browser monitoring.

Current limit
10 browser minutes/day on Workers Free.
Expected light use
A narrow daily critical-path schedule covering a few important public pages and forms.
What consumes it
Browser session duration shared across Quick Actions and Browser Sessions.
Fallback
HTTP checks, manual QA checklist, and user-reported issue path.
Paid successor
Cloudflare paid browser usage or approved monitoring provider
Commercial use
Commercial use permitted.
Data warning
Do not capture sensitive pages or secrets in screenshots.
Last verified
2026-08-02
View all referenced allowances
  • Browser verification: 10 browser minutes/day on Workers Free.
  • Asynchronous workflow: 10,000 operations/day and 24-hour message retention; a typical successful delivery uses three operations.
  • Transactional email: 3,000 emails/month, 100/day, one custom domain, one webhook endpoint, 30-day retention.

Upgrade triggers

  • browser minutes — 75%. Reduce schedule or move to paid monitoring.
  • critical failure — one confirmed. Alert human and display known status.
Conventional fallback: HTTP checks, static assertions, and manual QA checklist.
View implementation proof

Decision rationale

The implementation favors semantic HTML, static rendering, typed content, and isolated on-demand routes. Optional AI never controls pricing, eligibility, or emergency routing.

Controls

  • WCAG 2.2 AA target
  • Provider-neutral adapters
  • Usage caps and kill switches
  • Client-owned production accounts
  • Conventional fallbacks

Verified evidence

  • The browser demonstration runs from a clean clone without a paid credential.
  • Kill switch and allowance states are typed configuration.
  • Primary navigation and contact paths remain independent of this module.

Known limitation

External provider allowances and production behavior require owner accounts and deployment-time verification.