Read a failed run

When a run stops with a red Failed badge, one step errored and halted everything after it. Your job is to find that step and read why it stopped. This page walks the fastest path: open the run, jump to the first failed step, and read its error.

When to use this

Reach for this when a run shows status Failed on the runs list, or when a workflow stopped producing the result you expected and you want the exact reason. If a run is Paused or Waiting instead of Failed, it did not error: see why a run paused.

Find and open the run

1. Open the runs list

   Go to Monitoring > Runs in the sidebar. The runs table lives at /{workspaceSlug}/monitoring/workflow-runs. Each row shows the Run ID (first 8 characters), the workflow, its status, when it started and completed, and the duration.

2. Filter to failed runs

   Open the Status filter above the table and choose Failed. The list narrows to runs that errored. You can also type the first characters of a known run ID into the Run ID filter to jump straight to one run.

3. Open the run detail

   Click the Run ID to open the run. The breadcrumb reads "Monitoring / Workflow Runs / Workflow {id} / Run {id}". The overview shows a red Failed badge, the workflow name, and a Progress line such as 3 / 7 steps, which tells you how far the run got before it stopped.

If the run produced a run-level error before any step ran, an Execution Error banner appears at the top of the overview with the error text in monospace. Most failures are step-level, so continue to the timeline below.

Jump to the first failed step

The Execution Steps timeline lists every step in order, each row showing a status icon, the step number, the step title, the node kind (for example http.request), a status badge, and the duration. A summary line above it counts steps by status, such as "5 completed", "1 failed".

When a step failed, two things happen automatically:

• The first failed step expands on its own, so its error is already visible.
• A Jump to failed step link appears near the top of the timeline. Click it to scroll the first failed step into view.

Start at the first failed step, not the last red row. A single failure halts the run, so any later red rows are usually downstream of the real cause. The first failed step is the one that actually broke.

Read the error

The expanded failed step shows a red error panel built from the step's structured error. Read it top to bottom:

• Title is the error code, a short machine-readable label such as AUTH_MISSING or TIMEOUT. If the runtime had no specific code, the title reads just "Error".
• Message is the human-readable summary of what went wrong, shown in monospace.
• Provider status appears as "Provider status: 401" when the failure came from an outside service the step called. It is the HTTP status that service returned. When the failure is safe to retry, the line reads "Provider status: 429 (retryable)".
• Retrying in Ns means the runtime is already attempting the step again on its own. You do not need to act while this is showing.
• Technical details is a collapsible block holding the longer detail text and a Code: line. Open it when the message alone is not enough, and copy it if you need to share the failure with support.

Here is the shape of the error a failed step carries:

{
  "code": "AUTH_MISSING",
  "message": "No connection is attached to this action node.",
  "providerStatus": 401,
  "retryable": false,
  "detail": "Action node 'Create contact' resolved no active connection."
}

Decide whether it will pass on a retry

The error tells you which kind of failure you are looking at:

• Retryable or transient. A Provider status in the 429 or 5xx range, a TIMEOUT code, or a "(retryable)" suffix points to a temporary problem on the other service. Re-running the step is likely to succeed once the service recovers. See replay and re-run.
• Configuration or authorization. A 4xx provider status other than 429 (for example 401 or 403), or a code like AUTH_MISSING, points to something in your workflow or connection. Re-running it as-is will fail the same way. Fix the cause first, then re-run.

A common authorization case is a connection whose token can no longer be refreshed. The run does not retry that forever: it surfaces a reauthorization alert and the connection moves into an error state. Resolve it with reconnect an integration, then re-run.

Check the step's input and output

Below the error, each step has stacked Input, Output, and Console sections that show what the step received and produced.

• Input shows the data fed into the failed step. Use it to confirm an upstream step passed the values you expected. If the panel reads "No input data available", the step ran before any mapped data reached it.
• Output shows what the step returned. A failed step usually has none ("No output data available"), but a partial output can show how far the step got.
• Console appears only for code steps that called console.log(). If it reads "No console output. Call console.log() from your code to capture diagnostics.", the step ran but logged nothing. Console output truncates at 100 lines or 10 KB.

Inside Input and Output you can switch between Tree, JSON, and Meta views (and Table when the value is an array of objects) to read the data however is clearest.

Verify you found the cause

You have read the failure correctly when all of these are true:

• You are looking at the first failed step in the timeline, not a downstream one.
• You can state the error code and message in one sentence.
• You know whether it is retryable (transient, re-run) or a config or auth problem (fix first).

Troubleshooting

The run shows Failed but no step is red. The failure happened before any step executed. Read the Execution Error banner on the overview instead of the timeline.

Several steps are red. The first failed step halted the run; later red rows are downstream of it. Fix the first one and re-run, then re-check.

The error panel keeps changing or shows "Retrying in Ns". The run is still in flight and the runtime is auto-retrying. The detail page refreshes every 10 seconds while a run is pending or running, and stops once the run reaches a terminal status. Wait for the final status before deciding what to fix.

You cannot tell what the code means. Open Technical details under the error for the longer detail text, and read Provider status to see what the outside service returned.

Related

• Run and step statuses defines every status and its next action.
• Replay and re-run covers re-running a run after a fix, and its limits.
• Reconnect an integration resolves a "needs reauthorization" failure.