# Debug a Run

> Trace a failed or unexpected run from the Execution Log through Step-level Executions and upstream data.

Debug one run by finding the first result that differs from what you expected. The final red Step may only be where an earlier data or connection problem became visible.

## Follow the run from the first wrong result

### Open the run

Find the event or time in the [Execution Log](/build/the-canvas/execution-log). If no run exists, troubleshoot the trigger instead with [Workflow Did Not Start or Is Still Waiting](/reference/workflow-did-not-start-or-is-still-waiting).

### Find the first unexpected Step

Follow the route through the canvas. Stop at the first Step that failed, was skipped unexpectedly, or produced the wrong value.

### Read its Executions entry

Open the Step's App drawer, go to [Executions](/build/core-concepts/executions), and read the full message, input, and output for that run. Copy an exact validation message into [Step Error Messages](/reference/step-error-messages).

### Trace the input upstream

If the input is wrong, open the upstream Step's Executions entry. Continue backward until you find where the value or shape first changed.

### Reproduce the smallest safe part

Use [Test & Debug](/build/the-canvas/testing-and-debugging) on the affected Step with controlled data. Check the connected app before repeating a create, update, send, or charge action.

## The workflow ran twice

First decide whether you are looking at two runs or two attempts:

- **Two execution ids:** the trigger started two runs. A webhook creates one run for every request it receives, including duplicate deliveries from the sender. Scheduled workflows can overlap when a run lasts longer than the schedule interval.
- **One execution with an Attempt 2 or Attempt 2 of 4 marker:** this is **Retry on fail** repeating one Step. Single attempts and some historical entries may not show an attempt marker.
- **One execution with several unmarked entries on a looping Step:** these may be separate items or loop passes, not retries.

Compare the trigger payloads and timestamps. For webhooks, use the sender's stable event id to recognise an event already processed. For destination writes, prefer an idempotency key or an update keyed by a stable record id where the app supports it.

## Route the finding

- A missing or still-waiting run belongs in [Workflow Did Not Start or Is Still Waiting](/reference/workflow-did-not-start-or-is-still-waiting).
- A wrong value, missing field, or list/item mismatch belongs in [Data and Mapping Problems](/reference/data-and-mapping-problems).
- A provider error, timeout, or uncertain write belongs in [Connections and External APIs](/reference/connections-and-external-apis).
- A named Step validation message belongs in [Step Error Messages](/reference/step-error-messages).

## When the documentation does not have the answer

Take it to the [Glow Forum](https://forum.getglow.ai/). Post the workflow name, the Step that failed, and the error text as it appears in Executions. The exact error text gives others enough information to identify the next check.

## What's Next?

- Learn the run-level view in the [Execution Log](/build/the-canvas/execution-log).
- Inspect individual Step attempts in [Step-Level Executions](/build/core-concepts/executions).
- Build a recovery path with [Error Handling & Retries](/build/core-concepts/error-handling).