Who this is for. Integration engineers whose jobs send data to another system. After this page you can say, for any request your integration makes, how often it is retried, when it becomes a dead letter, and who is told.
What retries by itself
Less than it looks:
- An HTTP Request action can retry a failed request up to ten times; the default is none. It waits 0.3 seconds before the first retry and doubles the wait each time: 0.3, 0.6, 1.2, 2.4 seconds and so on, about five minutes of waiting in all for ten. The wait happens inside the running job. Its timeout is between 10 and 120 seconds, 60 when unset, and the status codes it accepts are
2**unless you set others (The default that surprises people). - Every attempt is recorded in the run's output in Batch Logs: the method, URL, headers and body sent, and the response with its headers. That is where you read why a request failed.
- A parallel loop can retry a failed element up to five times, if it is set to.
- Nothing else retries. A run that fails stays failed until someone re-runs it, and a re-run starts again from the first action (The job queue, and what a half-failed job leaves). Build your own alert into the policy below.
Those retries cover a dropped connection or a busy second. They do not cover the other system being down for an hour, which is the failure that matters.
A retry policy with concrete intervals
This policy is built from the pieces above; the worked example implements it.
| Stage | When | How |
|---|---|---|
| Immediate | 0.3, 0.6 and 1.2 s after the failure | The HTTP Request action's own retries, set to 3 |
| Scheduled | Every 15 minutes for 24 hours | A scheduled job selects the work that did not complete (not the runs that failed) and sends it again |
| Dead letter | After 24 hours | The item stays in the scheduled selection, and a daily report to a shared inbox lists it until someone resolves it |
| Give up | After 7 days | Out of the automatic retry, still on the daily report |
The scheduled stage is what turns a failure into a delay. It does not re-run failed runs: it selects, from the data, the work that has not completed (an order not yet marked as handed off, a contact without the other system's id) and sends it again. A failure at any step, for any reason, therefore ends up in the next selection, and work that has completed never does.
Retry only what is safe to send twice
Every request carries an id the other system de-duplicates on, and a "this already exists" answer (usually 409) is accepted as success, by adding it to the action's accepted status codes: 2**,409. Both are the integration's own responsibility, not something the platform does (Idempotency and replay). Retry timeouts, 429 and 5xx answers; a 400 or 422 fails the same way every time and belongs on the report at once, which is why the scheduled stage re-sends from the data rather than blindly re-running runs.
Dead letters, and who is told
A dead letter is a piece of work that has exhausted its retries. In this policy it is not deleted or moved anywhere: it stays in the scheduled selection, and the daily report lists it until someone resolves it. After seven days it leaves the automatic retry and stays on the report.
Who is told. A shared inbox or channel that a named team reads, never one person's address. Write which one in the job's Description, so the next developer knows who watches it.