Check that signup, login, and checkout still work every morning

Every weekday at 6:00am in our time zone, before our customers are awake, I want a browser agent to walk through the critical paths on our website and tell us whether any of them broke overnight. Use Notte to drive a real browser for this.

There are four journeys I care about, and each one is checked independently on every run: (1) sign up for a new account, (2) log in with our existing test account, (3) add a product to the cart and reach the checkout screen, (4) submit the contact or demo request form. I will supply the site URL, the specific page URLs, the test login credentials, and a test email address to use for signup.

How to run each journey with Notte: call Start Session to open a cloud browser session, then Start Agent against that session with a plain description of the journey as the task. Agent runs are asynchronous, so Start Agent returns immediately and you must poll Get Agent Status every 10 to 15 seconds until the status leaves "active", then read the returned steps and answer. Give every journey its own session and its own agent run. Do not try to do all four in one session: Notte sessions close after roughly 3 idle minutes and about 15 minutes total, and one long session that fails halfway takes every remaining journey down with it.

Rule one, never complete a real purchase. The checkout journey is considered successful as soon as the checkout screen renders with its payment fields visible. The agent must not enter real payment details and must never click the final pay, place order, or confirm purchase button. Put this instruction inside the task text passed to Start Agent, not only here, so the agent itself is bound by it. Fill the contact or demo form with obviously marked test data (for example the name "Synthetic Monitor") so nobody on the sales team chases it as a real lead, and use a unique test email per run for signup so runs do not collide with each other.

Rule two, there are three possible outcomes per journey, not two: passed, broken, and blocked. Blocked means the agent was stopped by a bot check, a captcha, a WAF interstitial, or a rate limit rather than by a genuine defect in our site. Blocked is never treated as a failure: it does not create a Linear issue and it does not send a Slack message. Record it and report it in the Friday summary instead, so we do not wake anyone up over a false alarm. Only classify something as broken when the agent hit an actual error, a dead end, a missing element, or a page that never loaded.

Evidence: whenever a journey ends broken or blocked, immediately call Take Page Screenshot on that journey's session, before the session times out and closes, so we have a picture of the exact screen where it stalled.

For each broken journey, use Linear, but check before you create. First run Search Issues for an existing monitor issue for that journey using a fixed title convention of "Journey monitor: <journey name>". If an open issue already exists for that journey, use Add Comment to Issue with today's date, the agent's step by step trace of what it clicked, the step where it stalled, the error or unexpected page, and the screenshot. Only create a new issue when no open one exists, using Create Issue with the title convention above, the journey name, the full step by step trace, the failing step and URL, and the screenshot. Use Add Link to Issue to attach a link to the Notte agent run so an engineer can inspect the replay. A flow that stays broken for three days must be one ticket with three comments, never three tickets.

Every time you touch a monitor issue, keep a dated result log in the issue description using Update Issue, one line per run in the form "2026-08-10 broken, stalled at step 6 of 9". This log is what the Friday summary reads to compute pass rates, so keep it consistent.

Recoveries: if a journey passes today and it has an open monitor issue from a previous day, that is a recovery. Add a comment noting it passed and on what date, append the passing line to the dated log, and move the issue to a completed state with Update Issue.

Send a Slack message to our engineering channel only when at least one journey is broken, or when a previously failing journey recovered. Never send a daily "everything passed" ping, because that just trains people to ignore the channel. Combine everything from a single run into one message rather than posting per journey: for each break, the journey name, the step it stalled on, the URL, one plain sentence describing what happened, whether this is a new break or a repeat, and a link to the Linear issue. For each recovery, the journey name and how many days it had been failing.

On Fridays, after the run finishes, always post one extra Slack summary for the week even if everything passed: the pass rate per journey across the week's five runs (for example "Checkout 4/5"), which journeys were blocked and how often, and any monitor issues still open. Build this from the dated result logs on this week's monitor issues in Linear, found with Search Issues on the title convention and including issues closed earlier this week, combined with today's results. A journey with no monitor issue at all this week passed every day.