Event Delivery and Retry Logic

We are committed to reliable event delivery, even in the face of temporary network issues or service disruptions. Our system automatically retries failed webhook deliveries using exponential backoff with full jitter to maximize success without overwhelming your infrastructure.

When Retries Apply

Retries run only when the delivery fails with a non-2xx HTTP response or an HTTP request failure (e.g. connection errors, timeouts). Other errors are not retried.

Retry Behavior

We make up to 13 delivery attempts in total (1 initial attempt + 12 retries). The first retry happens after 1 minute; subsequent retries use exponential backoff (the maximum wait doubles with each retry), with full jitter so the actual wait before each retry is random between 0 and that maximum — helping spread load and prevent retry bursts.

Attempt	Max delay before retry (full jitter; actual delay is 0..max)
Initial	Immediate
Retry 1	1 min
Retry 2	2 min
Retry 3	4 min
Retry 4+	Doubles each time (8, 16, 32 … up to 2048 min)

After Retries Are Used Up

If all 13 attempts fail (non-2xx or HTTP failure), the delivery is marked failed. Any other type of error does not trigger retries. Delivery stops after 13 attempts or the 48-hour cut-off, whichever happens first (with backoff and jitter, the cut-off may be reached before all 13 attempts are used).

We use exponential backoff with full jitter to help ensure high delivery success without retry storms or system overloads.