Monitoring a page behind a login

What a flow is

A flow is the short list of actions someone takes to get in: go to the login page, type a username, type a password, click the button. You write those steps once, on the Monitors page, and Mend performs them in a real browser before every scheduled scan. The audit then runs against the page you landed on.

Steps are ordinary things — go to a URL, type into a field, click, wait for something to appear, check something is visible. A flow is capped at 20 steps, which is far more than a sign-in needs; if you are approaching it, you are probably scripting a journey rather than a login, and each step is time your scan spends not auditing.

You can reorder, edit, and delete steps at any time. A monitor with no steps is just a URL scan, which is what every monitor was before this existed.

Recording a sign-in instead of writing it

Writing steps by hand means finding a CSS selector for your own login form, which is fine if you have devtools open and tedious if you do not. So there is a second way in: Record the sign-in opens the page in a browser on Mend's servers, streams it into your browser as video, and writes a step for each thing you do. When you press Done the steps land in the same editor, where you review them and save.

It is a shortcut, not a separate feature. Everything the recorder produces, you can write by hand, and the editor is the accessible path: the video stream is a picture of another browser, so it cannot be read by a screen reader or operated by keyboard, and no amount of markup would change that. What it records appears as an ordinary list of text either way, and that list is what gets saved.

Two things the recorder does that are easy to miss. It never records a password — typing one signs you in, and the step remembers only which field it was, so you attach a stored credential to it afterwards, and the flow will not save until you do. And it adds the waits for you: a click that navigates becomes a wait for the new address, and a click that reveals a field becomes a wait for that field. While you are recording, you are the wait; overnight, nothing is.

What it cannot do: sign-in windows that open in a pop-up — most “Continue with Google” buttons — are not recorded at all, because the recorder drives one tab. Sites that block automated browsers, and anything behind a CAPTCHA or a hardware key, will not record either. Write the steps by hand for those.

Recording holds a real browser open on our servers, so there is one recording at a time per account, it closes after three minutes of inactivity, and it closes after ten minutes regardless. Both closures keep whatever was recorded up to that point. Nothing from a recording session is stored: no video, no screenshots, no half-finished flow. The steps exist in your browser until you save them.

Credentials are write-only

Passwords never go into a step. They go into stored credentials, a per-account vault, and a step refers to one by name. That separation is structural rather than advisory: the step editor has no password field, so there is no way to put a plaintext password into a flow even if you want to.

A stored credential is encrypted with AES-256-GCM before it is written, and it is write-only. Mend can use it to sign in, and can never show it back — not on the page, not in a data export, not to support, not to us. The vault lists names and dates and has no code path that returns a value. If you forget one, you replace it; nobody can look it up for you.

Deleting a credential that a flow still refers to is refused, and the message names the pages using it. A slot deleted out from under a live flow would not break anything until the next overnight run, halfway through a sign-in, which is the worst place to find out.

What Mend refuses to do

It will not store an audit of your login page. If a flow finishes somewhere that still looks like a sign-in — a password field on the page, or a URL or title that reads like one — the run fails with an error instead of saving. An expired session otherwise turns into a quietly wrong answer: Mend would audit the login form, store it as that page, and report that yesterday's violations had been fixed.

That check treats a password field on the page it finished on as conclusive, and it cannot tell a login form apart from a legitimate one. So there is a real limitation to know about: a monitor pointed at a change-password or account-security screen will fail its runs, because that page looks exactly like a failed sign-in. We chose that direction deliberately — a failure you can see and act on is better than a silently corrupted history — but if this is the page you need to audit, monitor a neighbouring one instead.

It will not store a scan that contains one of your credentials. Audit results include HTML snippets of failing elements, and a form can put a typed value into its own markup. Every stored credential is removed from a run's output before it is written, and a run whose output still contains one is discarded rather than saved.

A monitor never has more access than the account you gave it. Mend signs in as that user and sees exactly what that user sees. The usual advice applies and we would rather say it plainly: make a dedicated account for monitoring, give it the least access that still reaches the pages you care about, and point it at staging where you can.