Launch allowances are documented limits—not “free forever” claims.See verified limits →

SITEBORNE SIGNAL MODULE

SiteSentinel — automated website verification

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

BUSINESS OUTCOME

What this capability changes.

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

Best for

All maintained websites, Agencies

AI: noneStatus: active

From $1,500

Care from $150/month

Illustrative allowance usageAvailable

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.

A real-world use

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

Transactional email

Launch allowance for low-volume transactional email.

View all referenced allowances
  • Transactional email: 3,000 emails/month, 100/day, one custom domain, one webhook endpoint, 30-day retention.
  • Asynchronous workflow: 10,000 operations/day and 24-hour message retention; a typical successful delivery uses three operations.
  • Browser verification: 10 browser minutes/day on Workers Free.

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.