ServiceNow Retry Policy Explained

Failure and resilience in integration systems

Integrations between systems inevitably encounter failures. Network timeouts, temporarily unavailable services, rate limits and transient errors occur frequently. Retry Policy provides automated mechanisms to retry failed integration requests, reducing manual intervention and improving overall system reliability.

Not all failures should trigger retries. Permanent failures—authentication errors, not-found errors, invalid data—will not succeed if retried. Retry Policy should distinguish between transient errors worth retrying and permanent errors that require different handling.

Where Retry Policy lives in Integration Hub

Retry Policy is configured on Integration Hub actions and flows. Each action can have a Retry Policy defining whether failures will be retried, how many times and with what delay. Retry Policy settings are visible in the action configuration. Default policies apply if no explicit Retry Policy is configured.

Retry Policy interacts with error handling workflows. When retries are exhausted, errors route to error handlers that may escalate to tickets or notify teams. Retry Policy and error handling work together to create resilient integrations.

Retry policy configuration and backoff strategies

Retry Policy defines the number of retry attempts—typically 3 to 5 for most integrations. Each attempt waits before retrying; waiting avoids overwhelming a temporarily unavailable service. Backoff strategy determines wait time: fixed delay, exponential backoff, or jittered delay.

Fixed delay retries at regular intervals, e.g., every 30 seconds. This strategy is simple but can create thundering herd problems if many integrations retry simultaneously.

Exponential backoff increases delay between retries: 1 second, then 2 seconds, then 4 seconds. This strategy gives services more time to recover between attempts.

Jittered delay adds randomness to backoff so that simultaneous failures don’t cause coordinated retry storms. Jitter improves resilience when multiple integrations fail at the same time.

Idempotency and safe retries

For retries to be safe, operations must be idempotent: performing the same operation twice must have the same result as performing it once. If an operation creates a database record, retrying must not create duplicate records.

Idempotency requires unique request identifiers. A request ID included in each request allows the service to detect retries and avoid duplicate processing. Integration Hub supports idempotency keys for this purpose.

Not all operations are safely idempotent. Money transfers and irreversible actions should use idempotency keys and require extra care. Operations that are inherently safe—data reads, state updates with version checks—can be retried freely.

Worked example: retry policy for a payment processing integration

A payment processing integration calls an external service to charge a customer. Network timeouts occasionally occur. Retry Policy is configured to retry up to three times with exponential backoff. First retry waits 2 seconds, second retry waits 4 seconds, third retry waits 8 seconds. If all retries fail, the error is escalated to a ticket for manual investigation. Idempotency keys prevent duplicate charges if the payment succeeds but timeout prevents confirmation.

Related concepts and extensions

Circuit Breaker pattern is an advanced extension of Retry Policy. If a service fails repeatedly, the circuit breaker stops sending requests to avoid wasting resources and return errors faster. Once the service recovers, the circuit breaker gradually allows requests to resume.

Fallback strategies allow integrations to provide reduced functionality if primary services are unavailable. If a customer data service is down, integration might use cached customer data instead of failing completely.

Monitoring and alerting on retry rates helps identify systemic issues. If retry rates spike, investigate whether the dependent service is having problems. Proactive alerts allow resolution before failures accumulate.

Idempotency requires attention to implementation detail. Request identifiers must be stable across retries. Deduplication logic on the receiving service must work correctly. Testing should validate that retries don’t create duplicate side effects. Distributed systems experts should review idempotency implementations before production.

A retry is a second request, with its own side effects

Integration owners often treat a retry setting as a resilience switch: turn it on, and failed calls stop being a problem. In practice a retry is a second request sent to a system that has just failed or slowed down, and it can produce effects that the first request did not. A timed-out payment confirmation may have succeeded on the far side. A record create may have been committed before the connection dropped. A notification may already have gone out. Before choosing a retry count or a delay, the integration owner needs to know what the downstream system does when it receives the same instruction twice.

That question is answered per action, not per integration. A single flow often mixes reads, state updates and creates, and each one carries a different risk if it runs more than once. Applying one policy to all of them is a common reason retries cause duplicate work.

Matching the failure to the response

The response to a failure should depend on what the failure tells you about the cause. The table below is a general practice frame. Your integration owner should confirm each row against the behavior of the specific external service, because some services return status codes that do not follow the usual meaning.

