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.

transient-faultsbackoffresilience
The problem
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
1

Classify whether the failure is transient and whether repeating the operation is safe.

2

Wait using bounded backoff and jitter, then retry with the same correlation context.

3

Stop after the configured limit and hand the final failure to catch, compensation or dead-letter handling.

GateSift explanation

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 failure mode or capacity limit is this pattern intended to contain?
Which thresholds, deadlines, state or compensation data must remain durable?
How will operators know the pattern activated and whether recovery succeeded?
Common Azure implementations

Where you may see it

  • Logic Apps connector retry policies
  • Azure SDK retry configuration
  • APIM retry policy around a backend call
GateSift relevance

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.

Source 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.

Back to pattern library