Skip to main content

​
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.