A run is a single pass through a workflow, from the moment something sets it off to the moment the last step finishes. If a workflow is the recipe, a run is one time you actually cook it. Understanding runs helps you see what your workflow did, when, and whether it worked.
A run is one execution of a workflow
Every time a workflow does its job, that's a run. A run captures the whole journey: which steps ran, in what order, how long each took, and what happened along the way. Each run is independent, so a workflow that fires a hundred times a day produces a hundred runs, each with its own record.
A run is always tied to a specific version of the workflow, the one that was live when the run began. That means a run reflects the workflow exactly as it existed at that moment, even if you edit the workflow afterward. Looking back at an old run shows you what really happened, not what the workflow looks like today.
Learn how to look at older runs here.
What starts a run
Runs don't happen on their own; something triggers them. The common starts are:
A schedule. A step set to run on a schedule kicks off a run at the times you choose, as long as the workflow is live and not paused.
An incoming request. A workflow that serves a webpage or an API endpoint starts a run when someone hits it.
A manual test. While building, you can run a workflow yourself to see how it behaves.
Whatever the source, the trigger is the entry point, and everything the workflow does from there belongs to that one run.
A run is made of step executions
Inside a run, each step does its work as a separate execution, running in its own isolated container. When a step finishes and produces output, Tines 3B follows the connections in the workflow and starts the next steps, adding their executions to the same run. So a run unfolds step by step, flowing through the workflow's shape until there's nothing left to do.
Because each step is its own execution, a run is really a collection of executions stitched together by the workflow's structure. If a step produces no output, the steps after it are skipped, which is how a workflow naturally stops a branch that has nothing to pass along.
A run has a status
At any moment, a run has a status that reflects its executions taken together:
Running. At least one step is still working or waiting its turn.
Success. Every step finished without error.
Error. At least one step failed.
The status updates as the run progresses, so a run starts as running and settles into success or error once all its steps are done.
Seeing your runs
The workflow editor has a Runs view that lays out a workflow's runs as a waterfall: each run's steps on a timeline, showing how long each one waited to start and how long it took to finish, along with the run's total duration and step count. Selecting a run lets you dig into what happened in it. When a workflow hasn't run yet, this view sits idle, waiting for its first real run.
Test runs versus real runs
Not every execution is a run worth keeping. The quick, throwaway runs you do while building, testing a single step or trying an idea, are treated as temporary. They don't show up in the runs list and don't cascade to downstream steps. This keeps your run history focused on the real work your workflow does once it's live, rather than the experiments you ran while creating it.