Workflow runs and errors

One accepted Source event can create one run for each active Workflow attached to that Source. Workflow Audit explains the execution step by step; Activity places Workflow runs beside related requests and Connection events.

Run statuses

• Queued — FastHook accepted the execution but work is waiting or deferred.
• Running — a worker owns the run and is executing its graph.
• Succeeded — every selected route completed or continued through handled error routes.
• Failed — an unhandled or exhausted error stopped the run.

Step statuses

A Step run can be pending, running, succeeded, failed, or skipped. Skipped commonly means a route did not match or the Step was disabled; it does not by itself mean the Workflow failed.

Read Workflow Audit

Open a Workflow and select Audit, then choose a run. Review evidence in this order:

1. Run status, timestamps, attempt count, and error summary.
2. Exact Workflow version and whether its snapshot matches the requested version.
3. Trigger payload preview.
4. Step execution order and selected routes.
5. The first failed Step's mapped input.
6. Response status, output preview, error code, and error message.
7. Downstream Steps marked skipped after the failure or route decision.

Payload previews may be unavailable because of retention, size, or storage state. A missing preview is not the same as a missing run.

The version block distinguishes an exact immutable graph snapshot from older legacy_unavailable evidence. See Workflow versioning and migrations before using an older run as a recovery reference.

Retry behavior

Temporary Action and delivery failures may be retried by the Workflow queue. The run attempt count and Step error context distinguish a retrying execution from a terminal failure. Delay steps also return a run to the queued state until the wait has elapsed.

If queue retries are exhausted, FastHook marks the run failed with a delivery-exhausted error and closes pending or running Step records instead of leaving them stuck indefinitely.

Error routes

A failed Step can continue through a connected error route. That route receives a normalized error envelope. If no error route matches after retry handling, the Workflow run fails.

Troubleshooting by symptom

No run appears

Confirm the Workflow is Active, the selected Source received the event, provider filters match, and the event occurred after activation.

A Step is skipped

Inspect the preceding Filter or Paths result, the route port, and whether the Step is disabled.

An Action fails

Check mapped required fields, provider account access, scopes, selected resource existence, response status, rate limits, and whether the operation is safe to retry.

The wrong value was sent

Compare the Step input in Audit with its saved data mapping. Verify the mapping points to the intended ancestor and uses JSON-aware insertion for structured data.

A run remains queued

Check whether a Delay is still active or a retryable provider failure is waiting for another queue attempt. Persistent queue exhaustion becomes a terminal failed run.

For transport-level webhook failures outside a Workflow, use Retries and replay and the Connection event history.