# Retries

> Set how many times a step tries again before it fails, and tell Hodoflow when repeating an external call is safe.

A step that fails can try again on its own before the failure becomes the run's
problem. That is set per step, on the **Policy** tab.

## Outcome

Transient failures — a timeout, a `503`, a brief network blip — stop turning
into failed runs, without repeating anything that should not be repeated.

## 1. Set the retry policy

Select a step, open the **Policy** tab, and set:

| Field | Range | Meaning |
|---|---|---|
| **Max Retries** | 0–5 | How many extra attempts the step gets before it fails. `0` means one attempt only. |
| **Retry Delay (seconds)** | 0–30 | How long to wait between attempts. |

Triggers have no Policy tab; retries are a property of work, not of what
started it.

**Checkpoint:** the Policy tab shows your values, and the toolbar shows
**Unsaved changes** until you save.

## 2. Decide whether repeating the call is safe

Retrying a read is free. Retrying a write can create two orders. Only you know
which one the endpoint is, so the retry count is where you say so.

A `GET` is safe to repeat by HTTP's own rules, and Hodoflow treats it that way.
A `POST`, `PUT`, `PATCH` or `DELETE` that is interrupted part-way is never
repeated on its own — it waits for a person, because nobody but you can check
the far end's records and say whether the first call landed.

## How many retries is right

- **Reads from a stable API:** 2–3 retries, 5–10 seconds apart.
- **Writes you know are safe to repeat** — replacing a record rather than adding
  one, or an endpoint that ignores a duplicate: the same.
- **Writes that create something:** `0`. Let it fail and handle it with an
  [on-error path](/help/workflows/error-and-compensation) or a manual retry,
  where a person decides.
- **Anything rate-limited:** fewer retries, longer delays. Hammering a `429`
  makes it last longer.

## What happens when the retries run out

The step fails and its **On error** path runs if one is attached. A successful
fault step can **Follow connections** to continue or **Fail workflow** after
completing its action. Without successful recovery, the run is recorded as
**failed**. From there it is a [recovery
decision](/help/run-troubleshoot/recover-a-failed-run) — and a retry from Monitor
keeps every step that already finished.

## Common problems

**Max Retries will not go above 5.** That is the ceiling. Higher counts turn a
failing dependency into a queue of stuck runs.

**The endpoint was called twice.** A retry repeated a call the endpoint counted
twice. Set **Max Retries** to `0` for that step, and handle the failure on an
on-error path instead.

**Retries made the failure slower to notice.** Max Retries multiplied by Retry
Delay is added to how long a failing run takes. Keep the product under the time
you are willing to wait for bad news.

## Next step

[Save, version, and activate](/help/workflows/save-version-activate).