How Long Meta Retries a Failed WhatsApp Webhook

How long does Meta retry a failed WhatsApp webhook?

For WhatsApp, Meta's own figure is up to seven days. Both of Meta's WhatsApp webhook pages state, in identical words:

"If a webhook request to your endpoint receives an HTTP status code other than 200, or if the webhook cannot be delivered for another reason, Meta retries delivery with decreasing frequency until the request succeeds, for up to 7 days." (Meta — WhatsApp webhooks overview)

So a server that goes down on Friday night and comes back on Monday morning has lost nothing yet: every delivery that failed over the weekend is still inside the window, and Meta will backfill it. What the weekend does cost you is duplicates, ordering, and a hard deadline — the three things the rest of this piece is about.

This is a different problem from the two webhook failures this blog has already covered. If Meta never validated your callback URL in the first place, that is the verify-token handshake failing; if the URL is verified and receives nothing even while your server is healthy, that is a subscription or configuration gap. This post assumes the integration worked, then your endpoint stopped answering — a deploy gone wrong, a certificate expiring, a box falling over — and asks what Meta does about it.

• How long does Meta retry a failed WhatsApp webhook?
• Why do Meta's own pages give two different windows?
• What counts as a failed webhook delivery?
• Should you answer 200 before processing finishes?
• Does Meta disable a webhook when its success rate drops?
• Why does the same message arrive twice after recovery?
• Do retried deliveries arrive in the right order?
• What is gone once the retry window closes?
• How do you reconcile after the endpoint comes back?
• How does WabaCRM handle retries on its own outgoing webhooks?

Why do Meta's own pages give two different windows?

Because Meta's documentation disagrees with itself, and has for as long as anyone has been checking. The generic Graph API webhooks page — the one that covers webhooks for every Graph product, Pages and Instagram included — says:

"If any update sent to your server fails, we will retry immediately, then try a few more times with decreasing frequency over the next 36 hours." (Meta — Graph API webhooks, getting started)

and, on the same page:

"Unacknowledged responses will be dropped after 36 hours." (Meta — Graph API webhooks, getting started)

The WhatsApp-specific pages say seven days. Not one WhatsApp page against one generic page, either: the seven-day sentence quoted at the top of this article appears word for word on both the WhatsApp webhooks overview in Meta's new documentation tree and the older Cloud API set-up-webhooks guide. Nothing on any of the three pages acknowledges the other figure, and nothing reconciles them.

For WhatsApp traffic the sensible reading is that the product pages govern: they are the specific documentation for the exact webhooks you are receiving, they agree with each other verbatim, and the generic page reads like an older default that WhatsApp's infrastructure overrides. But that is a reading, not something Meta states, so the honest engineering position is to split the difference by role: treat 36 hours as the deadline for getting your endpoint repaired, and seven days as the horizon for deduplication and reconciliation. Built that way, you are safe whichever figure Meta's systems actually apply to your account.

What counts as a failed webhook delivery?

The WhatsApp sentence defines it in two halves: an "HTTP status code other than 200", or a webhook that "cannot be delivered for another reason". The second half is the ordinary catalogue of a dead server — DNS that stops resolving, a connection refused, a TLS certificate that expired, a request that hangs until Meta gives up waiting.

The first half is stricter than most people assume. The sentence says other than 200 — not "outside the 2xx range". A 201, a 204, or a redirect to a page that eventually returns 200 are all, by the letter of Meta's own text, failed deliveries. Whether Meta's infrastructure is in practice more forgiving is not documented, so return a literal 200 and nothing else. A signature check that fails is a special case with its own trade-offs — what your endpoint should do when X-Hub-Signature-256 does not match covers why answering 200 and discarding is usually better than answering 403 and inviting a retry of the same mismatch.

Should you answer 200 before processing finishes?

Yes. The generic Graph page's instruction is that your endpoint "should respond to all Event Notifications with 200 OK HTTPS" (Meta — Graph API webhooks, getting started), and none of the three pages publishes the timeout Meta applies while waiting for that response. That absence cuts against you, not for you: an unpublished deadline is one you cannot budget for, so the only safe response time is "immediately".

The pattern that survives is acknowledge-then-process. Persist the raw request body, return 200, and hand parsing, media downloads and database writes to a queue. A handler that does the work inline is betting its response time against an undocumented number on every request, and it fails in the worst possible way: under load, the work completes but the response arrives late, Meta counts the delivery failed, and the retry re-runs work that already happened. That is not a hypothetical — it is why the deduplication section below is not optional.

Does Meta disable a webhook when its success rate drops?

A claim circulates — in webhook-platform blog posts, in engineering runbooks, in at least one conference talk — that Meta throttles or disables a webhook subscription once its delivery success rate falls below 95%. That figure appears on no Meta page this article's research could find. It is not on the WhatsApp webhooks overview, not on the Cloud API set-up-webhooks guide, and not on the generic Graph getting-started page, all three read in full on 25 September 2026. The overview page's failure-handling section describes exactly two consequences of failed deliveries: retries, and duplicates. No percentage, no throttle, no disablement.

Trace the 95% claim back and the chain ends in third-party webhook-infrastructure vendors citing each other, not Meta. That does not prove Meta's systems never degrade a chronically failing endpoint — an undocumented behaviour can still exist — but it does mean you cannot plan around the figure, and you should be suspicious of any dashboard or alert threshold that presents it as Meta policy. The documented cost of sustained failure is the one worth engineering against: every failed delivery spends its retry window, and everything unacknowledged at the end of it is dropped.

