Webhook retry schedules, compared

Every provider answers four questions differently: how long do I get to respond, what counts as success, how many retries do I get, and when does it give up — or disable my endpoint entirely? The answers are scattered across eighteen sets of docs (and some of the numbers circulating in blog posts are stale). Here they are in one table, each row sourced from the provider's current documentation and cross-checked in our per-provider deep-dive guides.

Provider	Deadline	Success =	Retry schedule	Gives up / disables
GitHub	10 s	2xx	No automatic retries — manual Redeliver only	each delivery is one shot
Stripe	—	2xx	backoff for up to 3 days (live mode)	dropped after 3 days
Shopify	5 s	2xx	up to 8 retries over ~4 h, increasing intervals	subscription removed after continued failures within 24 h
WooCommerce	—	2xx, 301 or 302	No retries — each failure just counts	silently disabled after 5 consecutive failures
GitLab	10 s (GitLab.com)	not 4xx/5xx/timeout	No automatic retries — manual resend only	temp-disabled after 4 consecutive failures (1 min → 24 h backoff); permanent at 40 (17.11+)
Bitbucket	10 s	non-5xx	up to 2 auto-resends, on 5xx only (X-Attempt-Number)	dropped after attempt 3
Slack Events	3 s	2xx	3 retries: ~immediately, +1 min, +5 min (x-slack-retry-num/-reason)	app risks temporary disable below 5% success (apps under 1,000 events/h exempt)
Zoom	3 s	200–299	2 retries: +20 min, then +60 min — 3xx/4xx never retried	dropped after retry 2
Meta (WhatsApp/Messenger/IG)	—	200	exponential backoff, up to 7 days	dropped — no dead-letter queue, no replay
Twitch EventSub	—	2xx	at-least-once; schedule undisclosed (Twitch-Eventsub-Message-Retry counts attempts)	subscription revoked with notification_failures_exceeded
Discord Interactions	synchronous	valid response	No retries — it's a request/response API	endpoint removed on sustained failures
Mailgun	—	200 (406 = permanent reject)	+5 m, +10 m, +15 m, +1 h, +2 h, +4 h (~8 h total)	dropped after; delivery-notification hooks aren't retried at all
Square	—	2xx	exponential backoff up to 24 h (1 min, 2 min, …; square-retry-number/-reason)	event discarded after 24 h
HubSpot	5 s	2xx	up to 10 retries over 24 h, varying delays (retried on connection failure, timeout, any 4xx/5xx)	dropped after 24 h
Svix (Clerk, Resend, Railway…)	—	2xx	immediately, +5 s, +5 m, +30 m, +2 h, +5 h, +10 h, +10 h (same svix-id every attempt)	marked failed after the schedule; dashboard replay
AWS SNS (HTTP/S)	—	2xx	default numRetries: 3, ~20 s targets — only 5xx and 429 are retried	any other non-2xx discarded immediately; retry window hard-capped at 3,600 s
Notion	—	acknowledged (2xx)	up to 8 retries, exponential backoff — final attempt ~24 h after the trigger	aims for at-most-once delivery: after the schedule the event is gone; re-fetch state via the API
PayPal	—	200	up to 25 retries over 3 days	marked Failed; manual resend from the dashboard
Paddle	5 s	200 only, within 5 s (docs: any other status is retried — even 201)	sandbox: 3 within 15 min; live: 60 within 3 days, exponential — 20 in the first hour (same event_id)	marked failed; manual replay via dashboard/API for 90 days
Zendesk	12 s	2xx	only 409 is retried (3×); 429/503 only with retry-after < 60 s; timeouts 5×; other 4xx/5xx dropped	never deactivated — but a circuit breaker (~70% errors in 5 min) can drop events entirely
Adyen	10 s	2xx (status code alone; the legacy [accepted] body is no longer required)	9 s, 18 s, 27 s, then a per-endpoint queue at 2 m/5 m/10 m/15 m/30 m/1 h/2 h/4 h/8 h for up to 30 days	queue is sequential — one stuck event delays everything behind it; alerts after 5 attempts and at 7 days; manual Retry/Ignore in the Customer Area
Patreon	not documented	successful response	no public schedule — failed events are stored and queued; docs say later retries deliver all accumulated missed events once your server responds again, and the portal has a manual "send queued messages" button	repeated failures flip the webhook to paused: true (see num_consecutive_times_failed on the API webhook object); deliveries stop until you PATCH paused: "false", which also flushes the queue
Asana	10 s	2xx	exponential backoff within a 24 h window (at-most-once, no replay)	no success for 24 h (8-hourly heartbeats included) = webhook silently deleted; 410 = delete on purpose
Trello	—	2xx (410 deletes the webhook)	3 retries: +30 s, +60 s, +120 s — then the delivery is gone (no replay API)	auto-disable requires both 30 days of consecutive failures and 1,000+ failures (any success resets); token revocation kills the webhook silently at any time
Webflow	“swift response” required (no documented number)	exactly 200 — redirects count as failures, as do SSL problems and slow responses	3 retries at 10-minute intervals — then the delivery is gone (no replay)	repeated failure = webhook deactivated with an email; reactivation goes through Webflow support, not a dashboard toggle
Strava	2 s	200 within 2 s	retried up to a total of 3 attempts (intervals undisclosed)	event dropped after attempt 3 — no replay; subscription itself stays active (validation-time failure is a different beast: the subscription never gets created)

Patterns worth noticing

• Three big names don't retry at all. GitHub, GitLab and WooCommerce deliver exactly once — if your endpoint hiccups, that event is gone until a human clicks Redeliver (or forever, for WooCommerce). Retry logic you assumed exists… may not.
• Auto-disable is the silent killer. WooCommerce (5 failures), GitLab (4 → temporary, 40 → permanent), Shopify (removal within 24 h of persistent failure), Slack (<5% success rate), Discord and Twitch (revocation) will all stop sending entirely — most of them without telling you. A dead endpoint for one afternoon can mean a deleted subscription.
• Deadlines are shorter than your handler thinks. Slack and Zoom give you 3 seconds; Shopify, Paddle and HubSpot 5; GitHub, GitLab and Bitbucket 10. And a timeout usually counts as a failure that feeds the retry/disable counters — the universal fix is ack fast, process async.
• Retries guarantee duplicates. Every provider that retries will eventually deliver an event your handler already processed (the classic case: you finished the work but responded in 5.1 s). Dedupe keys the providers give you: svix-id, square-retry-number, X-Attempt-Number (Bitbucket), x-slack-retry-num, Twitch-Eventsub-Message-Id, Paddle's event_id.
• 4xx is not "safe to return". Zoom never retries a 4xx, SNS discards on any non-2xx except 429/5xx — but Meta, HubSpot and PayPal retry 4xx for days. Returning 404/422 on unknown event types can mean either silently losing events or 3 days of pointless redeliveries, depending on the sender.

Don't trust the table — verify it

Numbers like these rot (Shopify's schedule was "19 retries over 48 hours" for years; the current docs say 8 over ~4 hours — plenty of blog posts still quote the old figure). The schedule your endpoint actually experiences is easy to observe directly: point the provider at a capture bin, set the bin's response status to 500, trigger one event, and read the retry timestamps off the dashboard. The step-by-step retry-testing guide covers forcing timeouts and 4xx-vs-5xx behaviour too.

← All guides · Signature debugger · Payload examples · Docs · Hookden vs webhook.site