---
sourceDocument: Australia IT Operations Management
sourceDocumentLink: https://www.servicenow.com/docs/r/australia/it-operations-management

 Release :

    - australia

ft:locale :

    - en-US

ft:publication_title :

    - Australia IT Operations Management

ft:clusterId :

    - itom

bundleId :

    - itom

workflow :

    - Technology


---

# Cloud Request Retry Configuration

# Cloud Request Retry Configuration {#ariaid-title1}

Release version: Australia  
Updated March 12, 2026  
![](https://www.servicenow.com/docs/portal-asset/ico-clock) 2 minutes to read
Summarize  
![AI sparkle icon](https://servicenow.com/docs/portal-asset/ai-sparkle-icon) Summarized using AI  
This content was generated using new OpenAI-powered functionality. Results are provided on an as is basis and are not guaranteed to be accurate or complete.  

## Summary of Cloud Request Retry Configuration

Cloud Request Retry Configuration enables Discovery admins and Cloud admins to manage retry mechanisms for requests that are throttled by cloud providers during Discovery processes.
This functionality is crucial for ensuring that requests to services like AWS and Azure are retried effectively, enhancing the reliability of data retrieval.
Show full answer Show less  

## Key Features

* **Customizable Retry Configurations:** Administrators can tailor existing configurations or create new ones specifically for each cloud provider.
* **Access:** You can find the configuration under All \> Discovery \> Cloud Request Retry Configuration.
* **Retry Strategies:** The framework supports various strategies including Exponential backoff, Response header backoff, and Custom backoff.
* **Integration with MID Servers:** Retry configurations are synchronized with MID Servers via the property mid.cloud.discovery.retry.configuration.

## Key Outcomes

Using the Cloud Request Retry Configuration, customers can expect:

* Improved reliability of Discovery operations by effectively handling throttled requests.
* Greater control over request handling, allowing for tailored retry mechanisms based on specific cloud provider responses.
* Enhanced operational efficiency by minimizing disruptions caused by throttling during data retrieval processes.  
If a request is throttled by a cloud provider during Discovery, Cloud Request Retry Configuration provides a customizable method to retry requests. Discovery and Service Mapping Patterns includes a retry configuration for AWS and Azure. You can customize the included configuration or create your own.
Discovery admins and Cloud admins can access the request retry configuration at AllDiscoveryCloud Request Retry Configuration. You can create one configuration for each provider.  
When a request is throttled, the retry framework uses retry configuration defined for the provider to handle retries before returning the final response to the ApiCommand classes:

* AwsApiCommand
* AzureApiCommand
{#cloud-request-retry-configuration__ul_vnx_nb1_b5b}

The retry configurations are synced with the MID Servers through the
MID Server property,
mid.cloud.discovery.retry.configuration.  
There are the following retry strategies:

* Exponential backoff
* Response header backoff
* Custom backoff
{#cloud-request-retry-configuration__ul_ipy_1h1_b5b}

## Exponential backoff {#cloud-request-retry-configuration__section_lgs_2h1_b5b}

For the following example configuration:{#cloud-request-retry-configuration__table_chm_xw1_b5b__entry__2}

| Setting | Value |
|-|-|
| Max retries | 3 |
| Response codes | 429 |
| Base delay in ms | 1000 |
| Max delay in ms | 10000 |
| Additional delay window in ms | 1500 |
[ ]

{#cloud-request-retry-configuration__table_chm_xw1_b5b}  
The Exponential backoff retry strategy works as follows:

* 1st retry---the backoff multiplier is randomly selected between 0 and 1. The max delay value is 400 ms (400 \* 1).
* 2nd retry---the backoff multiplier is randomly selected between 0 and 3. The max delay value is 1200 ms (400 \* 3).
* 3rd retry---the backoff multiplier is randomly selected between 0 and 7. The max delay value is 2800 ms (400 \* 7).
{#cloud-request-retry-configuration__ul_rwr_fx1_b5b}

On subsequent retries, if the delay exceeds 10000 (the max delay), 10000 will be used as
initial delay.

Once the initial delay is generated, jitter is added to the delay. The jitter window is
defined by the Additional delay window in ms field. The system
selects a random value between 0 and 1500 and adds it to the initial delay.

If the initial delay is 500, the final delay (with jitter) can be a value between 500 and
2000 ms.

## Response header backoff {#cloud-request-retry-configuration__section_ffr_2y1_b5b}

For the following example configuration:{#cloud-request-retry-configuration__table_a4m_gy1_b5b__entry__2}

| Setting | Value |
|-|-|
| Max retries | 3 |
| Response codes | 429 |
| Response header | Retry-After |
| Response header delay unit | Seconds |
| Additional delay window in ms | 1500 |
[ ]

{#cloud-request-retry-configuration__table_a4m_gy1_b5b}  
The Response header backoff strategy works as follows:

* Fetch the value of header Retry-After from the server response.
* Convert the Retry-After to milliseconds by multiplying by 1000.
{#cloud-request-retry-configuration__ul_e14_sy1_b5b}

Once the initial delay is generated, jitter is added to the delay. The jitter window is
defined by the Additional delay window in ms field. The system
selects a random value between 0 and 1500 and adds it to the initial delay.

If the initial delay is 2000, the final delay (with jitter) can be a value between 2000 and
3500 ms.

## Custom backoff {#cloud-request-retry-configuration__section_ipx_byx_f5b}

With a custom backoff retry strategy, you define the Max retries and
Response codes and create your own Mid script include that defines how requests are retried using the
getDelay() function. For more information, see [Script includes](https://www.servicenow.com/docs/access?context=c_ScriptIncludes&version=australia&pubname=australia-api-reference&ft:locale=en-US).

*[\>]: and then