Webhooks feel magical when they work—fire an event in one app, and data lands instantly in another. But when a webhook fails, most solo operators assume Zapier will keep trying forever. It won’t.
Zapier retries failed webhook requests exactly three times, spread over roughly 90 minutes. If all three attempts fail, the Zap stops for that event. The data is lost unless you’ve built a safety net.
Here’s how the retry logic actually works, what causes failures in the first place, and how to design workflows that don’t lose data when a webhook times out.
How Zapier’s webhook retry schedule works
When a webhook request fails—usually because the receiving endpoint returns an HTTP error (4xx or 5xx) or times out after 30 seconds—Zapier queues a retry.
The retry schedule follows an exponential backoff pattern:
- First retry: 1 minute after the initial failure
- Second retry: 15 minutes after the first retry
- Third retry: 60 minutes after the second retry
Total window: roughly 76 minutes from the original attempt to the final retry. If the third attempt fails, Zapier marks the task as errored and moves on. You’ll see the error in your Zap history for 30 days, but the workflow won’t automatically resume.
This matters most for time-sensitive workflows—payment confirmations, signup triggers, or inventory updates. A 90-minute delay can break user experience, and a permanent failure can cost you a customer.
What causes webhook failures in the first place
Most webhook failures fall into three categories:
Timeout errors: The receiving endpoint takes longer than 30 seconds to respond. This happens when you’re chaining multiple API calls inside a webhook handler, or when your server is under load. Zapier won’t wait—it cuts the connection and logs a timeout.
5xx server errors: Your endpoint is down, restarting, or misconfigured. Database connection failures, missing environment variables, and rate-limit overruns all surface as 500-level responses. Zapier treats these as transient and retries.
4xx client errors: Your endpoint returns a 400, 401, or 404. These usually mean the request payload is malformed, authentication failed, or the endpoint URL changed. Zapier does not retry 4xx errors by default—it assumes the problem is permanent. If you’re seeing repeated 400 errors in your Zap history, the issue is in your webhook configuration, not transient server load.
How to handle webhook failures without losing data
The three-retry limit isn’t negotiable, but you can design around it.
Log every incoming webhook to a database or spreadsheet. Before your Zap does anything else, write the raw payload to Google Sheets, Airtable, or a Postgres table. If the rest of the workflow fails, you have a recoverable record. This adds one extra step to every Zap, but it’s cheaper than losing customer data.
Use a delay step before expensive API calls. If your webhook triggers a chain of slow API requests—checking inventory, generating a PDF, updating a CRM—add a 2–5 second delay before those steps. This keeps the initial webhook response under 30 seconds and prevents timeouts. The delay costs an extra Zapier task, but it’s worth it for mission-critical workflows.
Set up error notifications that you’ll actually see. Zapier’s built-in error emails are easy to ignore. Instead, send failed tasks to Slack, Discord, or a dedicated email address you check daily. Include the full payload in the message so you can manually retry if needed.
For critical workflows, run two Zaps in parallel. Send the same webhook to two different Zaps—one that processes immediately, and a second that waits 5 minutes before checking if the first succeeded. If the first Zap fails all three retries, the second acts as a fallback. This doubles your task usage for that workflow, but it’s the closest you’ll get to guaranteed delivery inside Zapier.
When to move off webhooks entirely
If you’re seeing regular webhook failures—more than 2–3% of total tasks—it’s a signal that webhooks aren’t the right transport for that workflow.
Switch to polling-based triggers (Zapier checks for new data every 1–15 minutes) or move the integration server-side. Polling is slower but far more reliable when endpoints are flaky or rate-limited. Server-side integrations give you full control over retry logic, logging, and failure handling—but they require more code.
Webhooks are fast and cheap when they work. Just don’t assume they’re bulletproof.
Want more workflow breakdowns like this? Subscribe to One Two Three Send and get one operator-focused breakdown every morning.