> For the complete documentation index, see [llms.txt](https://docs.lleverage.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.lleverage.ai/build-and-improve/automate/test-and-publish/error-handling-and-validation.md).

# Error handling and validation

Configure explicit retry or continue behaviour and understand what validation cannot protect you from at runtime.

Workflow failure behaviour is explicit: decide what should stop, what may retry and what can continue with an error recorded.

## Default behaviour is abort, with no retry

Nodes do **not** retry by default. If a node throws and no alternative failure strategy applies, execution stops and the run ends in error.

## Retry is opt-in per node

For supported non-trigger nodes, **Enable Retry** adds node-level retry behaviour. The current defaults when enabled are:

* 3 retries;
* 1,000 ms fixed interval;
* abort after retries are exhausted.

The current UI allows retry count and interval to be adjusted, but there is no exponential backoff or jitter.

Some integration write actions are marked non-retryable to avoid duplicating side effects. For those actions, the platform overrides builder retry settings.

## Continue after a failed node

A node can instead continue after retries are exhausted. Downstream logic can inspect `_error` and `_retries` and branch accordingly.

There is no general fallback feature today: no fallback model, dedicated error output handle or automatic alternative path. If you need an error route, use continue plus explicit downstream logic.

A Workflow that continues past a node error still finishes with an overall **error** status. Continuing execution does not turn the failed run into success.

## Understand a failed production run

When a published Workflow fails and Lleverage has enough deterministic evidence, the failure is classified and the notification points to the person who can most safely act next. Depending on the evidence, that can distinguish issues such as unreadable input, context limits, workflow configuration or script problems, provider or upstream failures, and aborted or timed-out execution.

For signed-in viewers, the failed-run view also leads with a short plain-language explanation: **What happened** and **What you can do**. The explanation uses the viewer's browser language where possible and keeps the raw error collapsed underneath for deeper diagnosis. When Lleverage cannot produce the explanation, the raw error remains available instead. Anonymous Workflow-app viewers currently fall back to the raw error because the explanation service requires an authenticated viewer.

Treat the classification and plain-language explanation as routing help, not a replacement for the execution evidence. Open **Activity** to inspect the affected run and keep the raw failure detail available when deeper debugging is needed.

If the platform cannot identify a cause safely, the failure remains **unknown** instead of guessing. An unknown classification does not by itself establish whether the problem is in the Workflow, an external system or Lleverage.

In-app Workflow-failure notifications are currently sent for production executions to Project **Owners** and **Builders**. Test executions do not send these notifications.

## Terminal status

When several terminal conditions are present, the engine prioritises aborted/timeout, then error, paused, continue and success. A Request pause therefore produces a paused execution unless a higher-priority terminal condition has occurred.

## Validation is narrower than runtime

Builder validation catches configuration omissions and selected node-specific minimums. It does not prove that expressions, third-party APIs, permissions, rate limits, live data or trigger delivery will work.

Use Monitoring to investigate failures and treat recurring errors as evidence that the implementation needs changing.


---

# 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 dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.lleverage.ai/build-and-improve/automate/test-and-publish/error-handling-and-validation.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

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.