# Monitor workflow runs

Every real execution has its own run identity, mode, timing, and status. Use the workflow detail page to understand what is happening now and distinguish it from earlier executions.

## Start and observe

1. Confirm the saved definition and chosen run mode.
2. Start the run from the workflow's available action.
3. Open the detail page and select the relevant run.
4. Watch the pipeline strip for job progress.
5. Open a job's details when progress or counts are unexpected.
6. Inspect the final status and outputs.

A run request can be accepted before processing begins. Queued work can wait for execution capacity, a dependency, or a resource budget. Do not repeatedly click Run merely because outputs are not immediate.

## Interpret statuses

Pending or queued indicates work has not completed admission or execution. Running indicates active processing. Succeeded means the configured execution completed. Failed indicates an error. Cancelled indicates the run was stopped. A job can also be Skipped when its condition was not met.

A skipped job is not necessarily an error, and it does not automatically mean its descendants were skipped. Check downstream input counts.

Live updates and persisted job rows can arrive a moment apart. A final run status and a briefly lagging job card should be inspected again before assuming the run is stuck. Reopening the run lets you compare durable state with the live display.

## Compare runs

Use the run selector to move between executions and inspect differences in mode, status, timing, and output. Select an explicit run when investigating a report so newer activity does not change the scope under you.

A successful execution can have zero useful output because filters removed all records or a validated assumption did not match live data. Trace counts from source to destination to locate the first change.

For errors, record the workflow, run, and job identities along with the visible message. See [outputs](/docs/workflows/outputs), [reliability](/docs/workflows/reliability), and [troubleshooting](/docs/workflows/troubleshooting).
