Browser checks

A browser check is a synthetic monitor that runs a Playwright script in a real Chromium browser on a schedule. Use it for the things HTTP checks can’t tell you:

• Does the login flow work end-to-end with real JavaScript?
• Does the checkout button actually charge a card?
• Does the multi-step signup form submit correctly?
• Did the latest deploy break the homepage’s hero CTA?

When to use browser checks

• You have a critical user flow with multiple steps and JavaScript-driven UI.
• You’ve ever shipped a deploy that broke a button without breaking any HTTP endpoint.
• You want to monitor third-party JavaScript (analytics, payment widgets, fonts) that an HTTP check can’t observe.

When NOT to use them

• For “is my API up?” use HTTP checks. Browser checks cost ~30× more compute and are slower.
• For “is my page fast for real users?” use RUM. Browser checks measure synthetic latency from one IP, not your users’ experience.
• For low-priority pages. Reserve browser checks for the 5–10 most important user flows.

How it works

1. You write a Playwright script in JavaScript, driving the browser with the page API and step() helpers.
2. SiteQwality runs your script in headless Chromium on Lambda on the schedule (5m, 10m, 15m, 30m, 1h).
3. Each step’s pass/fail, duration, and a screenshot are captured.
4. On every run, a HAR file (full network log) and a video are uploaded to S3.
5. Web vitals (LCP, FCP, CLS, TTFB) are extracted from the page and reported.
6. Console errors and unhandled exceptions are captured.
7. Status flips to failed when steps fail, and alerts fire on that first confirmed failure. Browser checks have no consecutive-failure debounce; the confirmation_threshold knob is HTTP-only.

The script runs inside a sandboxed async function with page (Playwright Page) and step (your wrapper for tracked steps) injected:

await step('Open homepage', async () => {
  await page.goto('https://example.com');
});

await step('Click sign in', async () => {
  await page.click('text=Sign in');
});

await step('Fill credentials', async () => {
  await page.fill('input[name="email"]', 'demo@example.com');
  await page.fill('input[name="password"]', 'demo-password');
  await page.click('button[type="submit"]');
});

await step('Confirm dashboard loaded', async () => {
  await page.waitForSelector('h1:has-text("Dashboard")');
});

Anything you can do with Playwright works inside a step.

What’s captured

Artifact	Where
Step results	Pass/fail, duration, error message per step.
Screenshots	Auto-captured after each step (pass or fail).
HAR file	Full network capture, downloadable from the run page.
Video	1280×720 MP4 of the entire run.
Web vitals	LCP, FCP, CLS, TTFB extracted via PerformanceObserver.
Console errors	Anything logged at console.error or thrown.
Trace IDs	Outgoing requests get a traceparent header injected, allowing distributed-tracing correlation.

Frequencies and pricing

Available frequencies: 5m, 10m, 15m, 30m, 1h. Browser checks are billed per run; the dashboard shows your current monthly count under Settings → Billing → Usage.

Caution

Browser checks are paid-only. Single-region runs are included on Pro plans; multi-region checks need a higher tier.

Failure alerts carry the failed step and a screenshot

When a browser check fails, the alert names the first failed step and links to the screenshot captured at that step, so you can often diagnose without opening the dashboard.

This enrichment appears on email and Slack alerts. Other channels get the monitor name and error message only.

Three things determine whether you get it:

• The failure must happen inside a step() call. A script that throws at the top level, fails to navigate, or times out before any step runs produces no step results, so there is no step name and no screenshot. Wrap your actions in step('name', async () => { ... }) if you want named failure context.
• The step must have a name. An unnamed step yields no enrichment at all, including no screenshot link.
• Delayed alerts are not enriched. If a notification group has delay_send_after_minutes set, the delayed alert arrives without the step name or screenshot. The immediate alert is the enriched one.

Screenshot links are short-lived

The screenshot URL in an alert is pre-signed with the alerting service’s own temporary credentials, so it stops working when that credential session expires, typically within a few hours rather than days.

Open it while triaging. After that, get the screenshot from the check’s run detail in the dashboard, where it does not expire.

Regions

Browser checks all run from US East today

The region selector accepts the same four values as HTTP checks, but only one browser-runner exists in production, in aws-us-east-1. Whichever regions you select:

• the check executes in US East (Virginia);
• the result is recorded against aws-us-east-1, which is where it genuinely ran, not the region you asked for;
• selecting several regions produces one run and one result, not one per region;
• min_healthy_regions is capped to the number of regions that can actually serve the check, so a 3-of-3 configuration is evaluated as 1-of-1. Without that cap such a monitor could never report healthy.

POST /browser_check/{id}/run tells you the truth in its response: it reports the region the run actually executed in.

This is a browser-check limitation only. HTTP checks really do run from all four regions.

Constraints

• Script size: anything under 50KB. The script is stored in Postgres alongside the check config.
• Timeout: 1–300 seconds per run. Includes browser startup; the user script gets timeout - 30s.
• Regions: accepts aws-us-east-1, aws-us-east-2, aws-us-west-1, aws-eu-west-2, with the caveat above.

See also

Quickstart A working browser check in 10 minutes: a login flow against a public demo.

Reference Step API, supported assertions, captured artifacts.

HTTP checks The cheaper alternative for plain endpoint health.