browser flows
Know your login still works, not just that it answers
An HTTP check on your login page proves the page loads. It cannot tell you that the form still submits, that the session cookie is still set, or that the OAuth secret has not expired. A browser flow signs in the way a user does and tells you when that stops working.
The failure an HTTP check cannot see
Every outage postmortem has one of these. The login page returned 200 the whole time, so the monitor stayed green, while nobody could actually get in. An expired OAuth client secret, a JavaScript bundle that 404s, a session cookie that stopped being set: none of them change the status line of the page that hosts the form. A flow check runs the sign-in itself, so the thing you care about is the thing being measured.
Record it, do not write it
Chrome ships a Recorder in DevTools. Sign in once with it running, export the recording as JSON, and drop the file into the monitor form. It becomes steps you can read and edit. Selectors come across as written, the focus click before typing folds into the fill, and anything the recording could not carry is listed rather than guessed at.
The password never lands in the config
A recording holds whatever you typed, in clear text. The import drops the value of anything that looks like a password or a token instead of copying it, and points you at an organization secret. The monitor then stores a reference like {{login_password}}, never the credential. Use a dedicated low-privilege account for this, not a real one and never an admin.
A failure that names itself
When a step fails you get the step, the reason, and the page as it stood: the URL the browser had reached, the title, the visible text, and whatever the page logged to the browser console. Most of the time the URL settles it on its own. Still sitting on the login path after a submit means the credentials never took.
See the break coming, not just the break
Every run is kept, passing ones included, with each step's outcome and how long it took. The monitor page draws one small chart per step, each on its own scale, so a wait that has crept from 200 ms to four seconds stands out instead of flattening against a step that takes a second anyway. That is the login two weeks before it starts failing. Failed steps sit out of the line and are counted beside it, because a step that fails waits out its whole timeout and would otherwise bury every timing around it.
The heaviest check, priced that way
A flow drives a real browser process per run, which costs far more than an HTTP request. So it runs no faster than every five minutes, the number of flow monitors is capped by plan, and flows only run in regions where a browser engine is available. Watch the one journey that matters with a flow, and keep plain HTTP checks on everything else.
A 200 is not a login
The same minute, two checks against the same page. The HTTP check times DNS, the TCP connect, the TLS handshake and the first byte, finds all four healthy, and stops at the status line. The flow keeps going: it fills the form, submits, and looks for the page that only exists once you are signed in. Everything here runs against the-internet.herokuapp.com, a public practice site, so you can build the same monitor and watch it work.
Record it once, keep the steps
Chrome's own Recorder exports what you did as JSON. Dropping that file in turns it into steps. The focus click before typing collapses into the fill, the submit button's icon becomes the button, and the password never survives the trip.
When it breaks, it says where
A failed step names itself, and the run hands back the page it was looking at. Usually the URL alone settles it: still on the login page means the credentials never took.
A login flow, as the API stores it
{
"type": "flow",
"start_url": "https://the-internet.herokuapp.com/login",
"steps": [
{"op": "fill", "selector": "#username", "value": "tomsmith"},
{"op": "fill", "selector": "#password", "value": "{{login_password}}"},
{"op": "click", "selector": "#login > button"},
{"op": "assert_url", "contains": "/secure"},
{"op": "assert_text", "contains": "secure area"}
],
"timeout": 30000,
"step_timeout": 10000,
"verify_tls": true
}Links
At a glance
- What it proves a real sign-in, end to end
- Steps fill, click, wait, assert
- Authoring import a Chrome recording
- Credentials stored as a secret reference
- Check interval from every 5 minutes
- Price to start free, no card