FlowsGuide

Step run settings: retry, skip, stop, cache

Real steps fail, slow down and sometimes have nothing to do. Every executable step of a flow has a Run settings tab that decides what happens then — try again, carry on, skip itself, end the flow early, wait, reuse a recent result — so the flow’s logic stays in the flow and not in try/except blocks scattered through your scripts.

10 min readBefore this: What a flow is, Passing values between stepsOpen in Waiso
What you will learn
  • Retry a failing step, constant or exponential, only when a condition holds
  • Let a flow continue past a failure, and what later steps receive
  • Skip a step or stop the whole flow with an expression
  • Cache a step’s result for published runs and bound it with a timeout

A policy per step

Click a step and open Run settings. The tab has two groups. Flow control changes the path: Skip step if, Stop flow if, Sleep after step. Execution policy changes how the step itself runs: Retry on failure, Continue on error, Timeout, Cache result. Each is a switch; off means the step behaves exactly as if the setting did not exist.

A step with a retry fails, waits, and succeeds on the next attempt; a step whose Skip step if is true is drawn skipped.

A step with settings carries small icons on the canvas — hover one for a summary such as Retry: 3 extra attempts, exponential from 2 s or Cache: 10 min. Run settings exist on script and SQL steps, subflows, AI Scraper, Send email, HTTP Request and Transform steps; conditions, loops, parallel nodes, approvals and Start have none.

The expressions they use

Three settings take a JavaScript expression that must return true or false. It reads the step’s own inputs by name, earlier outputs as nodes.<alias>.output and variables as vars.NAME — the same scope as a condition. A syntax error shows under the field at once (This expression does not parse); an expression that throws or returns something that is not a boolean fails the step with expression_error.

SettingCheckedExtra name it seesExample
Skip step ifBefore the step runs—vars.DRY_RUN === 'true'
Stop flow ifAfter the step succeedsresult — the step’s outputresult.rows.length === 0
Retry only ifAfter a failed attempterror — the attempt’s errorerror.message.includes('503')

When a step fails

Retry on failure

Runs the step again when it fails or times out. Set the extra attempts (1–10), the delay in seconds (1 s–1 h) and Constant or Exponential — exponential doubles the delay each time, and the panel spells the schedule out (attempt 2 after 2 s, attempt 3 after 4 s…). The optional Retry only if… expression decides per failure; when it is false the step is not retried and the run says Not retried — the retry condition was false. Every attempt is recorded and listed under Attempts in the step’s run detail, and the Timeline shows each Retry wait.

Continue on error

The step may fail and the flow goes on. Later steps receive, in place of its output, an object describing the error; the step shows Failed — the flow went on in amber, and the whole run ends Completed with errors instead of Success. With a retry as well, the error is passed on only after the last attempt.

Expected outputSuccessWhat a later step receives from a step that failed with Continue on error
{
  "error": {
    "message": "connection refused",
    "code": "http_request_failed",
    "stepId": "n3",
    "stepName": "Fetch prices"
  }
}

Timeout

Stops each attempt after this many seconds; a timed-out attempt counts as a failure (code timeout), so a retry can run it again. Without it a step is bounded only by the flow’s own time limit (30 minutes by default). An AI Scraper step sets its Step timeout in its own panel instead.

Skip, stop and sleep

  • Skip step if: when true the step does not run, it is drawn dashed as Skipped by condition, and later steps receive an empty value (null).
  • Stop flow if: checked after the step succeeds, with its output as result. When true nothing after it runs and the flow ends as you choose under The flow ends as: Success, Skipped or Error (failed, code stopped_by_condition). The step shows Stopped the flow.
  • Wait after step: For an amount (seconds, minutes, hours or days, up to 30 days) or Until a date and time (fixed, or from an expression such as nodes.a.output.sendAt) before the next step starts. A date already past does not wait. A wait longer than a minute pauses the run and frees its worker: the run reads Waiting until 14:30 and continues on its own at that time, even after a restart.

Cache result

With Cache result on, a run reuses the output of a recent successful run of the same step with the same inputs instead of running it again, for the minutes you set (1 minute to 7 days). The key covers the step as published, the code it runs and its resolved inputs — change any of them and the step runs fresh. A reused step reads From cache on the canvas and in the run.

How a run ends

Run statusWhen
SuccessEvery step succeeded, was skipped, or a Stop flow if ended it as Success.
Completed with errorsAt least one step failed with Continue on error and the rest finished (also when a subflow ended this way).
SkippedA Stop flow if fired with “The flow ends as: Skipped”.
FailedA step failed for real — after its last retry, without Continue on error — or a Stop flow if chose Error.

The Runs page, the run panel and the canvas use the same words and colours: failed is red, failed · went on amber, cached and skipped have their own marks.

Ranges and checks

  • Retry: 1–10 extra attempts, delay 1 s–1 h. Wait: 1 s–30 days. Cache: 1 min–7 days. Timeout: a positive number of seconds.
  • A wait longer than 30 days is refused with wait_too_long — use a schedule. A wait longer than a minute inside a loop or a parallel branch is refused with long_wait_in_loop / long_wait_in_branch: place the wait before the loop.
  • A value out of range is refused at publish and at run with invalid_run_setting, naming the step and the setting.
  • The On error step cannot use Continue on error, and a cache is never offered on Send email.

Related topics