Classify whether the failure is transient and whether repeating the operation is safe.
Reliability & Delivery · Fault Handling
Retry
Repeat an operation after a controlled delay when the failure is likely to be transient. Bound the number of attempts, add backoff and jitter, and combine retries with idempotency and an explicit final failure path.
How should an integration recover when a remote operation fails for a short-lived reason?GateSift summary based on Microsoft Azure Architecture Center guidance. The wording, visualization, Azure mapping and analyzer context are original GateSift material.
Original GateSift visualization
How Retry works
A transient failure is retried within a bounded policy before control moves to the final failure path.
Failed operation
Backoff and retry
Recovered
Final failure
Wait using bounded backoff and jitter, then retry with the same correlation context.
Stop after the configured limit and hand the final failure to catch, compensation or dead-letter handling.
Curated GateSift guidance
When this pattern is a good fit — and when it is not
Use retry only for failures that are plausibly transient and only when repeating the protected operation is safe or made idempotent.
- The dependency can fail temporarily because of throttling, network interruption or short-lived service unavailability.
- The operation can be repeated without duplicating an irreversible side effect.
- A bounded delay is acceptable to the caller or asynchronous processing deadline.
- The error is deterministic, such as invalid input, authorization failure or a missing required resource.
- Repeating the operation can duplicate a payment, order, notification or other non-idempotent side effect.
- The dependency is broadly unhealthy and repeated calls would amplify the outage; consider circuit breaking or queueing instead.
Retry stormHigh impact
Many clients retrying together can increase load on an already degraded dependency.
Duplicate side effectsHigh impact
A timeout does not prove the remote operation failed; retry can repeat work that actually completed.
Hidden latencyReview
Multiple attempts can exceed upstream timeouts or message-lock windows even when every individual timeout looks reasonable.
- Use bounded exponential backoff and jitter where the runtime supports it rather than fixed immediate retries.
- Align retry count and delay with APIM request timeouts, Logic App action deadlines and Service Bus lock/processing constraints.
- After the retry budget is exhausted, hand control to an explicit catch, dead-letter or compensation path instead of retrying indefinitely.
What this pattern helps you decide
Repeat an operation after a controlled delay when the failure is likely to be transient. Bound the number of attempts, add backoff and jitter, and combine retries with idempotency and an explicit final failure path.
Which exact failure codes or conditions are transient enough to retry?
Is the protected operation idempotent when the first attempt may have completed remotely?
Does the complete retry budget fit inside upstream timeouts and processing locks?
Where you may see it
- Logic Apps connector retry policies
- Azure SDK retry configuration
- APIM retry policy around a backend call
How the analyzers can surface it
- Logic App retry policies and missing timeout handling
- APIM retry statements and retry count or interval configuration
- Repeated delivery combined with idempotency safeguards
Pattern detection is contextual. GateSift should present these as architectural signals, not claim a pattern is implemented solely because one policy statement or adapter exists.
GateSift support
Where GateSift can surface this pattern
Detection means the source contains direct structural evidence. Signal means the analyzer sees compatible structure but still needs architectural context.
Detection supportedAPIM Policy Analyzer
Detects visible APIM retry blocks and whether backend calls are protected by them.
Open toolDetection supportedLogic App Workflow Helper
Detects explicit retry policies on HTTP and managed-connector actions.
Open toolDetection supportedBizTalk Binding Visualizer
Detects configured transport retries on static remote send ports.
Open toolSource guidance and attribution
This page links to Microsoft Azure Architecture Center for the source architecture guidance. GateSift summaries, diagrams, Azure examples and analyzer signals are original. No endorsement by Microsoft is implied.