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	2xx within 5 s	sandbox: 3 over ~15 min; live: 60 over ~3 days, exponential (same event_id)	dropped after the schedule

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