Automations Retry Logic (v1)

Automations v1 recover from failures by retrying individual actions and by retrying an entire process. Automations v2 retries resume from a failed node.

Retrying Individual Actions

Automations often interact with remote systems that can be temporarily unavailable for very short periods of time. Rather than exiting immediately when an action step cannot be completed, an Automation automatically retries the operation.

Automations retry failed steps up to three times. The time between retries gradually increases, starting with a 15-second pause and extending to 1 minute. If an action step fails after the third attempt, it is logged as a failure in the Automations Run log. Retries are not logged as separate actions in the run log. Only the final status of the step is recorded.

If every action step in an Automation Run fails, the entire run is marked with a Failure status. If at least one action step succeeds while others fail, the Automation Run is marked with a Partial Failure status.

Retry Automation Runs on Failure or Partial Failure

You can configure an Automation to automatically retry the entire Automation Run when it completes with a Partial Failure or Failure status. This lets you build a process that will eventually complete if a remote system suffers a long-term outage spanning multiple days.

By default, Automations do not retry Failures or Partial Failures unless explicitly configured. The time to wait before retrying can be configured between 1 and 24 hours, and the maximum number of retry attempts can be set between 1 and 10.

Retry settings can be configured while setting up or modifying an Automation and are available with any type of Automation.

When retried, the Automation rebuilds its plan against the files available at retry time, including expanding globs or wildcards and checking the current destinations. It also keeps the original run's record of successful or skipped steps. Matching steps are left out of the new plan, so replanning does not mean repeating every operation from the original run.

For triggers that select files by listing a source folder, a retry can include newly matching files. File-action retries remain tied to the files that triggered the original run.

Each retry appears in the logs as a separate Automation Run.

Automatic exception handling, with options for when and how many times to retry, lets Automations recover from longer-term interruptions without manual intervention.