Browser flows

Test your app in a real browser

A 200 on the homepage still hides a broken login. A browser flow clicks through the live page and asserts on what visitors see after JavaScript runs.

Monitor a site free for 7 daysView pricing
Examples

Three click-throughs teams run on a schedule

Each example is a short executable spec — the same language the dashboard editor uses. No Playwright suite to maintain.

use browser

test "signing in lands on the dashboard" {
	when {
		browser.open "https://app.example.com/login"
		browser.fill textbox "Email" with "m@example.com"
		browser.fill textbox "Password" with "monitor-pw"
		browser.click button "Sign in"
	}
	then {
		eventually within 5s {
			expect browser.path "/dashboard"
		}
		expect browser.heading "Dashboard"
	}
}
use browser

test "checkout reaches confirmation" {
	when {
		browser.open "https://shop.example.com/cart"
		browser.click button "Checkout"
		browser.fill textbox "Card" with "4242424242424242"
		browser.click button "Pay now"
	}
	then {
		eventually within 10s {
			expect browser.heading "Order confirmed"
		}
	}
}
use browser

test "the settings page paints" {
	when {
		browser.open "https://app.example.com/settings"
	}
	then {
		eventually within 5s {
			expect browser.heading "Settings"
		}
		expect browser.button "Save"
	}
}

Sign-in lands on the dashboard

Fill the Email and Password fields, click Sign in, and expect the dashboard heading once the client has routed.

Checkout reaches the confirmation

Walk the cart through to pay, then assert on the confirmation heading that only renders after payment succeeds.

A client-rendered page paints

Open a SPA route and wait for the heading that hydration is supposed to show — a 200 on the shell is not enough.
Why a browser

HTTP can only see the request

An API flow signs in and calls the endpoint the token authorises — the right check when the path is JSON. A browser flow is for the failures that only appear once the page has painted: a client-rendered form, a checkout that depends on hydration, a dashboard that never routes.

HTTP flow

  • Posts credentials and reads the token back
  • Bills one ping per request from the shared allowance
  • Catches a broken session store or JWKS rotation

Browser flow

  • Opens the page, fills fields, clicks buttons
  • Bills $2.50 per 1,000 runs on its own meter
  • Catches a login that breaks only after JavaScript runs
Pricing

Priced per run, not per click

One browser run bills $2.50 per 1,000 on a separate flow-run meter — none included in the subscription. HTTP-only flows still draw from the shared ping allowance.

$2.50per 1,000 browser runs
15 minFastest schedule
1 hDefault schedule

Hourly sign-in check ≈ a few cents a month. Pair with a 1-minute HTTP monitor when you need faster detection on the endpoint the page depends on.

How it works

From a verified domain to a named failure

Three steps from an empty dashboard to a click-through that pages you when it breaks.

  1. Verify the domain

    Prove the team controls the host the browser will drive. A session will not navigate outside verified domains.

  2. Write the click-through

    Open the page, fill fields by role and name, click the button, and assert on the heading or path that means "it worked".

  3. Get alerted on the failing step

    A broken sign-in or checkout alerts through your existing channels, naming the expectation that failed.
sign-in.spec
browser.open "…/login"
browser.fill textbox "Email" with …
browser.click button "Sign in"
expect browser.heading "Dashboard"
✓ 4 steps · 2.1s
Next run in 15 min
FAQ

Questions about browser flows

When to use a browser session, how a run is billed, and what a short spec can express.

When should I use a browser flow instead of HTTP?

When the failure only appears once JavaScript has run and the page is laid out — a client-rendered login, a checkout that depends on hydration, a dashboard that never paints. An API path that answers with JSON stays on an HTTP flow.

How is a browser run billed?

One event per run on a separate flow-run meter at $2.50 per 1,000 runs — none included in the subscription — plus the measured session seconds on the cost ledger. HTTP-only flows still bill one ping per request from the shared allowance.

How often can a browser flow run?

Every 15 minutes at the fastest, then 30 minutes, hourly, every 3, 6 or 12 hours, or daily; hourly is the default. Pair it with a 1-minute HTTP monitor on the endpoint the page depends on when you need faster detection.

Do I need Playwright or a test suite?

No. The flow is a short executable spec in the dashboard — open, fill, click, expect — not a repo of Playwright scripts to maintain. Teams that already own a Playwright suite and want monitors-as-code may still prefer a tool built around that model.

What can't a browser flow express?

Branching, computation, and generated data. A signup that needs a fresh address every run wants a fixed fixture account, the same constraint every other flow has.

Catch the break your visitors would hit

Write a click-through once. Run it on a schedule. Get the failing line when the page stops working.

Monitor a site free for 7 days