Retries

Any step in a flow can be configured to retry automatically if it errors out, so a momentary failure doesn’t take down the whole run.

When a step is set to retry, an error triggers another attempt after the configured delay, up to the configured maximum number of attempts. If both a constant delay and an exponential backoff are configured, the constant-delay attempts run first, followed by the exponential ones.

Errors have a specific shape that the retry logic (and any downstream error handler) relies on.

A few situations where this is worth reaching for:

API requests: retry a call that failed due to a transient network blip or a temporary upstream outage, e.g. every 5 minutes for up to 5 attempts, so the request eventually succeeds instead of just failing once.
Payment processing: retry a transaction that failed because of a momentary issue on the payment gateway or the customer’s bank, backing off further each time so you’re not hammering the gateway during an outage.
Batch jobs: retry a batch step that failed under temporary resource pressure, e.g. every 30 minutes for up to 6 attempts, so the batch still completes without anyone re-triggering it by hand.

The same pattern applies just as well to inventory syncs, backups, file uploads, scraping jobs, and so on.

Constant retries

From the step’s Advanced menu, open Retries and toggle Constant retry enabled.

Set the maximum number of attempts and a fixed delay between them. The delay is stored in seconds, but the input accepts minutes, hours, or days too.

Exponential backoff enabled

From the step’s Advanced menu, open Retries and toggle Exponential backoff enabled.

Set the maximum number of attempts along with a base (in seconds) and a multiplier; the delay before each attempt grows with the attempt number.

The formula is delay = multiplier * base ^ (number of attempt).

For example, with:

base = 3
multiplier = 2
attempts = 5

the delays between attempts work out to:

#	Delay	Formula
1	After 6 seconds	-
2	18 seconds after attempt #1	2 * 3^2
3	54 seconds after attempt #2	2 * 3^3
4	162 seconds after attempt #3	2 * 3^4
5	486 seconds after attempt #4	2 * 3^5

Continue on error with error as step’s return

When enabled, the flow moves on to the next step once retries are exhausted, even if the step never succeeded — letting you catch and handle the failure explicitly, for instance with a branch one right after.