Node Execution Settings

Product documentation

Every node shares one set of execution settings — timeout, failure behavior, retries — separate from the node’s own configuration. They live in the same place on every node, so the pattern you learn once applies everywhere.

Open the settings

  1. Select a node on the canvas to open its settings sidebar.
  2. Click the gear button (Execution & runtime) in the sidebar header.

The drawer lists the node’s runtime sections flat: any injected capability sections first (Services, Storage, Runtime, Outputs — which sections appear depends on the node), then the shared Error Handling, Execution, and Retry sections present on every node. The back button returns to the node’s configuration.

Error handling

On Failure

What happens when the node fails (after its last retry attempt, if retries are enabled):

  • Stop — halt the whole run. The run fails with this node’s error.
  • Continue — record the failure and keep going. Nodes that consume this node’s outputs are skipped (there is no data to give them), independent branches keep running, and the run can complete with partial errors — the run header lists which nodes failed (see Debugging Runs).
  • Continue (pass error output) — record the failure and emit the structured error on the node’s reserved _error output port. Wire _error to a recovery branch — a notification, a fallback call. The error branch only activates on failure; when the node succeeds, it is skipped.

Defaults vary by node type. Nodes that do real work default to Stop. Triggers and utility nodes (control flow, Note) default to Continue, as do a few inherently optional nodes such as Run Command, Claude Code, Codex, and Perplexity Search.

Run even if upstream failed

Off by default. When an upstream node fails, downstream nodes are normally skipped. Turn this on for a node that must run regardless — cleanup or notification steps at the end of a branch.

Execution

Timeout (ms)

The wall-clock limit for one node execution, in milliseconds. Minimum 100 ms, up to 60 minutes; a node timeout cannot exceed the workflow’s run timeout.

Each node type carries its own default budget — for example API Request defaults to 60 seconds and Shell to 30 minutes — so an unset timeout gives the node its natural budget rather than a flat global default.

Two workflow-level settings interact with it (in the workflow’s settings, under runtime defaults):

  • Step timeout (ms) — applies to steps that don’t set their own timeout.
  • Run timeout (minutes) — caps the whole run: default 30 minutes, maximum 180.

Iteration settings

Nodes that can process either a whole list or one item at a time show two extra fields:

  • Iteration Mode — Auto (decide from the wired input), Per Item (run once per list item), or Batch (run once over the whole list).
  • Max Iterations — cap how many items per-item mode processes.

Use as Return

Marks this node as a return point when the workflow is called from another workflow’s Subflow node. The Subflow call returns the marked node’s outputs; with no marked node it returns the outputs of the workflow’s final nodes.

Retry

Off by default. When Retry on Failure is on:

  • Max Retry Attempts — 1 to 10, default 3.
  • Retry Delay (ms) — base delay between attempts, 100 to 60,000, default 1,000.
  • Backoff Strategy — Linear (delay grows by the base each attempt) or Exponential (delay doubles each attempt; the default). Delays get random jitter so parallel branches don’t retry in lockstep.

Only transient failures are retried: timeouts, network errors, and 5xx responses. Permanent errors — validation failures and most 4xx responses — fail immediately without burning attempts. Retries happen inside the same step; On Failure applies only after the last attempt fails.

Declared outputs

Nodes that produce data — API Request, Code, AI, Map / Transform, Shell, Run Command, the coding agents — include a Declared outputs editor in their settings. Each declared entry becomes a typed output port on the node that downstream nodes wire against, and the engine checks the real output against the declaration at run time.

Click + Declare an output and configure the entry:

  • Handle and type — the port’s name and its type. Pick a registered shape as the type to reuse a shared schema.
  • Source handle and Path — where the value comes from: an existing output and a path into it (for example result.items).
  • Parse — Raw (no parse), JSON, NDJSON, CSV, or XML. Parses a text output into structured data before typing applies — useful when a command or API returns CSV or JSON as a string.
  • Schema — attach structure beyond the base type: + JSON schema for an inline JSON Schema (which you can save as a reusable shape), or Pin last run to capture the structure the node actually produced on its most recent run.

On mismatch sets one policy for all declared outputs:

  • Ignore — skip validation.
  • Warn — log the mismatch and continue.
  • Fail node — fail the node when the output does not conform, so bad data never leaves the node.

Use Test against a sample on any entry to paste a raw sample of the node’s output and run it through the exact extraction, parsing, and validation the engine uses — without executing the node.

Model outputs

On AI nodes the editor shows a Model produces group: typed fields the model is constrained to generate. Each field’s description steers generation and its required toggle shapes the response contract; Import schema creates the fields from an existing JSON Schema in one step. The reply is parsed against these fields and each becomes its own output port. See AI Agent for details.

Input constraints

The editor’s Input constraints section works in the other direction: declare what an input handle accepts. A strict constraint fails the node before it runs instead of executing with malformed input.