Error Handling & Retries

Error Handling & Retries answers: How should a Step retry, and where should the run go after retries are exhausted? Both controls live in the Step’s Test & Debug tab. For a failure that already happened, start in Activity and inspect the affected Step execution.

Retries and error routing are off by default, so an untouched Step fails the whole run the first time it fails. This page covers both controls and the failures that are never retried.

Retry on Fail

Any step can retry itself before giving up. Open the step, go to the Test & Debug tab, and turn on Retry on fail.

The defaults are the ceiling. Turn the toggle on and leave the fields alone and you have asked for ten retries a minute apart: ten minutes of a run held open. Most third-party APIs recover much faster than that, so it is worth lowering both before you save.

Max retries counts retries, not attempts. Set it to 3 and a failing step runs four times in total: the original, then three more. Budget accordingly.

The wait is a fixed interval, not an increasing backoff.

Each retry is marked in the step’s execution history as Attempt 2, Attempt 3, and so on, with its own error message and timestamp. You can see whether a step succeeded first time and how far apart the tries were. See Executions.

Three things never retry

Even with the setting on, three failures are not repeated because repeating them cannot help:

• An expired or revoked connection. The account needs reconnecting; another attempt would fail identically. See Managing Connections.
• Stop and Error. That step fails deliberately, with the same message every time.
• A step whose outward call may already have gone through. If a step sent its email or created its ticket and the confirmation never came back, Glow declines to repeat the call. Trying again could send it twice. The step is marked failed and your error path still runs, so you can decide what to do about it.

Retries do not read the reason a step failed

Those three are the only exemptions. Every other failure is retried on the same schedule, whatever caused it.

So a request the other service rejected on its merits (a 400 from a malformed body, a 404 on a record that does not exist, a 422 from failed validation) is re-sent byte for byte on every attempt. It fails the same way each time.

At the default settings that is ten retries, sixty seconds apart: eleven runs in all, ten minutes before the run moves on. Where a rejection is final, set Max retries to 0 on that step and let your error path handle it straight away.

Inside Run for each item this is handled for you. A failed item is retried only when the failure looks transient. A rejection moves straight to failed without consuming the retry budget.

If This Step Fails: Stop or Continue

Alongside Retry on fail, the same tab has an If this step fails setting that decides what happens once a step has given up.

• Stop Workflow (default): immediately stop execution and mark the workflow as failed.
• Continue: continue running and pass the error message through the output, so you can handle the failure yourself.

Choosing Continue reveals a Select Error Path button just below the setting. Pick the step a failure should route to, and Glow draws that path on the canvas as its own line. The normal output carries on as before, and the error path runs only when the step fails.

Note what happens if you skip that second half. With Continue set and no error path chosen, a failed step simply carries on to the next step in sequence, passing its error message along as its output. That is a real choice for a step whose failure does not matter, but it is rarely what someone means by “continue”.

That is the usual shape of a resilient workflow: the success path does the work, the error path tells somebody or parks the data for review.

The two settings work as one machine. Retries happen first; If this step fails only decides what happens when they run out:

Building fallback logic

When a step permanently fails, you decide how the workflow responds.

Knowing when something failed

Every failed run is recorded in Activity with its Step timeline and error summary. Open the workflow on the canvas, then use Step-Level Executions for the failing Step’s output and attempt details.

To be told the moment something fails rather than going to look, build the notification into the workflow itself. That is what the error path is for:

🚨 _Step Failure Detected_
• _Time:_ {{ $now | format_date:"YYYY-MM-DD HH:mm:ss" }}
• _Workflow ID:_ {{ $workflow.id }}
• _Execution ID:_ {{ $execution.id }}
• _Failing Step:_ Step {{ $error.stepNumber }} ({{ $error.stepName }})
• _Error Message:_ `{{ $error.message | truncate:300 }}`

A notification you build says exactly what you need to know, and arrives in the channel your team already watches. Worth doing for anything you cannot afford to have fail unnoticed.

Diagnose a failure before changing the policy

This page owns the behavior you configure for future failures. For an incident that already happened, start in Activity, inspect the affected Step in Step-Level Executions, and use Troubleshooting & Common Errors for the symptom or exact message.

What’s Next?

• 👉 Activity →: find the failed run and identify the affected Step.
• Step-Level Executions: inspect each attempt and the Step’s recorded output.
• Troubleshooting & Common Errors: diagnose a symptom or exact error message.