Use this when

An action can fail temporarily, a system is briefly unavailable, a request times out, and a retry would often succeed.

The pattern

TRY the action
   ↓
FAILED?
  ├── Yes, and under the limit → wait, then retry
  ├── Yes, and limit reached   → stop, hand off to a person
  └── No                        → done

The workflow retries a failed action a set number of times, then gives up gracefully and escalates rather than retrying endlessly.

Why it works

Many failures are temporary. A short retry often succeeds where an immediate give-up would have created unnecessary work. But retrying forever is dangerous: it can hide a real problem, hammer a struggling system, or loop silently. A limit gives you the benefit of retries without the risk of an infinite loop. It is a standard part of failure design.

How to apply it

  1. Decide which actions are safe to retry. Reading is usually safe; repeating a write may not be.
  2. Set a sensible limit, and a short wait between attempts.
  3. After the limit, stop and hand off to a human fallback or a safe default.
  4. Log the failures and the retries, so a pattern of failures is visible.

Beware duplicate actions

Retrying a write is risky: if the first attempt actually succeeded but the response was lost, a retry can create a duplicate, a second order, a second email. Only retry actions that are safe to repeat, or make them safe to repeat, so the same action twice has the same effect as once.

What this does not solve

Retrying handles temporary failures; it does not fix a persistent one. If an action keeps failing, retries only delay the escalation. Use the limit and the failure log to notice when retries are masking a real, recurring problem.