Executions

Accessible via: Main Menu -> Workflow Builder -> [Workflow Name] -> Executions

Every time a workflow runs — manually, on a schedule, from a webhook, or from an agent — the platform records an execution: what triggered it, which nodes ran, what each one produced, and how it ended. The Executions tab is where you go to answer “did it run?”, “what did it do?”, and “why did it fail?”.

Finding a run

1. Open Workflow Builder in the left rail.
2. Pick the workflow in the column.
3. Switch from the Build tab to the Executions tab.

You land on the list of runs for that workflow, newest first, showing each run’s name (its execution id), status, when it started, and how long it took. Before the workflow has ever run, the tab shows “No executions yet — once this workflow runs, executions will appear here.”

The URL is stable and shareable:

/workflows/<workflowId>/executions              # the list
/workflows/<workflowId>/executions/<executionId> # one run

Reading the status

Each run carries one status:

Individual nodes have their own finer-grained state — queued, running, waiting, done, failed. waiting is the node-level counterpart of SUSPENDED: the step is holding for an approval or an external callback rather than doing work.

Inspecting one run

Open a run from the list. The detail view shows the same graph you built, with the run overlaid on it:

• The canvas replays the path the run actually took, so you can see which branch it followed and where it stopped. Each step carries its own state badge, and a failed step is highlighted.
• The timeline (the scrubber under the canvas) lets you step through the run in order.
• Trigger input (top left) shows the payload the workflow started from, field by field. View raw payload gives you the unparsed input if you need the exact bytes.
• Result (bottom right) shows what the run finally produced.
• The inspector — click any step — shows that step’s started time, duration, retries, node id, input, output, and, when it failed, the error. Opening a failed run selects the failed step for you.
• Re-run starts a fresh execution from the same input, so you can retry after a fix without reconstructing the payload.
• Open in builder jumps back to the Build tab for the same workflow.

A step that finished without recording an end time shows no duration rather than a made-up one — if a duration is missing, that’s why.

A RUNNING execution streams updates into this view as nodes complete. Long runs page their events in — older events load as you scroll back through the timeline.

Debugging a failed run

1. Open the failed run. The failed step is highlighted on the canvas and its inspector opens automatically.
2. Read the error in the inspector, along with the input that step received. The error is the raw payload from whatever failed, so for a tool step expect the tool’s own message and stack trace rather than a rewritten summary.
3. Check the input against what the node expected — most failures are a reference that resolved to nothing (see Dynamic data flow) rather than the node itself breaking.
4. Fix it on the Build tab, Save, Publish, then Re-run the original execution to confirm.

If a run sits in SUSPENDED longer than you expect, it is waiting on a human or an external system, not stuck: check for a pending approval, or whether the callback the workflow is waiting for was ever sent.

Where else runs show up

• Workflow output published to a channel appears in Feed — that’s the surface for reading results, where Executions is the surface for diagnosing them.
• Runs started by an agent inside a conversation are linked from that conversation.
• The API exposes the same records programmatically — see the API reference.