What is retried
In Inbound, automatic attempts belong to delivery to an individual Endpoint; in Outbound, they belong to an independent job. One recipient failing does not mean that others need a new delivery.
Success and failure
Success requires an HTTP 2xx response without an execution error. Network failure, timeout, read failure or another status means an unsuccessful attempt. Outbound response reading must complete correctly even when response body storage is off. Adal API response 202 confirms acceptance only.
A recipient can perform a business action and lose the connection before responding. A failed attempt therefore does not prove that the action did not happen.
Automatic attempts
CLI, Direct and independent Outbound jobs allow up to 10 HTTP attempts, including the first. The first starts without an additional retry delay when delivery can begin. The HTTP attempt timeout is 30 seconds including response reading. This does not promise to start or finish a job within 30 seconds of acceptance.
Schedule
Delays after successive failures are 1, 1, 2, 5, 10, 20, 20, 60 and 60 minutes. Success completes work for that recipient. Exhausting attempts completes it unsuccessfully. An Endpoint's delivery_interval_ms sets a delivery interval, not a custom retry schedule.
Actual retries can start later than the listed delay. Strict global order and fixed latency are not guaranteed.
Disconnected CLI
The Endpoint's deliver_backlog setting affects new backlog delivery. A job already stored by CLI resumes through its local journal. Reconnecting does not mean restarting every delivery. Preserve the journal directory; see Adal CLI.
Multiple recipients
Each Endpoint has its own attempts and progress. The aggregate Inbound status can be partial when recipient outcomes differ. Do not infer the entire request's outcome from one successful HTTP code.
Manual actions and replay
The current dashboard has no separate manual retry, delivery cancellation or replay actions. Sending the original event again or making another Outbound call is a separate action with possible new effects. Changing a Channel's settings is not a command to repeat a finished request either.
Two idempotency mechanisms
| Mechanism | What it does | What it does not do |
|---|---|---|
Inbound Endpoint idempotency_key flag |
CLI/Direct add Idempotency-Key containing request_id to attempts |
Force the recipient to deduplicate |
Outbound submission idempotency_key field |
Prevent repeated execution of a submission with the same user key during retention; a duplicate has duplicate_of |
Guarantee exactly-once HTTP effects or replace application protection |
When a submission response is uncertain, repeat the same Outbound request with the same key. Use a new key for a new logical operation. Once retention expires, the old key can be used again; it is not a permanent event ledger for your application. The field does not automatically set an identically named HTTP header at the recipient.
The recipient must implement its own key or provider-event-ID checks, deduplication, and atomic storage of processing results with business changes where possible.
Attempt history
Inspect the specific recipient, time, HTTP status and error in request details. Outbound provides a summary and execution details; failure to load details is not the same as HTTP delivery failure. Expired HTTP data does not mean a past action never happened.
Retention and usage
Retries do not extend the original retention deadline. Outbound counts the decoded request body once when execution starts, plus stored responses for each attempt. Do not assume retries are unconditionally free. See Storage and Traffic.
Troubleshooting
Check recipient reachability from the executor, timeout, handler response, CLI state and traffic balance. Do not create a new job instead of reading an accepted one before investigating its state. Do not change the key when retrying an uncertain submission.