Runs & execution

What a run is

Every execution belongs to a run, identified by a run id and listed in the workflow's run history. Because every trigger type is reusable, a run usually lives for a long time: each time a trigger fires, it opens a new epoch on the same run and executes the graph again. The run's start time is when it was created; each epoch has its own start time, and the most recent one is the run's last fire.

Which run a fire lands in

Run statuses

A run is always in exactly one of 11 statuses: 5 non-terminal (active or idle) and 6 terminal (finished).

Only COMPLETED counts as a success, and only FAILED, CANCELLED, and TIMEOUT count as a failure. PARTIAL_SUCCESS and SKIPPED are terminal but count as neither.

Epochs and spawns

Two different things can make part of a run happen again, and they are tracked separately:

• Epoch: a new trigger fire. Epochs start at 0 (before the first fire) and go up by one on each fire. Each epoch's results stay browsable on their own.
• Spawn: a re-execution within an epoch, produced by re-running a step (see below). Re-running raises the spawn, never the epoch.

Node counts shown for a whole run are cumulative across every epoch and every spawn: re-running a step never lowers what already happened.

Execution modes

In Step-by-step mode, triggers are never executed for you: they still fire on their own. After a re-run in Step-by-step mode, the run goes back to PAUSED if non-trigger nodes are still ready, or to WAITING_TRIGGER if only triggers remain. For how nodes, ports, and branching behave, see Workflows.

Run controls

Five actions control a run's lifecycle. They act on runs in your current workspace: in an organization, members can act on the organization's runs.

• Stop is refused on a run that is PENDING, WAITING_TRIGGER, or AWAITING_SIGNAL. On a run that already finished it only cleans up, with no status change and no error.
• Cancel is the one action that reaches a run parked on a signal. Cancelling a run that is already cancelled does nothing.
• Reactivate works from every terminal status, including a failed or timed-out run.

A Stop or Cancel records who stopped the run and why. An agent can stop a run too: a graceful stop only closes the running epoch, while a cancel is terminal and suspends the schedules, exactly like the buttons.

Signals and pauses

A node can hold a run by yielding a signal. There are six signal types:

Resolving approvals

A USER_APPROVAL signal is resolved one at a time or in bulk. When the node has a context template, the approver sees the rendered context next to the request.

Approvals can also be answered from a linked chat channel (Slack, Microsoft Teams, Discord, Telegram, or WhatsApp). See Chat channels.

Re-running a step

You can re-run a step that completed, failed, is awaiting a signal, or is ready, optionally editing its configuration first. On the canvas, use Re-run from this step (Step-by-step) or Restart from this step (the rest runs again automatically) (Automatic). Re-running:

• Raises the epoch's spawn, not the epoch itself.
• Resets that step and everything downstream of it, then makes them ready again.
• In Automatic mode, lets the ready steps continue on their own; in Step-by-step mode, returns the run to PAUSED (or WAITING_TRIGGER if the epoch is done) for you to advance.

Re-running an older epoch

By default the most recent epoch is replayed. When an older epoch is on screen in the canvas, the re-run replays that epoch instead, and its new spawn starts above that epoch's own highest spawn. Replaying a chosen epoch is not available on a Step-by-step run, and it is refused while other epochs of the same trigger are still executing.

When a re-run is refused

• The step is still executing on an Automatic run. Wait for it to settle, or stop the run.
• The run was CANCELLED or ended TIMEOUT. Fire the workflow again instead.
• The edit changes the graph's topology (adding or removing nodes, rewiring edges). Edits at re-run time are limited to parameters, prompts, and configuration.
• The step's branch was not taken in the chosen epoch, so there is nothing to redo.

Every attempt at a step is kept, with its epoch, status, start and end time, and error, so you can compare re-runs.

The run panel

A workflow's runs are listed in a paged history, most recent first. The pinned production run is always pulled to the top. Each row shows:

• the status, as an icon and a label;
• the version it ran, with a pin marker on every run of the pinned version;
• the current epoch (calendar icon), once the run has fired at least once;
• a Step-by-step marker, and a flask marker for a Mock run (a dry run with mocked integrations);
• when it last fired, as a relative time;
• how long its last execution took, measured from the first node start to the last node end of the latest epoch, so the idle time between fires is not counted.

Hover a row to see its run id, creation time, and last fire time.

Last-cycle result

Between fires, a reusable run sits at WAITING_TRIGGER, but the history shows something more useful: the outcome of its last cycle.

Cancelling a run clears this result, so a cancelled run always shows Cancelled.

Steps, timeline, and cost

Opening a run shows its graph in run mode, each node colored by its status, with an epoch selector: view one past epoch frozen in time, or switch back to all epochs. The steps panel lists every step and switches between List view and Timeline view, which draws one bar per step sized by how long it took. Its status filter keeps All, completed, failed, running, awaiting signal, or skipped steps.

With no epoch selected, the counts for finished steps (completed, failed, skipped) are cumulative, so a re-run never makes them go backwards, while running and awaiting-signal counts stay live.

The panel also shows the Cost of this run, for the selected epoch or across every epoch. When the workflow has a spending cap, a gauge shows the spend of the current period. Once the cap is reached, the run shows Budget reached, no new run will start: the run stays in WAITING_TRIGGER and opens no new epoch until the allowance starts again (or until you raise the cap, for a cap that never resets). Test fires from the builder are not counted. See Plans & billing.

Logs

Logs lists every time a node ran, with what went in and what came out. The Simple view reads one pass at a time; the Table view puts every pass of the node in one table, filtered by epoch and status. Click an input or an output cell to open that field as a table: it lists the field for every pass loaded in the table, one row per element. Use the breadcrumb to come back.

The ID comes first and already says where a row comes from. The status, input, and output follow, then Epoch, Spawn, and Iteration one per column, to filter and sort on. They stay visible inside an opened field too: each element keeps the coordinates of the pass it came from, so a value you drilled into never loses its origin.

The ID is those coordinates written together, epoch.spawn.iteration.item, with trailing zeros left out. Each number is the value of its own column, and they all count from 0. Because it describes the row itself, the ID never changes when you filter, scroll to older rows, or when new passes arrive. Hover or tap the info icon next to the ID header for a reminder.

An ID is not unique. A node that waits and then completes writes two rows at the same coordinates, and a node reached from two different triggers can show the same ID for both. Use the status and the times to tell them apart. An element that carries its own id field (a table row, for example) shows that value instead, and an opened field that is a single value (not a list) shows the ID of its pass.

Troubleshooting

Related pages