Meta API Outage: What Happens to Your DM Automations

A Meta API outage is not a light switch, and that misconception is why most people plan for the wrong thing. You picture the API being down, your automations pausing, and everything resuming when it comes back. That happens occasionally. Far more often, something subtler and more expensive occurs: the API stays up, reports success, and quietly fails to deliver a fraction of your messages.

This is the mechanics piece — what actually breaks, in what order, and which of it a retry can genuinely fix. If you want the historical data instead, we read seven years of it in our analysis of 155 ManyChat incidents.

The three shapes an outage actually takes

Every DM tool sits between two Meta surfaces: an inbound webhook that tells you a message arrived, and an outbound send endpoint you call to reply. Failures land differently depending on which side breaks, and the difference decides what you can recover.

1. Inbound webhooks stop — you never hear the message

Meta stops delivering the events that tell your tool someone messaged you. From inside your dashboard this is indistinguishable from nobody messaging you. There is no error, because an event that never arrives cannot fail — your inbox is simply quiet on a Tuesday, and quiet Tuesdays happen.

This is the most dangerous shape, because your tool has nothing to retry. It doesn't know a message exists. When the webhooks resume, Meta may or may not replay what you missed, and the shopper who asked “still available?” two hours ago has already bought elsewhere.

2. The send endpoint errors — you heard it, you can't answer

The friendlier failure, oddly. Your tool received the message, tried to reply, and got an error back. It knows exactly what it failed to do, which means it can queue the reply and retry when Meta recovers. This is the one shape where good engineering genuinely rescues most of the value.

3. Silent degradation — everything reports success, nothing arrives

The expensive one. The send call returns success and the message never reaches the recipient. Both sides believe it worked. ManyChat's public incident log documents this shape repeatedly — including a 2020 incident where messages were reported as sent by Meta but never delivered — and their status history quotes exact failure rates like “~1%”, “~3%” and “~5% of messages fail to send” across dozens of separate incidents.

The practical consequence: “is the API up?” is the wrong question. It's almost always partially up. The right question is what share of your sends are landing, and whether anyone would tell you if that number moved.

The fourth shape: you can't connect in the first place

One failure mode sits outside all of the above because it doesn't touch your existing traffic at all — it breaks the door rather than the room. When Meta changes anything about page or business permission scopes, the channel-connect flow tends to break before anything else does.

It's a recurring pattern in ManyChat's incident record: connection and permission-refresh failures after Meta-side changes show up across 2020, 2022, 2024 and 2025, including a WhatsApp signup outage in April 2026 that blocked most new channel connections platform-wide. If you're mid-migration when one of these lands, the symptom is a tool that appears broken on day one — when in fact the product is fine and Meta's OAuth flow is the thing that's down. Worth knowing before you conclude your new vendor is a lemon.

Why retrying doesn't fix everything

Here's the part that surprises people, and it's the reason a Meta API outage costs more than the arithmetic of “hours down times revenue per hour” suggests.

Meta's messaging platform runs on a standard messaging window: after a user messages your business, you have a limited period — 24 hours on the messaging surfaces — to reply freely, after which you need a tag, a template or a paid mechanism to reach them again. ManyChat's own product-marketing team has published a checklist of these constraints, and we want to be clear about what that means: these are Meta's platform-wide rules, binding every compliant tool identically. They are not a competitor weakness and we're not presenting them as one. Meta documents the policy itself in the Messenger Platform policy overview.

An outage doesn't just pause your replies. It spends your clock.

Now put the two together. A six-hour outage during a launch doesn't merely delay six hours of replies — it burns six hours off every open window. Messages that arrived early in the outage may be close to expiry by the time sends recover. The queue drains successfully, the retries all report success, and a portion of those replies land outside the window where a free reply was allowed. Your tool did everything right. The clock still ran.

Which is why the recoverable and unrecoverable piles are not what people assume:

• Recoverable — sends that errored inside a still-open window. A queue plus retry genuinely saves these, and this is the pile good engineering protects.
• Partly recoverable — messages whose window closed during the outage. Reachable, but now only through a tag, template or paid message, which is a different conversation with different rules and costs.
• Not recoverable — messages your tool never received, because the webhook never arrived. There is nothing to retry. This pile is invisible in every report you'll ever run.

The comment-to-DM trap

One constraint deserves its own section because it's where outages do disproportionate damage, and it's specific to the highest-value automation most brands run.

Meta allows exactly one private reply per comment, and that private reply does not itself open the 24-hour window. That rule is fine on a normal day. During an outage, it's brutal: a reel climbing while Meta is degraded produces hundreds of comments whose single permitted reply is being attempted against a failing endpoint.

We're going to stop short of telling you exactly what happens to a private reply that errors mid-outage, because we don't have documentation confirming whether a failed attempt consumes the one permitted reply, and inventing an answer here would be exactly the kind of confident nonsense this post exists to argue against. What we can tell you is that it's the sharpest question you can ask any vendor, ours included: “if a comment's private reply fails because Meta errored, do I get another attempt?” Make them answer specifically.

How you find out — and why it's usually too late

The failure mode that costs the most money isn't the outage. It's the gap between the outage and your awareness of it.

ManyChat's community carries an open, upvoted request for an alert when automations stop sending, from users who report discovering it only after the leads were gone. Another thread describes a dashboard showing a message as delivered when the recipient never received it — the silent-degradation shape, seen from the merchant's chair. We cite these as category-wide blind spots rather than as one vendor's failings; the fact you can read their community discussing them openly is more transparency than most vendors here offer.

The question to carry into any evaluation: when your sends start failing at 3%, who tells you, and how fast? If the honest answer is “you'll notice in the revenue,” that's the real cost of the next Meta API outage, and it's not on anyone's pricing page.

What to do about a Meta API outage

The uncomfortable honest note first: HyperDM runs on the same official Meta APIs as every other compliant tool in this category. When Meta degrades, we degrade. We cannot sell you an uptime edge against Meta and neither can anyone else — anyone claiming otherwise is misreading their own stack. What's actually available is behaviour around the failure, and that's where you should aim your scrutiny.

• Ask every vendor the three questions in this post: what happens to messages you never received, do failed sends queue and retry, and what happens to a comment's one permitted private reply.
• Watch Meta's own status, not just your tool's — the developer status dashboard is the upstream source none of us control.
• Keep a manual fallback you can run for a few hours: a pinned story, a link in bio, a human on the inbox. It's low-tech and it's the only thing that works when the API doesn't.
• Don't put your single biggest drop in a window you can't babysit, because the base rate says a Meta-wide outage lands on someone's launch day roughly twice a year.

If you want to put a number on your own exposure rather than a feeling, the Meta outage impact calculator models it from your DM revenue, and we walk through the full arithmetic in the real cost of an outage on launch day. If reliability is what has you reconsidering your stack, the switch page makes the rest of the comparison honestly — including the parts where we're behind.