Journeys

Checks that run after another ​

Use Runs after when one check must create a value that another check needs. A common example is Signup publishing a new test email and password, followed by Login using that account.

This is a data dependency. It is different from an advanced named chain, which only controls execution order and carries no values. Both are described below because choosing the wrong one produces a very different result.

Configure Runs after ​

  1. Open the parent check and declare each value it will publish under Outputs. Give each a useful description, such as “the order number on the confirmation page.” That description is what the parent agent is told to look for.
  2. Complete the following check's attended learning run.
  3. In its Start watching or Change schedule dialog, choose the parent under Runs after.
  4. Save the relationship.

Both checks must belong to the same site. A check can have one immediate parent, and Journeys refuses self-references, missing or cross-site parents, and cycles. The following check automatically declares the parent's output names as input variables without overwriting variables you already defined.

The follower receives each declared value as a structured input even when its instructions do not contain . Use the placeholder when the value must be interpolated into the prose or start URL; it is not required merely to make the value available to the agent.

What runs ​

The following check no longer has a schedule of its own. At the parent's scheduled time:

  1. The parent runs and is asked to publish its declared outputs.
  2. If it passes with all required values, Journeys supplies them to the follower.
  3. The follower runs. A longer line continues in the same way.

Only unattended schedule and CI triggers release followers. Clicking Run on a parent runs that check and stops, so a manual diagnosis does not alter the health history of every follower. Journeys temporarily holds values from that passing run; a later Run on the follower can reuse them. If no usable values are held, its button identifies and starts the root check instead. After that root passes, return to the follower and choose Run again to use the held values. One click still runs one check. Held values are temporary and can disappear after a service restart.

A follower run using held values is diagnostic, not a scheduled health sample. It does not release another follower of its own.

When a follower is skipped ​

Journeys records the follower as Not run when:

  • the parent did not pass;
  • the parent passed but published nothing;
  • one or more required values were missing; or
  • an invalid cycle exists in stored data.

This skipped row explains the gap in History, but it is not a check verdict. It does not count as downtime, change “last checked,” spend steps on the follower, or send a failure-only notification. Fix the parent result or output, then wait for the next scheduled firing or debug the line manually.

Secret outputs ​

Mark an output secret when its value is a password, token, or other credential. Journeys redacts it from the follower's report and activity just as it redacts a secret input.

The parent browser still had to read the value from the source page. Marking the output secret cannot retroactively hide it from the parent page or from evidence captured before it became structured output. Avoid exposing production secrets in the browser in the first place.

Advanced: named execution chains ​

Named chains are an automation API feature and are not shown in the current hosted interface. They are for existing integrations that need to run a named, ordered group of checks, often from CI.

A named chain has ordered steps. One step may contain several checks that start in parallel; Journeys waits for the whole step before starting the next. A failure stops progression, and later checks receive Not run rows. The caller polls the chain-run ID for the combined result.

Named-chain membership carries no values, has no schedule of its own, and does not fire any Runs after followers. Each member uses its own saved variables. Deleting a named chain does not delete its checks.

For an existing chain called nightly, trigger it with an API token:

bash
curl -X POST "$JOURNEYS_URL/api/sites/$SITE/chains/nightly/run" \
  -H "Authorization: Bearer $JOURNEYS_TOKEN" \
  -H 'Content-Type: application/json' \
  -d '{"trigger":"ci"}'

The response contains chainRunId. Poll it until the status changes from running:

bash
curl "$JOURNEYS_URL/api/chains/runs/$CHAIN_RUN" \
  -H "Authorization: Bearer $JOURNEYS_TOKEN"

Accounts without existing automation access should use Runs after in the interface rather than relying on these endpoints.