Workflow runs
Run history shows what happened to an individual customer journey. Each trigger creates a run that follows the published workflow, recording the steps it reaches and where it completes or fails. Use that evidence to investigate an unexpected outcome.
The Runs tab is where you go when an automation did not do what you expected.
Open the Runs tab
Open the workflow and choose Runs, next to Composer at the top. The tab only appears once the workflow has been published at least once, since there is nothing to run before that.
A panel beside the canvas lists the most recent runs, newest first, each showing when it started and how it ended:
| What you see | What it means |
|---|---|
| In progress | The run has not completed. It may be executing, on a Delay, paused with its workflow, or waiting for credits or capacity. |
| Finished! | It reached the end with nothing failing. |
| Failed. | A step failed and the run stopped there. |
There is no per-run cancel, skip or rewind control. If further execution would be harmful, pause the workflow: that parks existing runs as well as preventing new ones. Completed effects remain, and an external request already in flight can still complete. See pause behavior.
Select a run and the canvas redraws it: the steps it went through are outlined in green, the step it is sitting on right now in the accent colour, and a failed step in red. The connection points along the path it took are highlighted, so a branching workflow shows you at a glance which way this particular run went.
The Workflow run details panel in the corner gives you when the version was published, when the run was triggered, how many steps it went through, and either its status or when it finished.
See what a step did
Click any step on the canvas and its history opens underneath it:
- Entered at and Left at, and how long it Took.
- Received and Produced: the values the step was handed, and the values it added, each listed by name with a short summary.
- For a Send Email step, the Email status and a View email details button, which opens the message itself along with its Activity: sent, delivered, opened, clicked, bounced, unsubscribed.
- The failure reason, in red, if the run stopped there.
Compare Received and Produced to the decision you expected. An empty lookup may be a valid result; a controller may pass existing values on without adding a new one. Trace the recipient and the relevant purchase, event or object back through the path before treating a missing output as a failure.
When a run fails
A terminal step failure ends that run. There is no general replay-from-this-step control. Temporary waits and safe infrastructure retries are different from terminal failures: check the recorded reason before deciding that a customer was skipped.
The failed step is outlined in red and shows the failure message right on the canvas, without needing to select it. Common ones:
| Message | What to do |
|---|---|
| The recipient email address is suppressed. | The address bounced, complained or unsubscribed. Nothing to fix in the workflow. |
| Insufficient credits while execution is waiting | Restore available credits. Waiting execution can continue; do not re-trigger it and create a second journey. A run already marked Failed needs investigation. |
| An HTTP Request failure | Check URL, headers, payload, response shape and the receiving system. A timeout or response-validation failure may happen after the external system acted. Reconcile before triggering another call. |
| No available emails, an unverified sender domain or disabled sending | Correct the sending prerequisite. Email allowance exhaustion is distinct from a credit wait. |
| Email acceptance outcome is unknown | The provider may have accepted it. Inspect email activity before arranging another delivery. |
If the failure is in the workflow, fix the draft and publish. New triggers use that corrected version; existing runs keep their original one. Publishing also unpauses the workflow, so check older waiting runs before releasing them.
Waits and safe recovery
Long delays persist their wake-up time and survive restarts. Credit shortage and concurrency limits park work for another attempt rather than failing the run. Temporary service-capacity or explicitly retryable delivery responses can also wait.
The runtime records completed step effects and charges so a safe recovery can reuse them. That does not guarantee every external action is safe to repeat. An HTTP call or email whose acceptance is uncertain is held as a failure for investigation rather than blindly sent twice. Automatic infrastructure retries are bounded; exhausting them is a failure you should inspect.
Why one trigger produced several runs
Two things split a run into many:
- A Find Records, Create or Update Records or Delete Records step with Process each record separately checked. Each record carries on as its own independent run, with its own history.
- A For Each step, which always splits, one run per item in the list.
Each split is a real child run with its own subsequent step execution and cost. Child runs retain their parent relationship, which helps distinguish intentional fan-out from duplicate triggering. Count executed steps across the children when estimating usage, not only the number of boxes on the canvas.
Which version a run is on
Publishing takes a frozen copy of the workflow. A run stays on the copy it started with and finishes on it, even if you publish three more times in the meantime. Only new triggers pick up the latest version.
That is why the canvas you see in the Runs tab can differ from the one in the Composer. It is showing the workflow as it was when that run began. See Manage workflows.
Measure across all the runs
The Metrics tab answers the volume questions rather than the single-run ones. It shows the success rate, total runs, and how many completed, failed and are still waiting, all for one published version, which you pick from the Versions list in the same side panel.
Where the river leaks ranks the steps losing the most runs. Click one and the canvas jumps to it. That is the shortest route from "this automation underperforms" to the step responsible.
Read runs from your own code
The API lists runs and retrieves a run's status, step count and paginated history, including parent information for child runs. It does not return the live values the run carries. See the workflows API reference.
Related
- Workflows: steps, triggers, and how a run flows.
- Manage workflows: publishing, pausing, versions.
- Workflow billing: what each run costs, and the cap on runs at once.