Tendrl
Docs / Strand / runs/overview
Runs
Every time a workflow executes, Strand records a run: which nodes fired, in what order, what each one received and returned, and where execution stopped. Runs are how you debug a workflow after the fact.
The Runs list. Filter to failures first when you are debugging.
Reading a run#
Open Runs and select an execution. A run shows:
- Status — whether the workflow completed, failed, or is still executing.
- Per-step detail — each node that ran, with its input and output. This is usually
- Logs — output from Print nodes and
- Timing — how long each step took, which is where you look first when a workflow
where a problem becomes obvious: a step receives a payload shaped differently than its templating expects.
Python snippets, useful for narrating what a workflow decided and why.
is slower than expected. See Performance.
A run detail: trigger source, compute breakdown, and every step with its status and duration.
Switch Step Execution to Replay to step through the run on the canvas — completed nodes fill in, the active node highlights, and the branch that actually ran is drawn in.
Replay scrubs through the run, showing which branch was taken.
Common failure shapes#
| What you see | Usually means |
|---|---|
| Fails at the first node | The trigger payload isn't the shape the workflow expects |
| Fails at a connector node | Credentials or connectivity — check the connector itself |
| Stops partway with no error | A conditional routed execution down a branch that ends |
| Times out | A slow external call, or a limit — see Limits |
For retries, fallbacks, and explicit error branches, see Error handling.
Retention#
Run history is retained per plan. See Data retention for the window that applies to your account, and export anything you need to keep longer.
Related#
- Trigger a test run
- Approval links — runs paused awaiting a human decision
- Concurrency — how simultaneous runs are scheduled
