Skip to main content
A Runbook is a mode for running a journey that’s designed for people who aren’t the journey’s author — support agents, QA analysts, operations teams, or anyone who needs to execute a workflow reliably and document what happened. Instead of exposing the raw journey canvas, Runbook mode presents a clean, step-by-step interface and collects evidence automatically.

​
When to use it

Use Runbooks when:
  • A support agent needs to reproduce a customer issue without knowing how the API works under the hood.
  • A QA analyst needs to run a specific scenario and submit evidence that it passed or failed.
  • An operations team needs a documented, repeatable procedure for a routine task.
  • You need to prove to stakeholders that a workflow was executed correctly, with receipts.
Runbooks are most valuable when the audience is not the journey’s author and when the output (evidence, pass/fail record) matters as much as the execution itself.

​
Key concepts

Runbook mode presents a guided view. Instead of the build canvas, the user sees a structured sequence of steps with clear instructions. They progress through the journey one step at a time. Manual checkpoints (planned) allow a step in the journey to require the user to explicitly mark success or failure before proceeding. This is useful when part of the process involves observation or judgment that can’t be automated. See Manual checkpoints.
Manual checkpoints are planned and not yet available.
Evidence is collected automatically. For each step, Runbook mode captures request and response details, assertion outcomes, and any notes or confirmations the user provides at manual checkpoints. The result is a structured evidence log. Runbooks support cases and environments. Before starting a runbook run, you select the case and environment, just as you would in regular run mode. The journey’s value configuration applies normally. Results are structured for reporting. At the end of a runbook run, you get a clear summary: what happened, what passed, what failed, and what evidence supports each outcome. This is designed to be shared — with a customer, a QA record, or an incident post-mortem.

​
How it works

  1. A journey author builds and validates the journey in Build mode.
  2. An operational user opens the journey in Runbook mode.
  3. They select a case and environment, then start the run.
  4. Runbook mode guides them through each step, showing what’s happening and collecting results.
  5. At manual checkpoints (when available), the user confirms what they observed.
  6. At the end, a structured evidence log and summary are available to share or export.

​
Examples

A support agent investigating a failed payment might use a runbook that:
  1. Authenticates as the customer.
  2. Fetches the customer’s payment methods.
  3. Attempts to create an order with the same payment method used in the incident.
  4. Captures the response and asserts the expected behavior.
  5. (Planned) Presents a manual checkpoint: “Did the error message match the reported issue? Mark yes/no.”
The agent doesn’t need to know the API — they follow the runbook. The evidence log they produce is automatically structured for escalation or root-cause analysis.