Retries & Delivery

Zuse Bifrost treats webhook delivery as at-least-once. If your endpoint is unreachable or responds non-2xx, the worker retries on the schedule below.

Retry scheduleCopy Anchor Link

Every delivery gets up to 8 attempts. The back-off between them is exponential:

Cumulatively, an endpoint has about four days of retries before Zuse Bifrost gives up. That covers every reasonable outage short of a permanent DNS change.

Dead-letteringCopy Anchor Link

After the eighth failure the delivery row is marked dead and the worker stops retrying automatically. Dead rows stay in the log so the team can inspect them in Settings → Webhooks → Deliveries and either retry by hand or pull the payload out for debugging. Dead rows are kept until somebody prunes them; delivered rows are pruned after 90 days.

The Retry action on a delivery re-queues a failed or dead row as pending, resetting its attempts to zero and clearing the recorded response, so the log shows the replay's own outcome. A pending or delivered row cannot be retried: resetting a pending row would race the worker already holding it, and resetting a delivered row would post the event to your server twice.

Auto-disable on sustained failureCopy Anchor Link

If an endpoint reaches 20 consecutive failures (across many events, not just 20 retries of one), Zuse Bifrost switches it off automatically and records when. This stops the worker hammering a permanently broken URL.

When the endpoint is resumed, in Settings → Webhooks or through the API, its consecutive-failure streak resets and fresh deliveries flow. Pausing an endpoint yourself has the same effect on deliveries: a delivery picked up for a paused endpoint is dead-lettered without being posted, and can be replayed once the endpoint is resumed.

Response-time budgetCopy Anchor Link

Your handler has 30 seconds per delivery. Anything longer counts as a failure and triggers the next retry. If the work itself takes longer, the canonical pattern is:

1. Verify the signature.
2. Enqueue your own background job with the payload.
3. Respond 200 OK immediately.

What counts as a failureCopy Anchor Link

• Any non-2xx HTTP status.
• Connection timeouts (30 seconds).
• TLS handshake failures.
• DNS resolution failures.

5xx counts and retries. 4xx counts and retries too: even though 4xx usually means your code rejected the payload, verification can be brittle during a secret rotation and a retry usually recovers. If you deliberately want to drop an event, respond 200 and ignore it on your side.

Replaying dead deliveries in bulkCopy Anchor Link

The deliveries page has a Replay dead action that re-queues every dead row whose dead-letter time is within the last 24 hours, up to 500 rows per click. Use it after you have deployed a fix.

RelatedCopy Anchor Link

• Signature verification
• Security model
• Testing & debugging