Productivity app webhooks time out after 30 seconds—here’s the fix

If you’ve built any automation workflow that sends data between tools—Zapier to Airtable, Make to WordPress, a payment processor to your CRM—you’ve probably hit a webhook timeout without realising it.

The symptom: a task starts, the spinner hangs, and eventually you get a vague “request failed” error. The cause is almost always the same: your receiving endpoint took longer than 30 seconds to respond, and the sender gave up.

This isn’t a bug. It’s how most webhook systems are designed. And once you understand the constraint, you can route around it.

Why 30 seconds is the standard cutoff

Webhook senders—Zapier, Make, Stripe, ConvertKit, Memberful—don’t wait indefinitely for a response. They set a timeout, usually between 10 and 30 seconds, because:

• They’re firing hundreds of thousands of webhooks per minute across all users
• Open connections consume server resources
• If your endpoint is slow or broken, they don’t want to block their entire queue

Most platforms default to 30 seconds. Zapier and Make both cut off at that mark. Stripe allows 30 seconds for most events. Postmark’s inbound webhooks time out after 30 seconds. If your server hasn’t returned an HTTP 200 by then, the sender logs it as a failure and moves on.

Some platforms retry. Stripe retries failed webhooks for up to three days with exponential backoff. Zapier retries once, then marks the task as errored. Make retries based on your scenario settings. But the initial timeout is non-negotiable.

What actually takes longer than 30 seconds

Most webhook receivers respond in under a second. But a few operations consistently blow past the limit:

• Database writes that trigger cascading updates or recalculations
• Image processing or file uploads chained inside the webhook handler
• API calls to third-party services that are themselves slow (e.g., rendering a PDF, geocoding an address)
• WordPress actions that run on save_post and process hundreds of post meta fields

The worst offender: nesting multiple external API calls inside a single webhook receiver. Each call adds latency, and they stack. If you’re calling Clearbit for enrichment, then OpenAI for classification, then Airtable to log the result—all synchronously—you’ll hit 30 seconds easily.

The fix: acknowledge fast, process async

The pattern that works: your webhook endpoint should return HTTP 200 within a second or two, then hand off the real work to a background job.

Here’s the flow:

1. Webhook arrives at your server
2. Validate the payload and signature (takes milliseconds)
3. Write the raw payload to a queue, database row, or Redis key
4. Return 200 OK immediately
5. A separate worker process picks up the queued job and does the slow work

This decouples acknowledgment from execution. The sender sees success. Your app processes the work without time pressure. If the background job fails, you handle retries internally instead of relying on the sender’s retry logic.

In WordPress, that might mean using wp_schedule_single_event() to defer processing. In a Node app, it could be a Redis-backed Bull queue. In Python, Celery. The tool doesn’t matter—the principle does.

When you can’t control the receiver

Sometimes you’re triggering a webhook to a third-party service you don’t control—say, sending Zapier data that then hits another app’s API.

If that downstream app is slow, Zapier times out. You can’t fix their code. But you can add a buffer step:

• Send the webhook to a lightweight middleman endpoint you do control (a Cloudflare Worker, a simple Express server, a Make scenario that just writes to Airtable)
• That endpoint acknowledges instantly and queues the payload
• A separate process polls the queue and retries the slow destination with your own timeout and backoff logic

It’s extra infrastructure, but it keeps your automation chain from breaking every time a third-party API has a slow day.

Webhook timeouts aren’t going away. Thirty seconds is the ceiling. If your workflow assumes more time than that, it’ll fail intermittently—and intermittent failures are the hardest to debug. Acknowledge fast, process later, and your automations stay reliable even when the work is slow.

Want more workflow architecture breakdowns like this? Subscribe to One Two Three Send—we dig into the mechanics that most operator blogs skip.