> For the complete documentation index, see [llms.txt](https://api.dataloy.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://api.dataloy.com/dataloy-rest-api/webhook-notification-retry-rules.md).
# Webhook Notification Retry Rules
When a webhook notification fails to deliver, the system will automatically retry based on the following rules.
**Retry Schedule**
Retries use an exponential backoff strategy. The delay between each retry attempt increases as follows:
| |
|---|
| Attempt | Delay before retry |
| 1 | Immediate |
| 2 | 1 minute |
| 3 | 2 minutes |
| 4 | 5 minutes |
| 5 | 10 minutes |
| 6 | 15 minutes |
| 7 | 30 minutes |
| 8 | 1 hour |
| 9 | 6 hours |
| 10+ | 1 day |
**Maximum Attempts**
The maximum number of retry attempts is controlled by the system setting `System.webhookAttempts`. This applies to all subscriptions, including those with "Do Not Unsubscribe" enabled. When the maximum is reached, the individual notification stops retrying, but the subscription remains active for new notifications.
**Non-Retryable Errors**
Notifications that fail with the following HTTP status codes are never retried, as these indicate permanent errors that will not resolve on their own:
| |
|---|
| HTTP Status Code | Meaning |
| 400 | Bad Request |
| 401 | Unauthorized |
| 403 | Forbidden |
| 404 | Not Found |
| 405 | Method Not Allowed |
| 413 | Payload Too Large |
| 422 | Unprocessable Entity |
All other errors are retried, including:
* Connection timeouts (endpoint unreachable)
* Server errors (5xx)
* Rate limiting (429)
* Request timeouts (408)
* Conflicts (409)
**Circuit Breaker**
If a notification fails for a subscription during a retry cycle, all remaining pending notifications for that same subscription are skipped in that cycle. This prevents the system from repeatedly hitting a known failing endpoint. Skipped notifications are not counted as attempts — they will be picked up in the next cycle.
**HTTP Timeouts**
Webhook HTTP calls use configurable timeouts to prevent indefinite blocking:
| Setting | Description | Default |
| ---------- | -------------------------------------------------------- | ---------- |
| `CTIMEOUT` | Connect timeout — maximum time to establish a connection | 15 seconds |
| `RTIMEOUT` | Read timeout — maximum time to wait for a response | 60 seconds |
These can be configured via System Preferences.
**Overlap Protection**
If a retry cycle takes longer than the timer interval, the next cycle will not start until the current one finishes. This prevents multiple retry cycles from running simultaneously.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://api.dataloy.com/dataloy-rest-api/webhook-notification-retry-rules.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.