Retry policy
-
- UpdatedJan 30, 2025
- 4 minutes to read
- Yokohama
- Create Workflows
Automatically retry failed requests when a step encounters an intermittent issue such as a network failure or request rate limit. Set a retry policy to prevent having to manually trigger the step again.
Features
Retry policies can be:
- Created to support connection timeouts or failed requests based on header, status, response body, error, and HTTP method.
- Applied to all actions that use a given connection alias.
- Applied directly to an action step.
Use retry policies to define:
- The conditions that must be met to retry a step.
- The time interval to wait before retrying a step.
- The maximum number of retry attempts the step makes before stopping.
Note: You can only create retry policies for JDBC, REST, and SOAP steps.
Create a retry policy
Automatically retry failed requests when a step encounters an intermittent issue such as a network failure or request rate limit. Set a retry policy to prevent having to manually trigger the step again.
Before you begin
- Role required: connection_admin or credential_admin
Procedure
Example: Retry policy with Retry Strategy as Exponential Backoff

In this example, the policy is defined to attempt retry when one of these conditions
is met:
- HTTP Method is GET and Error is Connection Timeout
- HTTP Method is GET and Status Code is 429
What to do next
- Create a Connection & Credential alias, if you do not have the required alias.
- Assign the retry policy as Default Retry Policy to the
required Connection & Credential alias.Note: A default retry policy is provided and is selected as Default Retry Policy. If you have created retry policies, you can select the required policy as Default Retry Policy.
- Create an HTTP(s) Connection in the Connections related list for the Connection & Credential alias. For more information, see Connections and Credentials.
- Verify and view the details of the retry attempts by navigating to .