Skip to main content
By default, a step that still fails after its retries stops the run. For some workflows that is the wrong outcome: a check that should alert someone when a server is down, a Slack post that should not stop a file from being saved, or a fallback when one system is unavailable. For these, set the step to continue.

​
If this step fails

Open the step and find If this step fails in the properties panel:
  • Stop the run (the default): the run fails at this step.
  • Continue: the run goes on to the next step, and the step’s error is kept for later steps to read.
The setting is available on Connector, Knowledge, Attachment, File Store and Sandbox steps, and on Subworkflow steps that wait for their result. Send Email has its own If sending fails setting, which works the same way. Retries happen first. A step set to continue only continues once its retries are used up.

​
Reading the error

A step set to continue makes its error available to later steps as {{ <name>_error }}, where <name> is the step’s output name. When the step succeeded it is empty; when it failed it holds: When the step failed, its own output ({{ <name> }}) is empty. To handle the failure, add a Condition on {{ <name>_error }} with is not empty. The Yes branch runs only when the step failed. The variable picker lists the error variable under the step’s name.

​
Example: alert when a server is down

  1. A Schedule trigger every hour.
  2. An FTP step that lists the folder, with its output name listing and If this step fails set to Continue.
  3. A Condition: {{ listing_error }} is not empty.
  4. On Yes, a Send Email to the operations team: The FTP server could not be reached: {{ listing_error.message }}.

​
What always stops the run

Continue is for a step that fails on its own. These still stop the run, whatever the setting:
  • a tool call or connection blocked by your workspace’s governance policy;
  • an approval that is rejected or times out, and a Human Approval step;
  • a cancelled run, or a workspace out of credits.

​
How the run looks

A step that failed and continued shows as Failed with a Continued marker in the run’s step timeline. A run whose only failures were continued past ends Completed, marked With errors in the run list, so it is clear the workflow handled them. Filter the executions list by Completed with errors to find these runs.

​
Steps inside a loop

A Loop has its own On iteration error setting for a failing item. When a loop’s body is a single step, use the loop’s setting instead of the step’s: the loop records each failed item and goes on to the next.

​
Testing

A test run (Test run in the editor) does not run steps that would change something, so they cannot fail. To see the handling work, make a step that reads fail, for example by pointing it at an address that does not answer.