# Webhook retries The webhook dispatcher retries a failed delivery on your endpoint's behalf. Every attempt is logged in the developer dashboard. ## Delivery budget - **Timeout.** Each attempt gives your endpoint up to 20 seconds to return a `2XX` response. - **Retries.** A non-`2XX`, timeout, or connection error is retried with a scheduled backoff. The dispatcher makes up to **10 attempts per delivery** within a window of up to **3 days**. - **Schedule.** The inter-attempt delays are configured in `workers/developer-platform-webhook-dispatcher/src/retry.ts`. The base delays are 1 minute, 5 minutes, 30 minutes, 2 hours, 5 hours, 10 hours, 14 hours, 16 hours 40 minutes, and 16 hours 40 minutes. Carebit applies up to 10% positive or negative jitter to each delay. The cumulative retry window remains under 3 days. - **At-least-once.** Network partitions can cause the same event to be delivered twice. Dedupe on `Carebit-Event-Id` (equivalent to `id` in the JSON body). - **Order.** Events are not delivered in a strict order per endpoint. Design handlers to be commutative, or reconcile against the resource state via the public API. - **Redirects.** The dispatcher does not follow HTTP redirects. Respond `2XX` from the exact URL configured on the endpoint. A `3XX` response counts as a failure. - **Auto-disable.** If an endpoint fails continuously for 3 days, Carebit pauses it and emails the project's Admin and Developer StaffMembers. Re-enable it from the developer dashboard after fixing the receiver. The failure streak clears the first time any attempt succeeds. These schedule numbers describe how Carebit dispatches. They are independent of your own retry policy against the outbound API (see [Idempotency and retries](/guides/idempotency-and-retries)). ## Manual resend Every exhausted delivery in the developer dashboard has a **Resend** button. Resend reuses the existing `Carebit-Delivery-Id` and adds exactly one attempt to that delivery. If that attempt fails, resend does not queue further retries and cannot be triggered again. Use resend to replay a specific past event after fixing the receiver, not to escalate retries. ## Test events The **Send test event** action in the dashboard sends a fabricated payload with `livemode: false`. Fixture IDs are deterministic UUIDs for Organizations that do not exist, and payloads use `example.invalid` addresses and clearly fake names. Test deliveries do not affect the failure streak. ## Log retention Every attempt is logged with the request headers, the raw body, the response status, the response body, and the outcome. Logs are retained for 30 days and are searchable in the developer dashboard by event type, endpoint, delivery id, and outcome.