Will your webhook handler time out?
Slack waits 3 s for your handler to answer, Shopify 5 s, GitHub 10 s. Paste the URL your sender posts to and see which of them would hang up. Free, no sign-up.
We send two small POST requests labelled as a test, the second right after the first, so a cold start shows up. If the URL triggers something (a Zap, an email), it runs with test data. We keep the host name, not the URL.
How long each sender waits
From each vendor's documentation, checked 2026-08-06. A sender that does not get a 2xx in time counts the delivery as failed, whatever your handler does afterwards.
| Sender | Waits | After a failed delivery |
|---|---|---|
| LINE | 2 s | Webhook redelivery, off by default (enable in the channel's Messaging API settings); count and interval undisclosed |
| Slack | 3 s | 3 retries: immediately, after 1 min, after 5 min |
| Discord | 3 sfor an interaction's first response; defer it (type 5) and reply later | Not published |
| Shopify | 5 s | 8 retries over 4 hours |
| Paddle | 5 s | Live: 60 attempts over 3 days, 20 in the first hour, 47 in the first day. Sandbox: 3 attempts over 15 min |
| HubSpot | 5 s | Up to 10 attempts spread over 24 hours |
| GitHub | 10 s | None. GitHub does not automatically redeliver failed deliveries |
| Twilio | 15 s | Configurable: rc 0 to 5, default 1. rp selects which failures qualify |
Why handlers got slow
Most bots and automations now call an LLM inside the webhook handler: summarise the message, draft the reply, sort the order. That takes seconds, sometimes tens of seconds, and the senders above do not wait. The usual fix is to answer 200 first and do the work from a background queue, which means running a queue.
AnyHook is that queue without the code. It answers the sender in about a second, then gives your handler up to 60 s on Free and retries if it fails. You change one URL; nothing else in your code moves. The full guide, with code for Next.js, Workers, Express and Python.