ERR_WEBHOOK_TIMEOUT on Zapier: Webhook timeout — Zapier reports "Your app returned a timeout error" or the Zap step shows status Errored with no response body. Root cause: Zapier's webhook step waits a maximum of 30 seconds for a response from your endpoint. If your server takes longer than 30 seconds to process the request and return a 2xx HTTP status, Zapier marks the task as errored. This is not a Zapier bug — it is a hard platform constraint. Common causes: your endpoint is doing synchronous database writes or external API calls before responding, your server is cold-starting (serverless functions), or your endpoint is under load and queuing requests. Step 1: Confirm the timeout is on your endpoint, not Zapier. In Zap History, click the errored task and expand the webhook step. If the error says "Timeout" and the duration shows ~30000ms, your endpoint is the bottleneck. If the duration is under 5 seconds, the issue is likely a DNS or TLS handshake failure — check that your domain resolves correctly and your SSL certificate is valid. Step 2: Implement the respond-then-process pattern. The correct fix for slow endpoints is to return HTTP 200 immediately, then process the payload asynchronously. In Node.js: res.status(200).json({ received: true }); then call your processing function without await. In Python/Flask: use threading.Thread(target=process, args=(data,)).start() before returning. This keeps your endpoint under Zapier's 30-second limit regardless of how long processing takes. Step 3: Warm up serverless functions. If your endpoint is a serverless function (AWS Lambda, Vercel, Cloudflare Workers), cold starts can add 2–15 seconds to the first request. Set a minimum instance count of 1 in your function configuration to keep it warm. Alternatively, use a scheduled ping every 5 minutes to prevent cold starts. Step 4: Add a queue between Zapier and your processing logic. For high-volume or slow workloads, place a message queue (AWS SQS, Google Pub/Sub, or a simple Redis queue) between your webhook endpoint and your processing code. The endpoint writes to the queue and returns 200 immediately. A separate worker consumes the queue at its own pace. This is the production-grade solution. Step 5: Use Zapier's built-in retry logic as a safety net. Zapier automatically retries errored tasks up to 3 times over 24 hours. If your endpoint is intermittently slow (e.g., during peak load), you can rely on retries for occasional failures. Go to Zap History → find the errored task → click Replay to manually retry immediately.