Skip to main content
Coverage answers the question: does this journey actually prove the behavior it’s supposed to? The Coverage panel in Build mode shows which acceptance criteria are mapped to the journey, which steps satisfy them, and where gaps exist — criteria that aren’t yet covered by any assertion or step.

​
When to use it

Check coverage when you want confidence that a journey is doing the verification work you think it is. It’s especially useful when:
  • Handing a journey to someone else who needs to understand its scope.
  • Tying API testing to a requirement, ticket, or user story.
  • Auditing a journey before a release to confirm no acceptance criteria were missed.
  • Building evidence for a compliance or QA review.

​
Key concepts

Coverage is journey-level, not step-level. It’s a view of the whole journey’s purpose — what it’s trying to prove — not a breakdown of individual step health. Step-level pass/fail lives in run results; coverage lives in the journey definition. Acceptance criteria are the unit of coverage. An acceptance criterion is a statement of intended behavior: “A user with an expired card receives a 402.” You map criteria to the journey and then to the steps and assertions that verify them. Connecting external tickets and work items. Coverage can link to external work items — Jira issues, Linear tickets, GitHub issues — so you can trace from a requirement to the journey that validates it. See Jira and Linear. Gaps surface automatically. If a criterion is mapped to the journey but no step or assertion verifies it, Coverage flags it as a gap. If a criterion is entirely absent, it never shows up — which is why it’s worth being deliberate about mapping criteria when you build. Coverage feeds into reporting. When a journey runs, the results map back to its coverage criteria, so you can report not just pass/fail but which requirements were exercised.

​
How it works

  1. In Build mode, open the Coverage panel.
  2. Add acceptance criteria by describing the behavior the journey should prove.
  3. Map each criterion to the steps and assertions that verify it.
  4. Optionally link criteria to external tickets (Jira, Linear, etc.).
  5. Coverage shows a summary: which criteria are fully covered, partially covered, or missing.

​
Examples

A checkout journey might have these criteria mapped:
CriterionStepAssertionStatus
Successful order returns 201POST /ordersstatus == 201Covered
Order ID is present in responsePOST /ordersbody.order_id existsCovered
Expired card returns 402——Gap
The third criterion is declared but not yet verified — no step or assertion handles the expired card scenario. Coverage makes this gap visible before it becomes a surprise in production.