User journeys
A journey is the real thing a visitor does on your site - sign in, book, check out, send an enquiry. SiteOps replays it in a real browser on a schedule and tells you the exact step that broke, with a screenshot. This is the difference between "the homepage responded" and "customers can actually buy."
Journeys are the heart of SiteOps. A plain uptime check tells you a page returned 200; a journey proves the flow that makes you money still works end to end.
Build a journey with AI
Watch it end to end (3:06): describing the flow, the AI driving a real browser, it asking before it would submit anything real, then verifying all 10 steps.
You do not write scripts. Open the Journey page for a site and describe the flow like a real visitor would:
Buy a product - add an item to the basket and go through checkout to the payment screen.Sign in with the test account and reach the dashboard.Send an enquiry through the contact form.
Click Build with AI. The AI opens your site, reads the real buttons, links, dropdowns and fields (with their real selectors), and assembles the steps from what actually exists - so it can never invent a step that your site does not have. You watch it build live, step by step, with screenshots.
Keep it intent-level, not a click-script. Say "send an enquiry", not "click the ENQUIRE NOW button, fill Name, click Submit". Naming exact button text makes the build brittle; describing the goal lets the AI find the right controls itself.
Suggest journeys for my site
Not sure what to monitor? Click Suggest journeys for my site. The AI crawls your site live and returns the 3-4 journeys that matter most, ranked (most valuable first) as plain-English prompts. Click Use this on any one to drop it into Build with AI.
If the site is behind a login and you have set up a test account (below), Suggest signs in with that saved session and can suggest the flows inside your app (create a record, add a contact), not just the public login page. No login set up yet? It suggests what it can see and nudges you to add one.
Journeys behind a login
Many important flows sit behind sign-in. On the Journey page, turn on Requires login and set up a test account:
- Enter the login URL, email and password once. They are stored encrypted and go only to the browser that signs in - never into the AI's prompt, trajectory, or logs.
- Add a 2FA authenticator seed if the account uses one, and scheduled runs will pass 2FA unattended.
- On each monitored run, SiteOps reuses the saved signed-in session so it launches already logged in. If the session has expired, it signs in again automatically and saves the fresh session.
Turning Requires login off asks what to do with the saved account: Disable only (keep it, stop signing in), Change (enter a new account), or Remove (wipe the credentials and session). Login always actually submits - signing in is safe and never creates a record.
Review and edit the steps
After a build (or any time), the composer shows each step. You can add, remove, reorder, and edit steps by hand. Step types:
| Step | What it does |
|---|---|
| Click | Click a button or link (checkout / book / menu / CTA) |
| Fill | Type into a field. Use test values or tokens like {{email}}, {{today+7}} |
| Select | Choose a dropdown option (size, quantity, prescription) |
| Wait | Wait for text or an element to appear |
| Check | Assert success (text present, text absent like "Sold out", or an element present) |
| Checkout | Walk a shop or booking funnel to the payment screen and stop |
| Answer a multi-step form | Work through a quiz / multi-step booking or checkout |
| Stop | End the journey here (e.g. before payment) |
"Send the form for real" - the safe default
By default, when a journey reaches a form's submit button, SiteOps fills the form and confirms the submit is ready, but does not actually send it - so monitoring never spams a real enquiry, booking, or signup on someone else's site every run.
If you want a form really submitted (on your own site, where the enquiry/report comes back to you), each send-looking step has an "Actually send this form for real" toggle. It is off by default. When a build ends on a send step, SiteOps asks you a clear yes/no first - it never turns real submission on silently - and you can flip it on the step any time. Login and search always submit (they are safe); payment/booking commits are never clicked.
Run cadence
Set Run every on the journey (how often it replays). You can go as fast as your plan allows or slower to save runs; the value is clamped to your plan's floor. A sensible default is chosen for you.
Journey cadence by plan (fastest allowed): Free ~12h, Starter ~30 min, Pro ~15 min, Agency ~5 min. Your plan also sets how many journeys you can save (1 on Free up to 25 on Agency). Faster journey checks are the main reason to upgrade.
Verify & Save
Verify & Save runs the journey once to prove it works, then turns on 24/7 monitoring. Builds auto-save as they finish, so you never lose one. A journey that has never passed is kept but capped at warning severity until it does, so an unproven journey cannot page you.
When a journey breaks
A failed run opens an incident with a plain-English story - what happened, the likely cause, what to do next - plus the exact failing step and a screenshot. See Incidents & AI fixes.
Some outcomes are neutral - no incident, no alert - because your site is fine:
- Sold out / no availability - the funnel worked, there was just nothing to book.
- 2FA / one-time-code wall - needs a code we cannot get unattended (add an authenticator seed to pass it).
- Firewall blocked our checker - the site's WAF blocked our visit; the fix is to allowlist us.
"The site was edited" - one-click fix
Sites change. When a control your journey used has been renamed or moved (say a "Book an Appointment Now" button becomes "Book an Appointment"), SiteOps does not cry "outage." First it tries to self-heal: if a control still leads to the same destination page, it follows it and the run stays healthy with no incident. If it genuinely cannot, it raises a warning (never a critical page) that says the button looks renamed, and offers a one-click "Apply suggested fix" grounded in the live controls actually on the page now. Applying it re-points the step and re-runs to confirm - if the fix works the incident resolves and you get a recovery notice; if not, it re-opens. SiteOps never silently points your journey at the wrong button.
Do it by asking the AI
Everything here is also one sentence to the assistant: build a journey for example.com that adds a product to the cart and checks out, set my checkout journey to run every 15 minutes, or suggest journeys for my site. It drafts, previews, and applies on your confirmation. See Using the AI assistant.
Next: what happens when something breaks - Incidents & AI fixes.