Monitor and Recover Workflows

Workflow recovery starts with the execution record, not with editing or rerunning the definition. Preserve what happened, determine whether the run is queued, active, waiting, failed, or canceled, and only then choose a recovery action.

Before You Start

• Use a Starter or higher workspace.
• Use a workspace owner for write actions.
• Know whether the workflow can send messages, change invoices, apply fees, notify the team, or call another system.
• Do not create a replacement run until you have ruled out an active or automatically retrying run.

1. Find the Execution

1. Open Workflows → Executions.
2. Filter by workflow and state.
3. Choose Refresh.
4. Open the run by its workflow name or definition ID.
5. Record the full execution ID from Execution Replay.

The list shows at most 50 matching runs and has no pagination control. If the run is older, capture the workflow and approximate time for support or use an authorized integration with execution pagination.

2. Read the Evidence Before Acting

In Execution Details, review:

1. execution state and trigger,
2. start time and duration,
3. Execution Failed, when present,
4. Action Required, when present,
5. the current node on Execution Graph,
6. ordered steps in Execution Replay,
7. Trigger Data,
8. Execution Context, and
9. Execution Result.

Preserve the failed step’s node ID, error, input, and output. Redact secrets before sharing raw JSON.

3. Choose the State-Specific Response

Pending

Pending means the execution record was created but processing has not started.

1. Refresh once after allowing for queue delay.
2. Do not click Run again immediately; the editor manual action has no idempotency key.
3. If it remains pending, escalate with execution ID, workflow ID, and queued time.

The execution-start job is configured for up to three worker attempts, but attempt state is not shown on this page.

Running

1. Check whether the detail page says live updates are enabled, paused, or disabled.
2. Reload to fetch persisted steps if realtime is unavailable.
3. Confirm the current node and most recent step timestamp are changing.
4. Use Stop only from the editor that is currently tracking that run and only when cancellation is intended.

The history and detail pages do not have a general cancellation button.

Waiting

Identify the current node first.

• Wait uses a calculated time and scheduled resume.
• Pause creates a human checkpoint.
• subflow polling and a paused terminal outcome can also produce Waiting.

For Action Required, read the checkpoint message and expiry. The current web Resume Workflow action marks the pause resumed but does not prove a worker continuation was queued, and its optional JSON payload is not passed to execution by that action. Refresh and verify the execution after every pause action.

Do not deactivate a workflow that must resume. Resume jobs skip inactive definitions. Also avoid changing or deleting the current node while a run waits; continuation loads the current definition.

Failed

There is no manual Retry button in the web history or detail page.

1. Preserve the original failure.
2. Determine whether the error is configuration, data, provider, permission, or transient infrastructure.
3. Inspect newer executions before assuming recovery has not already happened.
4. If the definition needs a major change, account for any other waiting runs before deactivation.
5. Correct the smallest responsible block or connection.
6. Wait for Saved.
7. Open Deploy and clear every failed validation check.
8. Deploy the corrected workflow.
9. Start one new test run.
10. Verify the new execution and the external side effect.

The worker has automatic job retries and a dead-letter recovery path, but those attempts are not exposed as customer controls. Current configuration allows up to 25 resume attempts and up to three dead-letter retries with exponential delays beginning at one hour. Treat this as implementation behavior rather than a recovery SLA.

Canceled

Canceled executions do not resume. Determine who or what canceled the run, confirm whether any earlier side effects completed, then create one new run only if the operation is still required.

Canceling a Pause record is not the same as canceling an execution.

Completed with an unexpected outcome

A Completed state means the engine reached its successful terminal outcome. It does not independently prove that every external provider reflects the intended business result.

1. Expand each relevant step.
2. Compare input and output with trigger data and context.
3. Verify email, SMS, invoice, fee, task, or integration state in its authoritative system.
4. Correct the workflow before another trigger can reproduce the issue.

4. Prevent Duplicate Recovery Runs

The editor manual Run action sends no idempotency key. One click should correspond to one intended run.

For an integration that submits workflow trigger requests:

• supply an idempotency key between 1 and 128 characters,
• reuse the same key for retries of the same logical request,
• choose a new key for a genuinely new business action, and
• remember that key scope includes the team and workflow.

The queue returns the same job and execution for a reused key, including after the job has completed.

Human checkpoints use a separate resume key. Let the engine generate it unless your integration can guarantee a unique value per checkpoint.

5. Validate Recovery

A recovery is complete only when:

• the corrected definition says Saved,
• deployment validation has no failures,
• the intended workflow is active,
• exactly one replacement execution exists,
• its trigger data matches the intended record,
• the replay reaches the expected terminal step,
• the external side effect is confirmed, and
• the original failed or canceled execution remains preserved as evidence.

Escalation Checklist

Provide:

• workspace and workflow name,
• workflow ID,
• execution ID,
• state and trigger,
• approximate start time,
• current or failed node ID,
• exact visible error,
• whether live updates were enabled,
• whether the definition changed while the run was waiting,
• pause resume key when relevant, and
• expected versus actual result.

Do not include passwords, API keys, access tokens, or unredacted customer data.

Common Recovery Mistakes

Repeatedly clicking Run

Each editor click can create a new execution. Refresh history before starting another.

Editing the current node of a waiting run

Resume loads the current active definition. A changed or removed node can make the saved execution snapshot incompatible with the graph.

Deactivating to “pause” execution

Deactivation prevents new manual runs and causes resume attempts to skip. It is not an execution-pause control.

Treating the pause badge as execution state

Pause and execution records are separate. A Resumed or Canceled pause does not prove the execution moved.

Assuming a background retry will fix business data

Retries can repeat technical work; they cannot decide whether a message, fee, or invoice change is still appropriate. Verify provider state before another run.

Related Docs

• Workflows
• Workflow Executions
• Workflow Pauses
• Build Your First Workflow
• Weekly Finance Ritual