Sign in
Start free7-day free trial
Live API contract
Webhooks

Webhook retries and delivery logs

Understand the ten-attempt retry schedule, terminal failures and what delivery history can tell your operator.

A receiver should return 2xx only after it has durably accepted the work. Other responses, network failures and timeouts cause retry behavior. Redirects are not followed, so register the final HTTPS destination directly.

Know the delivery window

Each attempt has a 10-second timeout. Retries start with a three-minute delay and use exponential backoff. There are up to 10 attempts in total, spanning approximately 25 hours and 33 minutes from the first attempt to the last scheduled retry.

Do not interpret a retry as a second business event. The delivery ID stays stable across attempts. Your receiver should deduplicate it even when the original acknowledgment failed.

Inspect the delivery history

List deliveries for the endpoint. The record shows queue state, attempt information, response status and the next scheduled attempt when applicable.

A null response code can mean no HTTP response was received. It is not the same as a 200 with an empty body. A null next-attempt time means there is no scheduled retry for that record.

The service uses queued, completed and failed delivery states. A shared schema can include a running value, but operators should not depend on seeing a separate running state during each attempt.

Recognize early terminal cases

An endpoint that has been disabled or deleted, or a destination that fails public-address checks, can end delivery before the normal retry budget is exhausted. Check endpoint configuration and destination reachability before assuming every failure is a temporary application timeout.

Pausing an endpoint is a configuration action. It is not a guarantee that all historical work will automatically be rescheduled later. Inspect affected deliveries and use supported replay when appropriate.

Recover with evidence

Fix the receiver or endpoint first, then replay a failed delivery. Keep the original failed record for diagnosis. A replay receives its own delivery ID and retry budget.

Use the test endpoint for a ping after a configuration change, and confirm your durable queue accepts it. Do not keep testing at a high rate when the underlying receiver cannot store work.