Run and step statuses explained
Look up every workflow run and step status, what each one means, and the exact next action to take.
A run has one status. Each step inside a run has its own. The two vocabularies overlap but are not identical: a step can be skipped, a run cannot. Use this page to look up what a status means and what to do next.
This page covers the statuses you see on the runs list and the run detail timeline. For the workflow's own published-or-not lifecycle (Draft, Published, Paused (safety)), see versioning. For why a run stopped short, see why a run paused.
Run statuses
A run status describes the whole execution. There are seven values.
| Status | Badge | What it means | Your next action |
|---|---|---|---|
pending | Gray, clock | Run accepted but no step has started yet. | Wait. If it stays pending, confirm the workflow is published and the version is active. See no data coming in. |
running | Blue, play | Steps are executing now. | Watch the step timeline. You can Pause or Cancel from the run detail page. |
waiting | Blue, clock | Parked on a delay timer or an external wait (approval, form, sub-workflow, or a pending client connection request). | Resolve the wait or let the timer fire. See why a run paused. |
paused | Yellow, pause | An operator paused the run, or run controls halted it. | Click Resume on the run detail page. |
completed | Green, check | Every step finished successfully. Terminal. | Nothing. Replay if you need to run it again. |
failed | Red, x | A step errored and the run stopped. Terminal. | Open the first failed step and read its error. See read a failed run. |
cancelled | Outline, square | An operator cancelled the run. Terminal. | Replay if you want to run it again from scratch. |
completed, failed, and cancelled are terminal: the run will not change status on its own.
The Status dropdown on the runs list offers Pending, Running, Paused, Completed, Failed, and
Cancelled (plus Any). waiting is a valid run status but is not a filter option, so you cannot
filter for parked runs directly. Open a run to confirm it is waiting.
Step statuses
A step status describes one node inside a run. It shares the seven run values and adds one more, skipped, for control-flow paths that were not taken. There are eight values.
| Status | What it means | Your next action |
|---|---|---|
pending | The step has not started; the run has not reached it yet. | None. It runs when the run reaches it. |
running | The step is executing now. | Wait. |
waiting | The step is parked on a wait. The step carries waiting metadata (such as a scheduled time or the wait type). | Resolve the wait. See why a run paused. |
completed | The step finished successfully. | None. |
failed | The step errored. The step carries a structured error you can read in its detail panel. | Read the error, decide whether it is retryable, fix the cause, then replay. |
skipped | The step was bypassed, for example a branch path that was not taken. | None. This is expected on control-flow paths the run did not follow. |
paused | The step halted as part of a run-level pause. | Resume the run. |
cancelled | The step was cancelled because the run was cancelled. | None. |
A failing step may briefly show as retrying between attempts before it lands on completed or failed. Retrying is a transient state, not a stored step status, so you will not see it as a final value in the timeline.
The success status for both runs and steps is completed. You will not see succeeded anywhere
in the run detail timeline.
Agent run states
Runs that use the agent runtime show one extra pill in the run detail header, on top of the run status. Ordinary runs do not have it, so you only see these values on agent-mode runs. There are seven.
| State | Label you see | What it means |
|---|---|---|
pending | Pending | The agent run was accepted but has not started. |
running | Running | The agent is working. |
awaiting-callback | Awaiting callback | Waiting on an asynchronous tool callback. |
awaiting-human | Awaiting approval | Paused for a human approval decision. The pill links to the approvals inbox. |
awaiting-reauth | Awaiting reauth | A connection's token could not be refreshed and needs reconnection. The pill links to your connections. |
completed | Completed | The agent run finished. |
failed | Failed | The agent run errored. |
When the pill reads Awaiting approval or Awaiting reauth, it is a link: Awaiting approval opens the approvals inbox, and Awaiting reauth opens your connections so you can reconnect the integration. Once you reconnect, an agent run in Awaiting reauth returns to Running on its own.
Why a step is waiting
A step (and the run around it) enters waiting for one of these reasons. The wait type is recorded on the step.
| Wait reason | What is happening | How it clears |
|---|---|---|
| Delay | A delay step is holding the run until a scheduled time. | The timer fires automatically. |
| Approval | A gated action is waiting on a human decision. | An approver decides in the approvals inbox at /{workspaceSlug}/monitoring/approvals. |
| Form submission | The run is waiting for a published form to be submitted. | Someone submits the form. |
| Wait for event | The run is holding for a correlated external event. | The matching event arrives, or the timeout fires. |
| Connection request | The run is waiting for a client to authorize a connection. | The client authorizes the requested app. See requesting client credentials. |
| Sub-workflow or parallel barrier | The run is waiting for a sub-workflow or parallel/loop branches to finish. | The child work completes. |
Reading a failed step's error
When a step is failed, its detail panel shows a structured error. These are the fields you read.
| Field | Type | Always present | Description |
|---|---|---|---|
code | string | Yes | Machine-readable error constant. The panel shows the literal word "Error" when the code is the generic UNKNOWN_ERROR; integration steps surface an app-specific or HTTP-derived code. |
message | string | Yes | Human-readable summary of what went wrong. |
detail | string | No | Longer detail, shown in an expandable block as Code: <code>. |
providerStatus | number | No | HTTP status from the upstream provider, rendered as "Provider status: NNN". |
retryable | boolean | No | Whether re-running the step is likely to succeed. When true, the panel appends "(retryable)" to the provider status. |
If retryable is true or the failure looks transient, replay the run. If the error points to a configuration or authentication problem, fix the workflow first, then replay. See read a failed run.
Example: an authentication failure
A Slack action fails partway through a run. The run status is failed; the Slack step shows failed and the rest of the steps show pending because the run stopped. The step detail panel renders the error like this:
Step: Send Slack message failed
The Slack connection could not be authenticated.
Provider status: 401A 401 with no "(retryable)" tag means the connection needs attention rather than a simple retry. Reconnect the integration, then replay. See reconnect an integration.
What you cannot do
- You cannot resume a terminal run. Once a run is
completed,failed, orcancelled, Resume is not available. Replay creates a new run instead. - You cannot replay an in-flight run. Replay is offered only for terminal runs. A
pendingorrunningrun must finish first. - You cannot filter the runs list by
waiting. It is a real status but is missing from the Status dropdown.