# Observing runs

> Execution history and per-run traces for deployed Flow workflows, showing what triggered each run, the path it took, and per-node output and timing.

Once a Flow is deployed and running, the **execution history** gives you a complete view of every run — what triggered it, which path it took, what each node produced, and how long each step took.

## Execution history

The execution history lists every run of the workflow, with the following information for each:

| Field | Description |
|---|---|
| **Status** | `Succeeded`, `Failed`, or `Running`. |
| **Trigger** | What started the run (manual, scheduled, or integration event). |
| **Started at** | Timestamp of when the run began. |
| **Duration** | Total time from start to completion. |
| **Version** | Which published version of the workflow ran. |

Selecting any row opens the **execution trace** for that run.

## Execution trace

The execution trace is a step-by-step record of what happened during a specific run. For each node, it shows:

- **Input values** — what the node received.
- **Output values** — what the node produced.
- **Status** — whether the node succeeded or failed.
- **Duration** — how long the node took to execute.
- **Error details** — if the node failed, the error message, type, and stack trace.

The trace highlights the path actually taken through the workflow (for example, which branch a Decision node took), making it easy to understand the full execution without reading the workflow definition.

## Filtering and searching runs

You can filter the execution history by:

- Status (succeeded, failed, running)
- Trigger type
- Date range
- Version number

Filters help narrow down failed runs after a deployment or compare behavior between two versions.

## Failure monitoring

Failure notifications can come from workflow settings or from the workflow itself:

- The **Alerts** configuration in the workflow settings sends a notification to a specified email or Slack channel when a run reaches the `Failed` status.
- A notification step on a node's error path provides more control over the alert content.

## Common mistakes

- **Only checking failed runs** — Slow successful runs can indicate performance problems. Duration trends matter even when the run succeeds.
- **Ignoring version numbers in traces** — The version number identifies which workflow version produced the trace. A rollback does not explain what went wrong if the failed run used an older version.

## Related pages

- [Deploying a Flow](deploying-a-flow.md)
- [Debugging effectively](debugging-effectively.md)
- [Error handling](flow-error-handling.md)