Skip to main content
Not every step can be verified automatically. Manual checkpoints are places in a journey where a human needs to look at what happened and decide — did this work? They pause the runbook and ask the user to confirm their observation, check off evidence, or mark the step as passed or failed before moving on.
Manual checkpoints are a planned step type. The concept is supported in Runbook mode; authoring manual checkpoint steps in Build mode is coming soon.

​
When to use it

Add a manual checkpoint when:
  • An assertion can’t capture the full story — for example, a UI change that must be visually confirmed, or a downstream effect that isn’t reflected in the immediate response.
  • The process requires a human judgment call (e.g., “does this response look correct for this customer’s account?”).
  • Compliance or audit requirements mean a human must sign off at a specific point.
  • The runbook is gathering evidence and the checkpoint is a natural place to note an observation.

​
Key concepts

Checkpoint prompt. When the runbook reaches a manual checkpoint, it pauses and displays a prompt — a description of what to check, written by the journey author. The user reads the prompt, performs the check, and responds. Pass / fail marking. The user explicitly marks the checkpoint as passed or failed. This mark becomes part of the evidence log for the run and feeds into the run’s overall result. Evidence notes. At a checkpoint, the user can add a note — a brief description of what they observed. Notes are captured alongside the automatic response and assertion data. Blocking behavior. A manual checkpoint blocks the runbook from continuing until the user responds. This is intentional: the checkpoint exists because a human decision is required at that point.

​
How it works

When the runbook reaches a manual checkpoint step:
  1. The step pauses. The checkpoint prompt is displayed — for example, “Verify that the customer’s account shows a pending transaction in the admin panel.”
  2. You perform the check.
  3. You mark the checkpoint Passed or Failed.
  4. Optionally, you add a note describing what you saw.
  5. The runbook continues to the next step.
If you mark the checkpoint as failed, the runbook records the failure and continues — or, depending on how the journey is configured, may stop. Either way, the failure is captured in the evidence log and surfaced in the final report.

​
Examples

Verifying a downstream side effect A journey tests a payment submission. The HTTP response looks correct, but the team also wants to confirm the transaction appears in the internal ledger. A manual checkpoint after the payment step says:
“Check the internal ledger for a pending debit matching the amount in this run. Mark passed if it appears within 30 seconds.”
The support agent checks the ledger, finds the entry, marks the checkpoint passed, and adds a note: “Pending debit of $47.00 appeared at 14:03 UTC.” Flagging an unexpected result The same journey is run against a different case where the payment is expected to be rejected. The manual checkpoint asks:
“Confirm the customer account shows no new transaction.”
The agent checks, finds an unexpected charge, marks the checkpoint failed, and notes what they found. The failure is flagged in the run report.