Classify whether the failure is transient and whether repeating the operation is safe.
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.
How Retry works
A transient failure is retried within a bounded policy before control moves to the final failure path.
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.
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.
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.
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.