Webhook Timeout

Overview

Webhook Timeout is a webhook delivery outcome where the receiver does not complete the expected connection or response within the sender’s time limit. It is used to bound delivery resources and trigger a controlled retry or failure path. It differs from a webhook failure caused by an explicit rejection, because the sender may not know whether timed-out processing completed.

A typical implementation works as follows: The sender opens a connection and waits for the configured stages; if the deadline passes, it closes the attempt and applies retry policy.

Common risks include the receiver may complete after the sender gives up and causing an uncertain outcome and duplicate work on the next attempt. Recovery for Webhook Timeout should combine replay controls with an authoritative status check rather than trusting delivery history alone.

Core controls require teams to acknowledge quickly after durable receipt, move heavy work to a queue, use idempotency, tune deadlines, and record late completion. For Webhook Timeout, the event identifier, signature result, delivery attempt, and resulting business state should remain connected throughout processing.

Operational evidence should include event ID, timeout stage, configured deadline, elapsed time, receiver state, retry number, and final disposition. Webhook Timeout should be documented alongside Webhook Failure, Callback Response, and Retry Policy.

A receiver should treat transport acknowledgement and successful downstream processing as separate states for Webhook Timeout. The Webhook Timeout path should preserve ordering and duplicate evidence so delayed delivery cannot silently overwrite a newer state. A Webhook Timeout handler should acknowledge only after durable receipt when the provider’s retry contract depends on the response.