Workflow Executions

Watch workflow runs, understand execution and step states, examine replay data, and recover safely from failures.

Workflow Executions is the operational history for automated and manual runs. Use it to separate queued work from active work. Use it to understand a wait and to find a failed block. Preserve the evidence before you make 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 you expect 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 executions that match. 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	Description in the current engine	What to do
Pending	The execution record exists in the queue. It did not start yet.	Refresh before you treat it as stuck.
Running	The worker processes 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.	Examine the current node and the Action Required section.
Completed	The engine reached a successful terminal outcome.	Confirm the result and the 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	The engine recorded a cancellation.	Start a new run if the work still needs to happen. A canceled run does not resume.

The list calculates duration only when both start and completion timestamps exist. If not, it shows In progress. This also applies to some records that are not in the Running state and have no 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 you troubleshoot. The breadcrumb shows only 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 you use either action. The current web pause action updates the checkpoint state. It does not prove that Eigenn queued the worker continuation.

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 you set realtime credentials. The page explicitly reports Live updates enabled, Live updates paused, or Live updates disabled.

A hosted customer must not create or show a worker API key in the browser. If a hosted workspace has live updates in the disabled state, use Refresh. Then contact support. A self-hosted operator must set the worker URL and the public worker credential deliberately. That operator must also know that the browser gets a NEXT_PUBLIC_ value.

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 related 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 when you troubleshoot. Remove credentials and 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. Eigenn scopes the key to the team and the workflow. If you use the same key again, Eigenn returns the same queued or completed job and execution. Eigenn does not create a duplicate. Integration tests cover both active and completed jobs.

Current worker configuration includes:

up to 3 tries for an execution-start job,
up to 25 tries for a resume job, and
a dead-letter recovery path with up to 3 more retries and exponential delays that start at one hour.

Those values are implementation settings, not a completion SLA for the customer. The web execution page does not show the try count and the dead-letter state as controls. Examine a visible Failed state, even when a background retry can still happen.

Cancellation

The editor turns Run into Stop for the run that it now tracks. Stop submits an execution cancellation.

The execution history and detail pages do not show a general Cancel execution or Retry button. Cancel Pause changes a checkpoint record. It is not the same operation as a cancellation of the execution.

Confirm a Run

Open Workflows → Executions.
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.
Examine its input, output, and error.
Confirm that the trigger data matches the record that you intended to process.
Confirm the external side effect in its authoritative system. A completed step does not replace provider-side confirmation.

Troubleshoot

A run remains Pending

Choose Refresh. Wait for a possible queue delay. If the run 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 has the disabled or paused state, reload the page to fetch persisted steps. If the state and the persisted steps do not change, escalate with the execution ID.

A run stays in the Waiting state

Examine its current node. A Wait block has a time-based resume. A Pause block creates Action Required. Do not resume a checkpoint only 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. Examine the definition. Deactivate the workflow before a major edit when this is applicable. Correct the workflow. Deploy the workflow.

Then create a new manual run. The original execution remains the audit record.

The page does not show workflow names

The page cannot load the definitions and shows definition IDs instead. The executions can still be available. Refresh the page. Then check the workspace plan and the read permissions.

A completed run has no visible result

The result is optional. Use the step replay. Then confirm the action in the product or provider that owns it.