Quick Summary — TL;DR
A webhook timeout is the maximum duration a webhook provider will wait for your endpoint to respond before giving up and treating the delivery as failed. If your server doesn't return a 2xx status code within this window, the provider assumes the delivery didn't work and schedules a retry.
Webhook timeouts are the most common source of accidental duplicate deliveries. Here's the sequence:
The webhook was delivered and processed successfully. But because the response was too slow, the provider sent it again. If your handler isn't idempotent, you've now double-processed the event — double-charged the customer, sent two confirmation emails, or created duplicate records.
Each webhook provider sets its own timeout. There is no universal standard, and some providers don't publish their exact values. Here are the known ones:
| Provider | Timeout | Notes |
|---|---|---|
| Stripe | 20 seconds | First attempt; retries use longer windows |
| GitHub | 10 seconds | Marks as failed, retries up to 3 days |
| Shopify | 5 seconds | Aggressive; must respond fast |
| Twilio | 15 seconds | Configurable per webhook |
| SendGrid | 10 seconds | Event webhooks |
| Slack | 3 seconds | For interactive messages and slash commands |
| PayPal (IPN) | 20 seconds | Instant Payment Notification |
| Paddle | 15 seconds | Billing webhooks |
The range is 3 to 20 seconds for most providers. If your endpoint does anything non-trivial — a database query, an external API call, file processing — you can easily exceed these limits.
The single most important pattern: accept the webhook payload, store it (in a database, a queue, or a job queue), and return 200 OK immediately. Then process the payload asynchronously as a background job. Your response time drops to milliseconds, well within any provider's timeout.
Don't call external APIs, send emails, generate PDFs, or run heavy database queries inside the webhook handler. Every external call adds latency and increases the chance of hitting the timeout. The handler should do one thing: acknowledge receipt.
It's fine to do lightweight validation in the handler: verify the webhook signature, check that the event type is one you care about, parse the JSON. These operations take microseconds. Everything after validation goes into a queue.
A webhook timeout is a specific application of an HTTP timeout. The mechanics are identical — a client waiting for a server response — but the context is different:
With a regular HTTP timeout, you choose how long to wait. With a webhook timeout, someone else has already chosen for you. Your job is to respond within their window.
When a webhook delivery times out, most providers follow this sequence:
That last point is critical. Persistent timeouts don't just cause duplicate deliveries — they can get your webhook endpoint disabled, meaning you stop receiving events entirely until you fix the problem and re-enable the subscription. For more on building resilient webhook handlers, see webhook retry best practices.
A webhook timeout is the maximum time a webhook sender waits for your endpoint to respond with a success status code. If your server doesn't respond within this window, the sender treats the delivery as failed and schedules a retry. Timeout values are set by the provider and typically range from 5 to 30 seconds.
It varies by provider. Stripe waits 20 seconds, GitHub waits 10 seconds, Shopify waits 5 seconds, and Slack waits only 3 seconds for interactive messages. There's no industry standard, so you should design your webhook handler to respond within 3 seconds to be safe across all providers.
Return a 200 response immediately after receiving and validating the webhook. Don't process the payload in the request handler. Instead, queue it as a background job and process it asynchronously. This keeps your response time in the milliseconds range, well under any provider's timeout.
Webhook timeouts are closely related to HTTP timeouts but are controlled by the sender, not the receiver. When a timeout triggers a retry, the provider follows its retry policy with exponential backoff. To prevent duplicate processing from retried deliveries, always build webhook handlers that are idempotent and offload heavy work to background jobs.
Recuro handles cron scheduling, retries, alerts, and execution logs -- so you can focus on building your product.
No credit card required