Troubleshooting Guide · SideGuy · 2026

Webhook Timeout Fixes

Stripe, Zapier, Twilio, and GitHub webhooks have different timeout windows and failure modes. Here's exactly what to do when your automation stops responding — by platform.

The 4 Real Reasons Webhooks Time Out

⏱

Slow endpoint response

Your receiving server takes longer than the platform's timeout window (usually 5–30 sec). The sender gives up and marks it failed.

🔁

Synchronous processing

You're doing heavy work (DB writes, API calls, email sends) inside the webhook handler before returning 200. Queue it instead.

🛡

Firewall or cold start

Serverless functions (Lambda, Vercel) have cold starts of 500ms–3s. Combined with processing time, this exceeds timeout limits.

📦

Payload too large

Large payloads take longer to parse and validate. Some platforms have payload size limits that cause silent drops.

Platform-by-Platform Fixes

Stripe Webhooks

Return 200 OK immediately on receipt — process the event asynchronously via a job queue (SQS, BullMQ, Inngest).
Stripe times out after 30 seconds. If no response: retries 3x over 24 hours with exponential backoff.
Use stripe.webhooks.constructEvent() before any DB work — invalid signature → return 400 fast.
Check Stripe Dashboard → Developers → Webhooks → Event log to see exact failure timestamps and retry attempts.
Enable "Stripe Radar" webhook delivery logs to see if the payload reached your server at all.

Zapier Webhooks

Zapier Catch Hooks have a 30 second response window but will queue retries for up to 15 minutes.
If your Zap step times out, split into two Zaps: Trigger Zap stores to a shared sheet → Worker Zap polls and processes.
Use "Delay For" action to break synchronous chains that build up latency.
Check Zap History → failed task details → "Response timed out" vs "Connection refused" — different root causes.
For high-volume: switch to Zapier's "Custom Webhook" action with async response (Zapier transfers payload to your endpoint and moves on).

Twilio Webhooks

Twilio voice webhooks: 15 second timeout for TwiML response. SMS webhooks: 15 seconds.
If your TwiML app is slow: use <Redirect> to point to a pre-cached static TwiML URL for instant response, then process async.
Twilio will retry failed webhooks up to 3 times with a 1-minute delay between retries.
Use Twilio's Debugger (console.twilio.com → Monitor → Errors) — error code 11200 = HTTP connection failure, 11205 = timeout.
For Studio flows: check "Flow Execution" logs → step durations. Add a "Send & Wait" widget pattern to prevent blocking.

GitHub Webhooks

GitHub expects a 10 second response. No 200 received → marks delivery as failed (no automatic retry).
Go to Repo → Settings → Webhooks → Recent Deliveries to see exact HTTP response codes and bodies.
Use GitHub Actions instead of webhook endpoints when possible — built-in retry, logging, and event buffering.
If using ngrok for local dev: keep tunnel alive, check ngrok dashboard for request/response pairs.
For enterprise: configure a proxy service (Hookdeck, Svix) between GitHub and your endpoint to handle retries and replay.

Timeout Window Comparison

Platform	Timeout Window	Auto-Retry	Retry Window	Log Location
Stripe	30 sec	Yes (3x)	24 hours	Dashboard → Webhooks
Zapier	30 sec	Yes (queued)	15 min	Zap History
Twilio Voice	15 sec	Yes (3x)	3 min	Console → Monitor
Twilio SMS	15 sec	Yes (3x)	3 min	Console → Monitor
GitHub	10 sec	No	Manual redeliver	Repo Settings → Webhooks
Shopify	5 sec	Yes (19x)	48 hours	Partners → Webhooks

Prevention Patterns That Actually Work

⚡

Respond first, process second

Return 200 immediately, push the payload to a queue (BullMQ, SQS, or even a simple DB table), and process asynchronously. This is the universal fix for every platform.

🔐

Validate signature before any work

Reject invalid signatures with 400 in under 5ms — don't waste timeout budget on unauthenticated requests. Use platform SDK helpers.

🌡

Keep serverless functions warm

Ping your endpoint every 5 minutes via a cron job to prevent cold starts eating into the response window. Vercel and Railway support always-on instances.

🔄

Use a webhook relay layer

Hookdeck, Svix, or Inngest sit between the sender and your app — they buffer, retry, and replay. Eliminates all timeout concerns on your end.

📊

Monitor with alerting

Set up webhook delivery monitoring. Stripe and Twilio send emails for repeated failures — make sure those go to an active inbox, not a dead alias.

Frequently Asked Questions

My webhook worked fine for months and suddenly started timing out — what changed?

Common culprits: a dependency your handler calls slowed down (external API, DB query, email service), a recent deploy added processing time, or your host started cold-starting. Add timing logs around each step to isolate where the latency appeared.

Can I test webhook behavior locally without deploying?

Yes — use ngrok, Cloudflare Tunnel, or localtunnel to expose your local port. Stripe and GitHub both have CLI tools (stripe listen, gh webhook) for forwarding events to localhost during development.

What happens if a webhook fires twice after a retry?

You need idempotency keys. Use the event ID (Stripe's event.id, etc.) as a unique key — store it in your DB and skip processing if already seen. Every major platform includes a unique event ID in the payload for this reason.

Zapier says my webhook succeeded but nothing happened in my app — why?

Zapier considers the webhook "succeeded" when your endpoint returns 200. If your app logic after that fails silently, Zapier won't know. Add internal logging to your handler and check error tracking (Sentry, Logflare) for silent failures.

I need to fix a webhook timeout today for a client — what's the fastest path?

Text PJ at +1 (858) 461-8054. Webhook diagnosis, fix deployment, and verification — usually within the hour. Bring the platform (Stripe/Zapier/Twilio), the error log screenshot, and your endpoint URL.

Webhook down right now?

Text PJ the platform + error message. Most webhook failures are diagnosed and fixed within one session.

💬 Text PJ Now 💙 Venmo PJ Zapier vs Make →