A homepage returning 200 isn't a working product
A flow monitor's configuration is a short executable spec: several HTTP requests in order, with assertions between them. Sign in, read the token back, call the endpoint it authorises — so the question a check answers is whether somebody can still do the thing they came to do.
Requests per run
Run time limit
Minimum interval
Result history
Everything you need
A closer look at what you get, from the first check to the alert that reaches you.
Auth is a first-class step
Bearer and basic credentials, form posts to a token endpoint, and cookie headers are part of the spec rather than something to work around.
Tokens are verified, not just received
A returned JWT is checked against a live JWKS endpoint — ES256 signature and expiry — so a rotated signing key surfaces as a failure instead of a 200.
A failure names a line of your spec
The failing test's title, its line number, and expected against observed, rendered on the source with that line marked. Compare with `HTTP 500`.
No new unit to price
A run bills one check per HTTP request it made, drawn from the same allowance every other monitor type uses.
Alerts you already configured
Flow failures go through the same alert channels, cooldowns, and maintenance windows as every other monitor.
Runs only against verified domains
An HTTP monitor sends one request a stranger could have sent anyway; a flow drives a whole sequence, so it runs only against domains your team has verified.
How it works
Three steps from an empty dashboard to checks that run on their own.
Verify the domain
Prove the team controls the host the flow will drive. A flow won't run against a domain nobody has verified.
Write the spec
A few requests in order, with the assertions that matter between them: a status, a field's value, a token that verifies.
Get the failing line
A failing run names the assertion that broke and the line it sits on, and alerts through your existing channels.
Frequently asked questions
The questions people ask most before they start monitoring.
How often can a flow run?
Every 15 minutes at the fastest, then 30 minutes, hourly, every 3, 6 or 12 hours, or daily; hourly is the default. Anything you need caught faster wants an HTTP monitor on the endpoint the flow depends on, which runs at 1-minute resolution.
Does a flow drive a browser?
No. A flow makes HTTP requests, parses URLs, and verifies tokens. Nothing clicks, fills a field, or renders a page, so a failure that only appears in a browser won't show up here.
What can't a spec express?
Branching, computation, and generated data. Assertions compare for equality or truthiness, so there are no regex or substring matches, and a signup flow needing a fresh address each run wants a fixed fixture account instead.
What happens when a flow can't run at all?
An unparseable spec, or a host outside reach, is reported as "cannot run" — deliberately never an outage, and it never pages anyone.
How long does a run get?
Thirty seconds and 20 requests, whichever comes first. That covers a sign-in, a read-back, and the calls the token authorises.
Start monitoring your services
Create your first monitor in under 2 minutes. No credit card required to start.