Journeys

Start a check signed in ​

There are two ways to test an authenticated feature:

  • Let the check sign in itself, using variables or credentials published by a parent check. Choose this when the login flow is part of what you are testing.
  • Give several checks a saved browser session so they start inside the product. Choose this when login is setup, not the behavior each check should measure.

Saved sessions belong to one site. They contain browser cookies and storage, not a Journeys account session.

Create and refresh a saved session ​

  1. Create a custom or catalog check whose job is to sign in from a signed-out browser. Teach and approve it like any other check.
  2. Open Site settings → Sessions and choose Add a session.
  3. Give the session a recognizable name and select the login check under Refreshed by.
  4. Optionally add a signed-in check: a URL fragment under URL contains, text under Page shows, or both.
  5. Save, then run the login check. Its next passing run fills the session.

Every later passing run of that login check replaces the saved state, so a nightly login schedule can keep it fresh. A failed login run leaves the last working session untouched.

The Sessions list reports when the state was captured and how many cookies and browser origins it contains. It never reveals the cookies or storage. The state is encrypted and decrypted only for a browser run that uses it.

Use the session in another check ​

Open the target check and select the saved session under Start signed in. Save the check and perform an attended run to confirm it starts in the right account and area.

If you configured a signed-in check, Journeys tests it before the agent's first step. URL contains compares the destination's host and path, and Page shows looks for the supplied text; both must match when both are present. A check cannot start with a session that has not been captured yet. A captured session that fails this liveness check is Could not check, not a false claim that the product is Down.

Deleting a session does not delete checks that selected it. Their selection is cleared and future runs start signed out, so edit or pause them first.

Email confirmation ​

For flows using Journeys' test mailbox, the agent gets a unique test email address and generated password for that run. It can wait for the message, enter a verification code, or open a confirmation link. Codes and links travel through the same protected channel as secret variables and are redacted from evidence. On a resend, Journeys waits for the new message rather than reusing an invalidated code.

If a message says the address was refused or already registered instead of containing a code or link, the run reports that reading as the blocker. It does not guess a code.

Unsupported authentication paths ​

The current hosted interface does not provide SMS or TOTP retrieval. It also does not offer browser-session capture for third-party social-login flows, and Google is known to reject replayed automated sessions even when the cookies are valid.

Test the application after its own login when possible. If the exact provider handshake or a non-email second factor is essential to the check, that flow is not currently supported.