> ## Documentation Index
> Fetch the complete documentation index at: https://docs.workflowmachine.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Runs

> Understand what a workflow run is, what run states mean, and how runs help you monitor and troubleshoot automations.

## What a run is

A run is one execution of a workflow.

Every time the workflow starts from a trigger, Workflow Machine creates a run. That run records what happened as the workflow moved through its steps.

Runs are how you answer questions like:

* did the workflow start
* which step failed
* what output did a step produce
* did the workflow complete successfully

## Why runs matter

Building a workflow is only half the job. The other half is understanding how it behaves over time.

Runs give you that visibility. They help you:

* confirm the workflow is working
* debug failures
* inspect data passed between steps
* understand how real inputs differ from test inputs

Without run history, automation becomes much harder to trust.

## Common run states

The most important run outcomes are:

* **Started**
* **Completed**
* **Failed**
* **Stopped**
* **Timeout**

In practice:

* **Completed** means the workflow reached the end successfully
* **Failed** means one of the steps or conditions caused the run to break
* **Stopped** means execution was intentionally halted
* **Timeout** means the run took too long to finish

These states help you decide whether the next action is “leave it alone,” “fix configuration,” or “redesign the workflow.”

## Runs are also a debugging tool

When something goes wrong, start with the run.

Review:

* the trigger input
* the step sequence
* the first step that failed
* the outputs produced before the failure

This is usually more useful than changing the workflow immediately, because the run shows what actually happened.

## Test runs and real runs

Both are valuable, but they serve different purposes.

* **Test runs** help you validate setup before going live
* **Real runs** show how the workflow behaves with real inputs and timing

Many workflows pass a test and still reveal edge cases later. That is normal. The important thing is that runs give you a place to inspect and improve.

## A healthy workflow habit

After publishing any important workflow, review the first few real runs.

That habit helps you catch:

* unexpected input formats
* missing fields
* auth problems
* logic branches that do not behave the way you intended

Over time, run history becomes one of the most useful parts of the product.