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 or a manual retry, where a person decides. - Anything rate-limited: fewer retries, longer delays. Hammering a
429makes 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 — 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.