Workflow Executions
Monitor workflow runs, understand execution and step states, inspect replay data, and recover safely from failures.
Workflow Executions is the operational history for automated and manual runs. Use it to distinguish queued work from active work, understand a wait, identify a failed block, and preserve evidence before making a recovery change.
Prerequisites
- Use a Starter or higher workspace.
- Open the feature as a workspace owner through the supported web navigation.
- Create and deploy at least one workflow before expecting a run.
- Use read access only when you do not need to stop a run or act on a checkpoint.
Open Execution History
Choose Workflows in the primary sidebar, then choose the Executions secondary tab. You can also choose View Executions from the Workflows page or View All in a workflow’s Recent Executions section.
The list loads the newest 50 matching executions. It has no next-page control in the current web view.
Use:
- All Workflows to filter by one of the first 100 loaded definitions,
- All States to filter by execution state,
- Clear Filters to reset both filters, and
- Refresh to request the list again.
The table shows Workflow, State, Trigger, Started, Duration, and Error. Select the workflow value in a row to open Execution Details.
Execution States
| State | Meaning in the current engine | What to do |
|---|---|---|
| Pending | The execution record exists and is queued but has not started. | Refresh before treating it as stuck. |
| Running | The worker is processing the execution. | Open the run for live or persisted step progress. |
| Waiting | The engine stopped at a scheduled wait, subflow poll, terminal pause, or human checkpoint. | Inspect the current node and Action Required section. |
| Completed | The engine reached a successful terminal outcome. | Verify result and side effects when the run matters financially. |
| Failed | The execution recorded an error. | Preserve the error and failed step, then follow the recovery guide. |
| Canceled | A cancellation was recorded. | Start a new run if the work still needs to happen; canceled runs do not resume. |
The list calculates duration only when both start and completion timestamps exist. Otherwise it displays In progress, including for some non-running records without a completion timestamp.
Read Execution Details
Header and metadata
The page shows Status, Trigger, Started, and Duration, plus View Workflow. A failed run with an execution-level error also shows Execution Failed.
Record the full execution ID from Execution Replay before troubleshooting; the breadcrumb only shows its first eight characters. The full ID is the best identifier for support and audit follow-up.
Action Required
When the run has a pending human checkpoint, Action Required shows its message, node, expiry, and Resume or Cancel actions. Choose View All Pauses to open the checkpoint dashboard.
Read Workflow Pauses before relying on either action. The current web pause action updates checkpoint state but does not itself prove that the worker continuation was queued.
Execution Graph and Execution Replay
When the stored definition parses successfully, Execution Graph renders a read-only copy of the workflow with execution overlays. Execution Replay orders persisted steps chronologically and shows:
- execution and step status,
- the current node,
- visited paths,
- timestamps and durations,
- skipped steps,
- step errors, and
- input or output where present.
Step states are Pending, Running, Completed, Failed, and Skipped. They are separate from the execution-level state.
Live and persisted data
The detail page combines persisted execution steps with realtime worker events when realtime credentials are configured. The page explicitly reports Live updates enabled, Live updates paused, or Live updates disabled.
Hosted customers should not attempt to create or expose a worker API key in the browser. If live updates are disabled in a hosted workspace, use Refresh and contact support. Self-hosted operators must configure the worker URL and public worker credential deliberately and understand that a NEXT_PUBLIC_ value is delivered to the browser.
Even without live updates, the page can replay persisted steps returned by the execution query.
Trigger Data, Execution Context, and Result
These sections render raw formatted JSON when the corresponding object is present.
- Trigger Data explains what started the run.
- Execution Context shows the accumulated runtime context.
- Execution Result shows the recorded final result.
These objects can contain customer, invoice, or integration data. Share only the minimum necessary excerpt during troubleshooting and remove credentials or secrets.
Retry and Idempotency Behavior
The editor’s manual Run action does not send an idempotency key. Treat each click as a potential new execution.
A workflow trigger integration request accepts an optional idempotency key of 1 to 128 characters. The key is scoped to team and workflow. Reusing the same key returns the same queued or completed job and execution instead of creating a duplicate; integration tests cover both active and completed jobs.
Current worker configuration includes:
- up to 3 attempts for an execution-start job,
- up to 25 attempts for a resume job, and
- a dead-letter recovery path with up to 3 additional retries and exponential delays beginning at one hour.
Those values are implementation configuration, not a customer-facing completion SLA. Attempt and dead-letter state are not exposed as controls in the web execution page. A visible Failed state should be investigated even if a background retry may still occur.
Cancellation
The editor turns Run into Stop for the run it is currently tracking. Stop submits an execution cancellation.
The execution history and detail pages do not expose a general Cancel execution or Retry button. Cancel Pause changes a checkpoint record; it is not the same operation as canceling the execution.
Verify a Run
- Open Workflows → Executions and choose Refresh.
- Find the run by workflow, trigger, and start time.
- Open Execution Details.
- Confirm the execution-level state.
- Compare the current node with Execution Replay.
- Expand the failed or unexpected step and inspect its input, output, and error.
- Confirm trigger data matches the record you intended to process.
- Verify the external side effect in its authoritative system; a completed step does not replace provider-side confirmation.
Troubleshooting
A run remains Pending
Choose Refresh and allow for queue delay. If it does not start, capture the execution ID, workflow ID, queued time, and current state for support.
A run remains Running but the graph does not move
Check the live-update message. If realtime is disabled or paused, reload the page to fetch persisted steps. If both the state and persisted steps remain unchanged, escalate with the execution ID.
A run is Waiting
Inspect its current node. A Wait block should have a time-based resume; a Pause block should create Action Required. Do not resume a checkpoint merely to clear the queue—read its message and expiry first.
A run failed
There is no manual retry control on this page. Preserve the failure, review the definition, deactivate before a major edit when appropriate, correct and deploy the workflow, then create a new manual run. The original execution remains the audit record.
Workflow names are missing
The page could not load definitions and displays definition IDs instead. The executions themselves may still be available. Refresh, then check workspace plan and read permissions.
A completed run has no visible result
Result is optional. Use the step replay and verify the action in its owning product or provider.