Flow Watch

Email breaks quietly after launch: an API key expires, a DNS record changes, a plugin update drops the verification email. Flow Watch re-runs a flow that passed, on a schedule, and tells you when it stops working.

Guide

Record once, replay on a schedule

After your agent runs a signup, magic-link or password-reset flow that passes, it offers to watch it. If you say yes, it writes down the steps it just took as a recipe. Flowproof then replays that recipe in a headless browser on a schedule, with no AI involved: same steps, a fresh test address each time, the same grading as a normal run, and cleanup afterwards.

Each replay is compared with the last five runs that passed. If something got worse, you get an alert.

Ask your agent to create a watch

Right after a green test run, say:

Prompt

That signup flow passed. Use Flowproof to create a Flow Watch for it that runs every night, then check the verification run with list_watches and tell me whether it passed.

The agent calls create_watch. Flowproof immediately does a verification run, which takes one to three minutes. The agent reads the result with list_watches; if a step failed, it fixes that step and submits the watch again under the same name. Only a watch whose verification run passed goes on the schedule, and verification runs never alert anyone.

You can also ask the agent to:

run a watch now, to check a fix (run_watch; once per watch every 10 minutes);
pause or resume it (pause_watch), for example while you redesign the signup page;
show its recent runs (list_watches).

This is roughly what a recipe looks like. Your agent writes it; you don’t have to.

Recipe

{
  "version": 1,
  "steps": [
    { "action": "goto", "url": "https://app.example.com/signup" },
    { "action": "fill", "selector": { "label": "Email" }, "value": "{{address}}" },
    { "action": "fill", "selector": { "label": "Password" }, "value": "{{persona.password}}" },
    { "action": "click", "selector": { "role": "button", "name": "Create account" } },
    { "action": "expect_email", "kind": "verify_email", "within_seconds": 120 },
    { "action": "follow_link", "kind": "verify_link", "expect_text": "Email confirmed" }
  ]
}

Fields are found by their visible label or button text, not by CSS classes, so a restyle doesn’t break the watch. The password is generated fresh for every run and never stored.

Alerts

Where: by email to your account’s address, and to Slack if you give your agent a Slack incoming-webhook URL.
Retry first: the first failed run schedules a retry 15 minutes later. You’re only told if the retry fails too. A one-off blip passes silently.
One alert per problem: a flow that stays broken for a week is one alert, not seven. You hear again only if it gets worse.
Recovered: the first passing run after an alert sends a “recovered” message.

What counts as a change

Level	Examples
Broken	An expected email is missing. SPF, DKIM or DMARC was passing and now fails. The email’s link returns an error or can’t be reached. The link loads but the app no longer shows its success message.
Worse	An email is slower than both your threshold (30 seconds unless you set another) and twice its usual time. A new failed check. The grade drops a whole letter (A- to B+ counts; A to A- doesn’t).
Noted, no alert	The subject changed. The sender changed. The link now points at a different host. Reported once, then it becomes the new normal.

Safety gates

These are checked when a watch is created and again before every run:

Cleanup must be armed on the project. Every run signs up a real account on your live site, so without armed cleanup a nightly watch would leave a test user behind every night. If a run’s cleanup fails or is incomplete, the watch pauses and you’re told.
One site per watch. Every page the recipe opens directly must be on the same https site; other pages are reached only by clicking, like a person would. Private and internal addresses are refused.
Only the test address signs up. The recipe must use the run’s fresh address; a typed-in email address or password is refused.
Gentle on your site. At most 6 runs an hour against any one site, across all watches.

Let Flowproof do the clicks

Some agents won’t create accounts on a live site. If yours says so, it can hand the steps to Flowproof instead: it reads your signup page, writes the steps as a recipe, and calls run_recipe_once. Flowproof’s browser does them once, inside the agent’s current test run, with no AI involved, and follows the link in the email itself. The agent follows along with get_recipe_run, and the report marks those steps as done by Flowproof’s browser.

It only runs on projects where you turned on Flowproof may run sign-up steps on your site (Projects page), on the Flow Watch or Agency plan, with cleanup armed so the test account is removed when the run ends. It never pays, never types card details, and never solves a captcha.

Plan limits

Plan	Watches	How often, at most
Flow Watch ($15/month)	3	Every 6 hours
Agency ($99/month)	30	Every hour
Free and Flow Pass	None

Watches count across your whole account, not per project. The default schedule is once a day. Watch runs don’t count toward your plan’s test runs. If your plan lapses, watches stop at its end date. See Plans and limits.

A watch can also check every pull request’s preview deploy before it merges, from CI, with the grade posted on the pull request. Those checks do count as runs. See Pull request checks.