Error Handling

When a node hits a transient error, Solaris AI Flow retries it automatically. If a failure is permanent, the workflow stops and the run is marked failed, unless that node is set to continue on failure. Here's how errors surface, when they retry, and how to fix the common ones.

Where errors appear

• Execution history - failed runs show a red status
• Run detail - the failed node is highlighted red with an error message
• Workflow editor - during live execution, failed nodes show a red indicator

Error types

Reading error details

In the Run Detail view, click the failed node. The error panel shows:

• Error message - human-readable description
• Error hint - suggested fix or context for the failure

Automatic retries

Transient failures are retried automatically before a node is marked failed. A node that throws a retryable error (a 429 rate limit, a 5xx from an upstream API, a timeout, or a network blip) is retried up to 3 times with exponential backoff (1s, then 2s, then 4s). If a retry succeeds, the run continues normally.

Retries are scoped to operations that are safe to repeat:

• Read and data operations retry freely - price lookups, token feeds and lists, balance reads, and HTTP GET. For example, a Pump.fun discovery feed that blips with a 429 simply runs again.
• Side-effecting operations never auto-retry - token buys/sells and swaps, transfers, message sends (Telegram, Discord), x402 payments, and signed on-chain trades. Repeating one of these after an ambiguous failure could double-send or double-spend, so they fail on the first permanent error.
• Config, auth, and validation errors don't retry - they would fail again on a second attempt, so the node fails immediately with the real message.

Continue on failure

By default, a node that fails permanently stops the whole run. To let the workflow carry on instead, turn on Continue workflow on failure from the node's action menu (the ••• / right-click menu, next to Deactivate). Nodes with it enabled show a small On fail badge on the canvas.

When such a node fails (after its retries are exhausted):

• It is recorded as skipped rather than failed, with the error preserved on the node so you can still see why in Run Detail.
• Steps that depend on its output are skipped too, but independent branches and the rest of the workflow keep running.
• The run finishes as completed instead of failed.

This is useful for non-critical steps - for example a flaky data feed on a scheduled workflow, where you'd rather skip one source than kill the whole run. It also keeps scheduled triggers healthy, since a completed run resets the failure streak described below.

Auto-paused schedules

To stop a broken schedule from burning runs forever, a cron- or webhook-triggered workflow is paused automatically after 4 consecutive failed runs. The Workflows list shows a deactivation reason ("Auto-disabled after 4 consecutive failed runs"), and the schedule stops firing until you re-enable it.

• Any successful run resets the streak to 0, so an occasional failure never trips it. This is also why turning on Continue on failure for a flaky step keeps a schedule alive: the run completes and the counter resets.
• A later success does not auto-resume a schedule that was already paused. Re-enable it from the Workflows list or the editor toolbar after fixing the cause.
• Manual runs, and runs you cancel yourself, don't count toward the streak.

Execution timeout

All executions have a 10-minute hard limit. If your workflow approaches this limit:

• Remove unnecessary Delay nodes
• Reduce data volumes (lower limit parameters)
• Split into multiple smaller workflows

Stuck executions

Executions stuck in "running" for more than 10 minutes are automatically marked as failed by a background cleanup job. If you see this, the underlying action crashed mid-flight.

Next steps

• Credentials - managing API keys
• Run Detail - inspecting execution results