Run states and limits
Each state’s word in the dashboard and in the API, and the limits a run works within.
States
Each run has a status in the API. A list of runs also gives each its state, in the dashboard’s words. For what each state means, see Runs.
| Dashboard | state (List runs) | status |
|---|---|---|
| Queued | queued | waiting |
| Running | running | pending, running, or paused in a Delay |
| Held | held | paused with waitingOn: person |
| Worked | worked | completed |
| Failed | failed | failed |
| Cancelled | cancelled | cancelled |
completed, failed and cancelled are final: stop polling there. A rejected approval is still Worked; its decision says rejected.
What is the difference between pending and running?
pending: a worker has the run or is about to take it. claimedAt says when one took it. running: a run carrying on after a wait.
How do I see why a run is Queued?
A waiting run has waitingFor: workflow or organization, the limit that holds it, with waitingLimit. linePosition is its place, 1 being next. With no waitingFor, it is waiting for a free worker, usually for a moment.
Test and production
| What | Test | Production |
|---|---|---|
| Started by | Test in the editor, or Listen for the next real event while the workflow isn’t Live | The trigger of a Live workflow, Run, or the API |
| Runs | The draft | The published version |
| Pinned step data | Used | Ignored: every step runs |
| In Runs | Only with Include test runs | Always |
environment | test | production |
Times
startedAt- When the run was accepted.
firstStartedAt- When a worker first started it. The gap from
startedAtis the time it waited in line. durationMs- From
firstStartedAtto the end, rounded to the millisecond. Waits inside the run, such as a Delay, count. finishedAt- When its result was decided. Both are there as soon as the run ends.
On a run’s page, hover over or focus the time in the top bar to see where it went, such as Took 697 ms · steps 456 ms · start-up 241 ms · waited in line 2.1 s (not counted). A time under half a millisecond shows <1 ms.
A run started on v2026.10.5 or earlier, or one that ran inline, such as a Sub-flow’s, counts from startedAt.
Limits
- A step’s Timeout
- 30 seconds, unless you set another or the app needs longer, up to 600. Each retry gets it again.
- Retry on failure
- Up to 5 retries.
- The workflow’s Execution timeout
- 5 minutes when 0, up to 1 hour. Delays and approvals don’t count.
- A Code step
- 30 seconds and 256 MB of memory.
- An expression
- 100 ms.
- What one step passes on
- 16 MB.
- A webhook’s body
- 5 MiB.
- A caller that waits for the answer
- Up to 30 seconds, in line and running together. Then it gets
202with the run’s id, and the run carries on. When the server already holds as many waiting callers as it can, it gets that202at once. - Runs at once
- None, unless the workflow sets a limit, or one is set for your organization (by a platform admin, or by your provider in the Embed).
- Runs waiting in line
- 10,000 for an organization, 1,000 for one workflow. Then new runs get
429 RUNS_WAITING_LIMIT.
Self-hosted: MAX_STEP_OUTPUT_BYTES, SCRIPT_MEMORY_LIMIT_MB, RUNS_WAITING_PER_ORG and RUNS_WAITING_PER_WORKFLOW change these, and RUN_RETENTION_DAYS changes how long runs are kept. See Settings (.env).
Does a held run take a place?
It keeps its workflow’s place, but frees its organization’s, so an approval left for days doesn’t hold up other workflows.
Which runs never wait in line?
Runs started by an Error or Run Finished trigger, and a Sub-flow’s run, start at once. A schedule skips its turn while a run of it still waits.
If a worker stops mid-run
An accepted run is never dropped. A worker stopped normally, as in an update, finishes its runs first. One that stops without warning, when it is killed or runs out of memory, is noticed within about 10 seconds, or about 3 minutes when its whole server is gone. Another worker then carries on from what was finished:
- A finished step
- Doesn’t run again. Its result is used.
- A running step that reads or computes
- Runs again.
- A running step that changes something outside
- Such as an email, a
POSTor a new row. It isn’t sent again: it fails with Outcome unknown, and its error handling decides what happens next. Check the service it calls.
If the record of what was finished is lost, because Redis lost its data, a run that could change something outside fails with Progress unknown instead of starting over. One that only reads starts again from its first step. Runs in progress carry on through a Redis outage of up to about 2 minutes.
The run’s page says Restarted once or Restarted 2 times, and each step’s record says whether it was kept, ran again, or its outcome is unknown. In the API, the run has restarts, and each step recovery (replayed, rerun or unknown) and runAttempt. After the third stop the run fails with This run’s worker stopped 3 times, so the run was stopped.