Why does the same message arrive twice after recovery?

Because Meta says it will. The retry mechanism is a re-delivery of the same notification, and the WhatsApp documentation is explicit about the consequence:

"Meta sends retries to all apps that have subscribed to webhooks (and their appropriate fields) for the WhatsApp Business account. These retries can result in duplicate webhook notifications." (Meta — WhatsApp webhooks overview)

The failure mode this bites hardest is the near-miss: your endpoint received the notification, processed it, and then the 200 was lost — a proxy timeout, a worker killed mid-response. From Meta's side that delivery failed, so it retries a message your database already holds. An endpoint that files every arrival as new will double-file customer messages, double-fire automations, and double-count statuses for as long as the backlog drains.

The dedupe key is the message id — the wamid. Every inbound message carries one, and every status notification carries the wamid of the message it describes:

"statuses": [{
  "id": "wamid.HBgMOTE5NjY3NDg1NTY5FQIAERgS...",
  "status": "delivered",
  "timestamp": "1758790000",
  "recipient_id": "919667485569"
}]

Deduplicate messages on the id alone, and statuses on the id plus the status value — sent and delivered for one message are two distinct facts, and a retried sent must not block a fresh delivered. Keep the set of processed keys for at least seven days, the longest window Meta documents, and treat insertion into that set and the side effects as one transaction, or a crash between them recreates the duplicate problem you were solving.

Do retried deliveries arrive in the right order?

Assume not. Meta publishes no ordering guarantee for webhook deliveries — the webhook payload reference and both webhook pages were checked for one on 25 September 2026 and none of them addresses ordering at all — and the retry mechanism makes interleaving structurally inevitable. A sent status that failed to deliver on Friday is retried on Monday, landing in the same queue as Monday's fresh delivered and read for the same message. After any outage, your endpoint will observe time moving backwards.

The defence is to treat statuses as a set with precedence rather than a sequence: read outranks delivered, which outranks sent, which outranks failed-then-recovered edge cases you decide explicitly. A handler that assigns whatever status arrived last will show customers' conversations regressing from read back to sent for hours after recovery — cosmetically alarming, and corrosive to anyone's trust in the numbers downstream.

What is gone once the retry window closes?

Everything that was never acknowledged. The generic page says unacknowledged responses "will be dropped after 36 hours"; the WhatsApp pages promise retries "until the request succeeds, for up to 7 days", after which the promise simply ends. Neither the WhatsApp webhook pages nor the generic Graph page documents any endpoint for requesting a re-delivery, and no replay mechanism appears anywhere in the webhook documentation read for this article — the retry schedule is the only recovery Meta describes, and it runs on Meta's clock, not yours.

Concretely, for an outage longer than the window: inbound customer messages sent during the gap will never reach your system, and no API call afterwards can fetch them. The messages still exist on the customer's phone and in the business's WhatsApp clients — Meta has not deleted anyone's conversation — but the webhook was your only feed of them, and it has moved on. Status updates for messages you sent before the outage are equally unrecoverable once dropped: a message your records show as sent forever may well have been delivered and read, with the evidence expired.

How do you reconcile after the endpoint comes back?

In this order, because each step feeds the next:

1. Fix the endpoint and prove it answers 200 fast. Nothing else matters until this is true, and every hour it is not spends more of the window.
2. Let the backlog drain without fighting it. The retried deliveries arrive on Meta's decreasing-frequency schedule mixed into live traffic. Keep acknowledging quickly; do not rate-limit or firewall the burst, because a rejected retry just goes back into the queue.
3. Find your high-water mark. The last inbound message timestamp and wamid your database holds from before the outage marks the edge of what you know. Anything after it either arrives by retry over the following days or was dropped — there is no third category, so schedule the audit for after the window closes, not the morning of recovery.
4. Reconcile your own sends from your own records. Every message you sent through the API returned a wamid in the response. Statuses for those wamids may backfill inside the window; any that never do should be marked unknown rather than failed, because absence of a status is now evidence of nothing.
5. Only then compare against Meta's aggregate analytics if the account's numbers matter to billing or reporting — aggregate counts survive an outage even where per-message webhooks did not.

How does WabaCRM handle retries on its own outgoing webhooks?

Everything above is Meta's side of the contract: Meta delivering WhatsApp events to a platform like WabaCRM. WabaCRM then operates the same pattern one hop downstream — outgoing webhooks from a workspace to a customer's own CRM or backend — and publishes its own rules, which are deliberately not Meta's. In WabaCRM's production behaviour, an endpoint that fails twenty consecutive deliveries is switched off rather than retried for a week, because a receiver that has been down that long is better served by a visible "disabled" state and a manual re-enable than by a silent backlog. And a WabaCRM retry is a newly built payload carrying a fresh sent_at, which means a fresh X-WabaCRM-Signature on every attempt — so receivers must deduplicate on the event name plus the record id and status, never on a hash of the body.

The reason to say this here is not the product; it is the general lesson. Every webhook platform chooses its own retry count, window, disablement rule and signature scheme, and none of them inherits Meta's. If your architecture receives webhooks from more than one system, read each system's own page — the 36-hour figure, the 7-day figure and the 20-failure figure on this page are three different answers to the same question from two providers, and only one of the three is a number you can see and change in a dashboard.

Every Meta quotation on this page was read from Meta's own documentation on 25 September 2026. Meta changes that documentation without notice; the linked pages are authoritative and this one is not.