Error handling

Real-world automation has to cope with flaky networks, rate limits, and transient failures. Orvanta provides several mechanisms so a single failure doesn’t have to mean a failed run.

Retries

Any node can declare a retry policy. On failure, Orvanta re-runs the node up to the configured limit with an optional backoff between attempts.

Setting	Description
Max attempts	How many times to retry before the node is considered failed.
Backoff	Fixed or exponential delay between attempts.
Retry on	Restrict retries to specific exit codes or error classes.

A node is only marked failed once its retries are exhausted.

Timeouts

Each node can set a maximum duration. If it exceeds the timeout, the node is cancelled and treated as a failure (which then triggers any retry policy).

Error branches

Instead of failing the whole run, route failures down a dedicated edge:

Node A ──success──→ Node B
       └─error────→ Cleanup / Notify

This lets you compensate, clean up, or alert without aborting the workflow.

Run-level error handler

A workflow can define a run-level error handler — a node (or sub-workflow) that runs whenever any node fails and is not otherwise handled. Use it to send a notification, open an incident, or record the failure.

Notifications

Pair error handling with a notification channel (email, Slack, or webhook) so the right people hear about failures that need human attention.

Jobs and runs — Run statuses including failed.
Caching and concurrency — Limit load that causes rate-limit failures.
Approval steps — Escalate risky recovery to a human.