Failure seen	Likely cause	Retry it?	What to record before the next attempt
Connection timeout	The call may or may not have been processed	Only if the action is idempotent or carries a request identifier	The request identifier, the time, and whether a later read confirms the state
Rate limit response	Too many calls in a window	Yes, after the wait the response specifies	The wait applied and the calls remaining in the batch
Server error from the provider	Temporary fault on the provider side	Yes, with a limit and a delay that grows	The status, the response body if safe to store, and the attempt number
Authentication or permission refusal	Expired credential or changed role	No, retries will repeat the refusal	The credential alias used and the time the refusal began
Validation refusal on the data sent	The payload is wrong for the receiving system	No, the same payload will fail again	The field named in the response and the record it came from

The row that often causes the most trouble is the timeout. Teams treat a timeout as a failure, when it is really an unknown outcome. Without a request identifier that lets the receiving system recognize the repeat, a retry after a timeout is a guess about what happened.

Preparing an existing integration for retries

Adding retries to an integration that has been running without them requires more care than configuring a new one, because the existing behavior has been tolerated, and some duplicates may already have been absorbed silently. The following sequence keeps the change reviewable.

1. List every outbound REST message in the integration and classify each one as a read, a state change with a version check, or a create or irreversible action.
2. For each create or irreversible action, confirm whether the provider accepts an idempotency key or a client request identifier, and where that identifier will be stored.
3. Apply retries first to reads and version-checked updates, where a repeat is harmless, and observe the outcome for a period.
4. Only then apply retries to creates and irreversible actions, and only where a repeat can be detected and rejected on the receiving side.
5. Route the final failure to an error handler that creates a visible record, so exhausted retries are reviewed rather than dropped. The integration error handling approach covers how to shape those records.
6. Set an alert on the retry rate itself, not only on final failures, so a degrading provider is seen before it becomes an outage.

Retry settings can hide the problem they were meant to absorb

A retry policy that succeeds most of the time can conceal a provider that is becoming unreliable. Users stop complaining because the flow eventually completes, and the failures never reach a ticket. The first sign is often a slow flow rather than an error. Who receives those signals, and what they are expected to do, is covered in the piece on integration monitoring ownership. The integration owner should watch attempt counts per action, the time spent in retries, and the share of calls that needed more than one attempt. A sudden rise in any of these is a signal to investigate the provider, the network path or the credential, before the retry budget is quietly raised to compensate.

Retries also draw on the provider’s rate limit allowance. A flow that retries aggressively during an outage can consume the allowance that other integrations depend on, and turn one provider’s problem into a wider one. Spreading attempts over time, and stopping the policy once a provider is clearly unavailable, protects the rest of the estate.

When retries are the wrong answer

Retries are not the right tool in every case. A synchronous call that a user is waiting on should usually fail fast and offer a clear message, because a long retry sequence simply moves the wait to the user. A non-idempotent action with no way to detect a repeat should be redesigned, perhaps with a separate confirmation step, before any retry is enabled. And a provider that is known to be down for planned maintenance should not be retried at all. Holding the work in a queue and releasing it when the provider returns can be a cleaner pattern, and it is easier to explain to the people who own the business process.

The circuit breaker pattern addresses the case where a provider is failing repeatedly. It stops sending calls for a period, which is better than an ever-growing retry queue. Deciding whether an integration needs that protection is a design decision, and it should be recorded alongside the retry settings.

Questions integration owners ask about retries

Should retries be configured in the flow or in the provider’s own client?

Configure them where the integration owner can see and change them, and where the attempt count is logged. Hidden retries inside a client library can be difficult to audit, and the first person to notice duplicate effects may not know where they came from.

How do I tell whether a repeated request created a duplicate?

Search the receiving system for the request identifier, or for the natural key of the record, and compare counts with the number of attempts logged on the ServiceNow side. A mismatch means a duplicate was created or an attempt was never delivered, and both need investigating.

Do retries need to be the same for every environment?

Not necessarily. Test environments can be configured to fail fast so that problems surface quickly. Production should use the settings agreed for each action, and the difference should be documented so that a test pass is not mistaken for production evidence.

Who should be told when retries are exhausted?

The owner of the business process affected, not only the integration team. Exhausted retries usually mean a piece of work has stopped, and the people who depend on it need to know what was delayed and what they should do about it.