Retry Strategies
A retry means: "If this step fails for a temporary reason, wait a little and try again."
Retries are useful when the problem may fix itself, such as a slow network, busy server, temporary file lock, or rate limit.
The Basic Idea
When Retries Help
| Problem | Why retry may help |
|---|---|
| Network hiccup | The connection may work a few seconds later |
| Busy server | The system may recover after a short wait |
| Rate limit | Waiting gives the external service time to accept more requests |
| File lock | Another process may release the file soon |
| Temporary timeout | The next attempt may complete faster |
Retries are not a fix for wrong passwords, bad file paths, missing required data, or incorrect step setup. Those need correction, not repeated attempts.
Transient Error Detection
Automation Hub automatically detects temporary errors and classifies them as retryable. The system checks for common transient patterns such as timeouts, connection resets, temporary unavailability, and TLS handshake failures. When a transient error is detected, the retry system knows the step is a good candidate for another attempt.
Where Retries Are Configured
Retry settings are configured at the job level, not on individual steps. This means all steps in the same automation share the same retry rules.
The retry configuration (RetryConfig) has these settings:
| Setting | Internal field | What it controls |
|---|---|---|
| Maximum retries | maxRetries | How many times to retry after the first failure |
| Retry delay | retryDelaySeconds | How long to wait before the first retry (in seconds) |
| Backoff multiplier | backoffMultiplier | How much to increase the wait after each failed retry |
| Maximum wait | maxBackoffSeconds | The longest wait time allowed between retries |
By default, each step gets 1 attempt with no retry. You need to increase the maximum retries to enable retry behavior.
Temporal handles the retry orchestration durably, which means retries survive system restarts and are tracked reliably even during infrastructure disruptions.
Retry Options
Fixed Wait
Use the same wait time between every attempt. Set the backoff multiplier (backoffMultiplier) to 1.
Best for simple temporary problems that usually clear quickly.
Increasing Wait (Exponential Backoff)
Exponential backoff is the recommended strategy for external API calls. It reduces pressure on an already-stressed service and lowers the chance of hitting rate limits on retry attempts.
Wait a little longer after each failed attempt. Set the backoff multiplier (backoffMultiplier) to a value greater than 1.
The wait time is calculated as: retryDelaySeconds multiplied by backoffMultiplier raised to the attempt number. The wait is capped at maxBackoffSeconds so it never grows too large.
Best when the other system may be overloaded or asking you to slow down.
Which Retry Should I Use?
| Situation | Recommended retry |
|---|---|
| Calling an external API | Increasing wait |
| Reading from a database | Fixed wait |
| File temporarily locked | Fixed wait |
| Rate-limited service | Increasing wait |
| Wrong credentials | No retry; fix the connection |
| Missing required data | No retry; fix the input |
| Payment or duplicate-sensitive action | Be careful; confirm business rules first |
Example Configuration
Here is an example of how the retry settings work together:
| Setting | Value | Effect |
|---|---|---|
| maxRetries | 3 | Up to 3 retries after the initial attempt |
| retryDelaySeconds | 5 | First retry waits 5 seconds |
| backoffMultiplier | 2 | Each subsequent wait is doubled |
| maxBackoffSeconds | 60 | Wait never exceeds 60 seconds |
With these settings, the waits would be: 5 seconds, 10 seconds, 20 seconds. If the multiplier produced a wait longer than 60 seconds, it would be capped at 60.
What Happens After Retries Run Out
If a step keeps failing and no retries remain, the step is marked as failed.
What happens next depends on the step's error-handling setting:
| Error handling choice | Internal name | What happens |
|---|---|---|
| Stop the Job | STOP_WORKFLOW | The automation stops at the failed step, job status = FAILED |
| Continue Anyway | CONTINUE | The step is marked COMPLETED despite the error, automation moves on |
| Continue and Flag | CONTINUE_WITH_ERROR_OUTPUT | The step is marked FAILED, but the automation continues |
See Error Handling for how to choose the right behavior.
How to Read Retry Activity
When you monitor a run or read logs, look for:
- How many times the step was attempted
- Whether the retry eventually worked
- The error message from each failed attempt
- How long the automation waited between attempts
- Whether the same step needs retries often
If a step needs retries every day, the problem is probably not temporary anymore.
Good Retry Habits
Retry temporary problems
Use retries for slow networks, busy services, and short-lived failures.
Do not hide real problems
If a step is configured incorrectly, retries only delay the failure.
Avoid duplicate actions
Retrying steps that send emails, create tickets, charge payments, or write records can cause duplicate side effects. Confirm the external system is idempotent before enabling retries on those steps.
Be careful when retrying steps that send emails, update records, create tickets, or charge payments.
Use longer waits for busy systems
If another system is overloaded, fast repeated attempts can make the problem worse. Use a higher backoff multiplier and a reasonable maximum wait.
Review retry patterns
Frequent retries are a signal. They may mean the automation, connection, or external service needs attention.
Related Pages
- Monitoring Automations - how to see retry attempts in a run
- Logging - how to read retry messages
- Error Handling - what happens after retries fail