> For the complete documentation index, see [llms.txt](https://docs.stackai.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.stackai.com/technical-reference/workflow-execution/retries-fallbacks-and-error-branches.md).

# Retries, Fallbacks, and Error Branches

Retries repeat failed work. Fallback branches provide an alternate path. Configure them together so an error leads to a deliberate result.

{% embed url="<https://files.gitbook.com/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FSQ1Sgy933krTyK0S4JpP%2Fuploads%2FsCbfJPJ0MpjtMpuCOQqg%2FG033.mp4?alt=media&token=b6418512-a20b-4016-91a5-42efaa47c8f8>" %}

## Before you begin

An editable workflow and knowledge of whether the affected action reads or changes external data.

## Key concepts

| Term              | Definition                                                                                                                                                                                                |
| ----------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Retry             | A repeated attempt after a failed or uncertain operation. It can repeat external changes; use it only when the result is understood.                                                                      |
| Transient failure | A failure that can resolve without changing the intended input, such as a temporary service interruption. Retry guidance is operation-specific; invalid credentials or fields usually require correction. |
| Fallback          | An alternate response, model, or branch used under a configured failure condition. A fallback can produce a usable answer while the original operation still failed.                                      |
| Branch            | One possible path after a routing decision. An unselected branch is not automatically a failed branch.                                                                                                    |
| Side effect       | A change outside the returned answer, such as creating a record or sending email. Cancellation or release rollback does not undo a completed side effect.                                                 |

## Settings

These controls apply to nodes that expose them. A retry repeats the same failed work; a fallback changes how the workflow recovers.

| Control                 | Values and behavior                                                                      | When to use it                                                                                              |
| ----------------------- | ---------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------- |
| **Retry on Failure**    | Off by default. Enabling it initially sets **Max Retries** to 2.                         | A temporary failure can succeed on another attempt.                                                         |
| **Max Retries**         | 1–10 retries in the builder control.                                                     | Bound how many additional attempts the node can make. More retries can increase latency and external calls. |
| **Retry Interval (ms)** | 100–20,000 milliseconds; default 1,000 ms.                                               | Set the delay between attempts. This is a time interval, not a retry count.                                 |
| **LLM Fallback Mode**   | Select an alternative model when the node exposes this setting.                          | Continue with another model when the configured fallback condition applies.                                 |
| **On Error**            | Controls whether unresolved failure stops execution or uses the supported recovery path. | Decide what the workflow should return or do when the original work cannot complete.                        |

Do not assume the same options exist on every node. Inspect the settings on the node that can fail.

## Configure failure handling

1. Open the node’s advanced settings and inspect its retry options.

![On Error controls whether the node stops the workflow or follows a supported recovery path.](https://content.gitbook.com/content/SQ1Sgy933krTyK0S4JpP/blobs/RGFigcy5yOUcZUPjBXVV/assets/g033-g033-01-stop-settings.png)

On Error controls whether the node stops the workflow or follows a supported recovery path.

2. Choose the error behavior and connect the fallback path where supported.
3. Run the workflow with inputs that exercise the relevant error condition. Inspect which node and branch produced the final result.

<figure><img src="https://1957915746-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FSQ1Sgy933krTyK0S4JpP%2Fuploads%2FbCIUmWNcHB9dS7JZjWua%2Freliability-controls.png?alt=media" alt="Reliability controls controls in StackAI" width="800"><figcaption><p>Retry on Failure, LLM Fallback Mode, and On Error address different situations. A retry repeats an eligible failed operation. A fallback uses the configured alternative. On Error controls what the workflow does when the failure remains unresolved. Review each control separately; enabling a retry does not undo external changes.</p></figcaption></figure>

The workflow either returns the intended recovery result or reports the failure clearly.

## Behavior and limitations

Retries help transient failures; they do not correct invalid credentials or missing inputs. A fallback result can hide the original error from the final answer, so preserve the run details. For loops, inspect the specific node variant’s failure behavior rather than assuming one failed item is skipped.

## Related resources

[Error handling and fallback branches](/guides-and-quickstarts/workflow-builder/error-handling-and-fallback-branches.md)

[Execution Order and Node Dependencies](/technical-reference/workflow-execution/execution-order-and-node-dependencies.md)


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.stackai.com/technical-reference/workflow-execution/retries-fallbacks-and-error-branches.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
