# Watch runs in Monitor

> Find a run in the history, filter to what you care about, follow one live, and read what each step did.

**Workflows → Monitor** is the run history: every run of every workflow, as it
happens.

## Outcome

You can find any run, tell what state it is in, and see which of its steps did
what.

## 1. Find the run

The table shows **Time**, **Workflow**, **Status**, **Duration**, and
**Source**. Filter it by workflow version and by time range.

From inside the builder, the **Monitor** button in the toolbar opens this page
already filtered to the workflow you are editing.

**Checkpoint:** your workflow's runs are the only ones in the table.

## 2. Read the status

| Status | Means |
|---|---|
| `pending` | Accepted, not started yet. |
| `running` | In progress. |
| `completed` | Every step that had to run finished. |
| `failed` | A step failed and nothing recovered it. |
| `suspended` | Normal. The run is waiting out a delay or waiting for a subflow. |

`suspended` is not a problem state. A run in it has released its slot and will
resume on its own.

## 3. Follow it live

Turn on **Live Tail** and new runs stream in without a refresh.

For a single workflow there is a second view. In the builder, the **Live run**
toggle in the toolbar subscribes the canvas to the latest run: step cards light
up as they execute, and the summary beside the toggle counts completed steps
out of the total. Selecting a step while it is on also shows a small metrics
strip — **Success 24h** and **p50 latency** for that step.

**Live run** is only available on a workflow that is saved, active, and has no
pending changes. Hover the toggle when it is greyed out and the tooltip says
which of those is missing:

- *Save the workflow first*
- *Save your changes to watch live runs*
- *Activate the workflow to watch live runs*

## 4. Open a run

Click the row. The **Steps** panel lists each step with:

| Column | Shows |
|---|---|
| **Step** | Its name. Steps from a subflow are indented under their parent. |
| **Type** | The step type identifier, such as `http_request`. |
| **Status** | `pending`, `running`, `completed`, `failed`, or `skipped`. |
| **Duration** | How long it took. |
| **Error** | The failure message, where there is one. |

The panel does not show the payload each step was holding. To inspect values,
use **Test Request** in the builder, or persist them with a **Map to Data
Model** step so they land in the warehouse where you can browse them.

A failed run also gets a **Run again from the failure** panel — see [Recover a
failed run](/help/run-troubleshoot/recover-a-failed-run).

**Checkpoint:** you can name the first step that did not complete.

## The Analytics tab

The **Analytics** tab on the same page totals **Total Runs**, **Completed**,
**Failed**, and **Avg Duration** for whatever the filters are set to, with
breakdowns by workflow and by status. It is the view for "is this getting
worse?" rather than "what happened to this one?"

## Common problems

**No runs at all.** The workflow is probably inactive — saving is not
activating. Check the **Workflows** list for its state.

**Runs stop appearing after a while.** Run history is retained for a period set
by your plan, and older runs are pruned. Check the time filter first, then
**Settings → Organization** for your retention window.

**A run sits at `running` for a long time.** Open it: the step in progress is
the one to look at. A step calling a slow endpoint holds the run for as long as
that call takes, plus any retries.

**A run says `suspended` and nothing is happening.** That is a delay or a
subflow in progress. It resumes on its own — check the parent run's steps for
which one is waiting.

**I cannot tell which version ran.** Filter by workflow version. Every run is
pinned to the version that was active when it started, so an old run keeps
showing the old behaviour.

## Next step

[Recover a failed run](/help/run-troubleshoot/recover-a-failed-run).
