Retry Strategy
To manage retries, we use an exponential backoff strategy. This increases the interval between retry attempts, allowing for a lessened server load and recovery time. This strategy is essential for handling temporary outages and other issues.
Retry Logic Details
- Initial Delay: Starts after 10 seconds of first failed attempt.
- Maximum Attempts: There will be up to 7 attempts in total.
- Backoff Calculation: Delay duration doubles with each subsequent attempt.
Retry Intervals Overview
| Attempt | Delay | Notes |
|---|---|---|
| 1 | 10 sec | |
| 2 | 20 sec | |
| 3 | 40 sec | |
| 4 | 80 sec | (1 min 20 sec) |
| 5 | 160 sec | (2 min 40 sec) |
| 6 | 320 sec | (5 min 20 sec) |
| 7 | 640 sec | (10 min 40 sec) |
After 7 attempts, the system stops retrying and considers the job failed. This retry count is dynamic and depends on webhook delivery success rate. Lowest retry count is 3, and the maximum is 7.
Job Failure and Deactivation Logic
A failed delivery is considered after all retry attempts are exhausted.
Webhook will be deactivated after 7 days of continuous failure. This is to prevent further attempts to deliver events to a non-responsive endpoint.
All delivery attempts are logged in the system, allowing you to track the status of each webhook event and re-deliver them if necessary.
Skipping retries
Webhooks retries are skipped on hard errors immediately, such as an HTTP 404, 410 error response