Browser Monitoring

SiteBrief runs a self-hosted headless Chromium (Browserless) to check your sites the way a real user would — full JS rendering, real performance metrics, accessibility violations, and multi-step flows.

💡

Tip:All browser-based features require Browserless to be configured (BROWSERLESS_URL + BROWSERLESS_TOKEN env vars). If Browserless is not set up, each feature either falls back gracefully or shows a clear error. See the infrastructure guide for setup.

Why real-browser checks?

Plain HTTP checks fetch a URL the way curl does — fast, but they see only the raw HTML before JavaScript runs. This creates two classes of false results:

False negatives — a React/Next.js site returns HTTP 200 with an empty shell; the check says "up" even though nothing renders.
False positives — a keyword check reports "missing" because the word is injected by JS after load.

Browser checks solve both by running a real Chromium session — the same engine your users use.

Accessibility scan (axe-core)

SiteBrief injects axe-core 4.9.1 into a live browser session and runs a full WCAG 2.1 AA audit — covering 80+ rules across perceivable, operable, understandable, and robust criteria.

What you get

Risk score (0–100) — higher is worse. Derived from violation count and severity.
Risk level — critical / high / medium / low.
Legal exposure — EU (EAA / EN 301 549) and US (ADA / Section 508) risk notes.
Top issues — each with impact level, one-sentence explanation, and actionable fix.
Priority action list — three things to fix first.

How it works

Browser navigates to the URL and waits for networkidle2.
axe-core script is injected from CDN and runs against the live DOM.
Violations (with HTML context) are sent to Claude Haiku for AI analysis.
Result is stored on the site and shown in the Accessibility panel.

ℹ️

Note:Scans run automatically on a rolling schedule (3 sites per day, oldest-first). Pro and Agency plans only. You can also trigger a manual scan from the site page.

Fallback behaviour

If Browserless is not configured, scans fall back to the external AccessGuard API (ACCESSGUARD_API_URL + ACCESSGUARD_API_SECRET). If neither is configured, the scan button returns an error.

Core Web Vitals — real browser fallback

SiteBrief measures Core Web Vitals using two methods, in priority order:

Method	LCP	CLS	INP	FCP	TTFB	Score	Requires
PSI / Lighthouse	✓	✓	✓	✓	✓	✓	PAGESPEED_API_KEY
Browserless (fallback)	✓	✓	—	✓	✓	—	BROWSERLESS_URL

The Browserless method uses PerformanceObserver (LCP, CLS) and the Navigation Timing API (TTFB, FCP) inside a real Chrome session. Long Task API provides TBT. INP and the 0–100 performance score are only available via PSI.

💡

Tip:If you don't have a PAGESPEED_API_KEY, Browserless gives you free, real-browser CWV data with no quota limits.

JS & console error detection

Every page load in a browser session fires a PerformanceObserver for pageerror and listens on console.error. SiteBrief captures uncaught JavaScript exceptions and console errors that users see but HTTP checks can never detect.

Noise is filtered automatically — Chrome extension errors, [Violation] messages, favicon 404s, and third-party script errors with no local context are excluded.

Enable JS error monitoringon a site from its monitoring settings. Errors are stored per-check and visible in the site's Error log panel.

Keyword checks on SPA / React / Next.js sites

When a keyword check runs on a site that uses client-side rendering, a plain HTTP fetch returns an empty shell — the keyword isn't there yet. SiteBrief detects this and re-fetches using Browserless renderHTML (networkidle2 wait), so the check runs against the fully rendered page.

No configuration needed — the browser fallback is automatic for any site where the initial HTTP response contains fewer than ~300 words or no keyword candidates.

Broken links on SPA sites

The broken links crawler detects SPA shells automatically: if the raw HTML body is under 8 KB or contains fewer than 3 links, SiteBrief considers it a JavaScript-rendered app and re-fetches via Browserless. The fully rendered DOM — including all links injected by React Router, Next.js, or any other client-side framework — is then crawled normally.

Both the root page and one-level-deep internal pages benefit from this fallback. Broken link checks run weekly on Pro/Agency plans.

Synthetic transactions (Browser Scenario Builder)

Build multi-step browser flows with a drag-and-drop step editor. Available step types:

Step type	What it does	Key fields
Go to URL	Navigate to a page	url, waitUntil
Fill input	Type into a form field	selector, value
Click	Click a button or link	selector
Select option	Choose a dropdown value	selector, value
Wait	Wait for element or fixed time	selector or ms
Assert text	Check page contains (or not) text	text, not
Assert URL	Check current URL contains pattern	pattern
Assert selector	Check element exists (or not)	selector, not
Set cookie	Inject auth cookie before navigation	cookieName, cookieValue, domain

💡

Tip:Use Set cookie as the first step to inject a session token, then navigate directly to an authenticated page — without building a full login flow. The cookie value is masked in the UI and never exposed in logs.

Auth-protected page checks

To monitor a page that requires login, you have two options:

Login flow — Go to login page → Fill email → Fill password → Click submit → Assert URL contains /dashboard. Straightforward but slower (~3–5s per run).
Cookie inject — Set cookie (session_token = your-value) → Go to protected URL → Assert text. Faster (~1s) but requires keeping the cookie value current.

Scenarios are saved per site and run on the cron schedule alongside other checks.

Screenshots

On-demand screenshots are taken via Browserless with full JS rendering — no blank pages on React or Next.js sites. Screenshots are stored in Supabase Storage and used by the Visual AI Diff feature to detect layout regressions after deploys.