Observability & audit

Every meaningful thing a run does is recorded in an append-only event log — step started / completed / failed / retrying, signals and forms received, webhooks fired, errors. That log powers both a human-readable timeline and an exact audit trail.

From the command line

flowctl run status <exec> -o json     # current status + variables + outcome + result
flowctl run narrative <exec>          # human-readable timeline (step narratives + outcomes)
flowctl run events <exec>             # the raw event log — the audit trail
flowctl run watch <exec>              # follow a run live until it reaches a terminal state
flowctl run list --status FAILED --since 2026-06-01   # find runs to investigate

• run narrative is the “what happened, in English” view — built from per-step narratives and outcome templates.
• run events is the “exactly what occurred, with timestamps” view — use it for debugging and audit.

From the web console

The web console run-detail view shows the same information visually: a timeline, the run’s variables, the full events list, and tabs for forms, signals, webhooks, queries, and connector jobs — plus the workflow graph with the run’s current position highlighted.

Making runs answerable

To answer “what did this run produce?” without scraping variables, give the workflow an outcomeTemplates line (human) and a result reducer (typed). Then run status and run list carry both outcome and result on every run.