01Lifecycle and classification
Delivery lifecycle: PENDING (awaiting its attempt) then DELIVERED (succeeded — terminal) or DEAD (exhausted its attempts — terminal). Each attempt has a 10-second deadline, and any 2xx response settles it as successful. Anything else counts as a failed attempt and is retried automatically: a non-2xx response (3xx after the redirect chain counts too), a timeout, a connection error, a rejected URL or host, or an oversized response.
The wait between attempts is exponential: after the n-th failed attempt, the wait is 60 × 2^(n-1) seconds capped at 7200 seconds (2 hours), multiplied by a random factor between 0.85 and 1.15 (±15% jitter).
| After failed attempt | Approximate wait |
|---|---|
| First | ~60 seconds |
| Second | ~120 seconds |
| Third | ~240 seconds |
| Fourth | ~480 seconds |
| Fifth and beyond | 960 seconds then doubling up to the 7200-second cap — if the attempt limit is above 5 |
The maximum number of attempts is 5 by default (the storage model allows 1–10; deliveries are created with the default). After the final failure the delivery is marked DEAD — terminal and visible in the 30-day delivery history.
02Manual replay
- Replaying an old event to an active endpoint (Replay) and retrying a DEAD delivery (Retry) — both follow the same rules.
- A 14-day window from event creation — older is rejected.
- A shared budget of 1000 replays per hour per store (covering both) — exceeding it returns 429.
- A replay creates a brand-new REPLAY delivery with a new id and a copy of the payload — original rows are never touched.
COMPLETE YOUR INTEGRATION