WhatsApp Error 131047 vs. Messenger's Window Codes

What does Meta's own definition of 131047 actually say?

Meta's own documentation states the reason for error 131047 in one sentence: "More than 24 hours have passed since the recipient last replied to the sender number." (Meta — WhatsApp error codes) The same row gives the fix in one short sentence: "Send the recipient a template message instead."

Every vendor page that ranks for this error repeats the first half of that sentence and stops there. Twenty-four hours, template message, done — the base case, and the least useful part of it, since it's the part nobody gets wrong.

The two words worth reading twice are "replied" and "to the sender number," because almost every confusing case of this error hinges on one of them. "Replied" excludes anything that isn't an actual inbound message or call — a status update doesn't count. "To the sender number" scopes the clock to one phone number talking to one customer, not to the business as a whole. Both qualifiers sit in Meta's own sentence; neither survives most paraphrases of it.

Checked against Meta's documentation on 5 September 2026.

• What does Meta's own definition of 131047 actually say?
• Which customer actions restart the clock, and which do not?
• Why is the window tied to the number rather than the business?
• Does a message sent from the owner's phone reopen anything?
• Why does your CRM show a recent message when Meta disagrees?
• What are Messenger's equivalent codes, and why are they different numbers?
• Which Facebook Page actions let you message someone first?
• How does a comment on a post differ from a direct message?
• What can you send once the window has genuinely closed?
• How should a team be set up so this stops happening?

Which customer actions restart the clock, and which do not?

For WhatsApp, Meta's own definition of the window is narrow: "When a WhatsApp user messages you or calls you, a 24-hour timer called a customer service window starts. If the user messages or calls you again before the timer expires, the timer resets to 24 hours." (Meta — Service messages) A message, or a call — that's the entire documented list.

Messenger's list is longer: nine specific items, including "A person sends a message to your Page or Instagram Professional account," "A person clicks on a Click-to-Messenger ad and then sends a message to your Page," "A person reacts to a message, such as a marketing message," "A person comments on a post on your Page or Instagram Professional account," and "A person publishes a visitor post on your Page." (Meta — Send a message)

The reaction item overturns a common assumption. A tap-and-hold heart looks like nothing — no text, arguably not even a reply — yet Meta lists it in the same sentence as clicking an ad or commenting on a post. WhatsApp's documentation makes no equivalent claim; its window is defined narrowly around messaging and calling, and a reaction is never named as either.

The row worth remembering is the reaction row, because the two platforms disagree on it rather than quietly agreeing. Treating an emoji the same way on both channels is exactly the shortcut a vendor paraphrase makes and Meta's own page does not.

Checked against Meta's documentation on 5 September 2026.

Why is the window tied to the number rather than the business?

Re-read the operative clause from the first section: "since the recipient last replied to the sender number." Not to the business. Not to the WhatsApp Business Account. To the specific phone number that sent the outbound message. (Meta — WhatsApp error codes)

A workspace with two connected WhatsApp numbers — a sales line and a support line — isn't running one clock for a customer who has talked to both. It's running two, and they can be in different states at the same moment: open with sales, closed with support, for the same customer. Nothing in Meta's error object treats the business as a unit; the clock is scoped to the two parties on the message.

A common way to misread the error: an agent sees a customer messaged "the company" nine minutes ago, replies from the support number, and gets 131047 back — because that message went to sales, not support. Nothing is broken; two numbers under one business are, to this rule, two separate relationships.

A workspace running several connected numbers is running that many independent clocks against the same customer, not one shared clock for the business. Any product that lets a team split traffic across numbers — a shared WhatsApp inbox included — has to show the window per conversation, per number, or an agent ends up reading someone else's countdown.

Does a message sent from the owner's phone reopen anything?

No — and this is the one claim on this page Meta's documentation doesn't spell out directly; it follows from applying the same sentence to a case Meta wasn't describing. Coexistence lets a number stay live in the owner's WhatsApp Business app while also connecting to the Cloud API, and every message the owner types on their phone arrives back on the API side as an echo, in the same thread as everything else.

An echo is still the business's own words, delivered through a different door. Meta's rule opens the window when "the recipient" — meaning the customer — replies. An owner typing from their own handset is the sender, not the recipient, exactly as if the words had gone out through the API instead.

That's easy to miss by eye: an agent scrolling a thread sees a bubble that just arrived and assumes recency means an open window, without checking which side sent it. The difference between the WhatsApp Business app and the Cloud API is exactly this — one is a phone, one is a server, and coexistence keeps both live on the same number.

An echo carries the timestamp of the moment the owner tapped send, not the moment the customer said anything, so it cannot be what Meta's rule means by "replied." WabaCRM's own coexistence handling labels an echoed message as arriving "from WhatsApp on the phone" for exactly this reason; the full mechanics, and where the feature still falls short, are in this coexistence write-up.

Why does your CRM show a recent message when Meta disagrees?

Because "last message" and "last reply from the customer" are different timestamps, and most inbox screens show only one. A thread's most recent line can easily be something the business sent thirty seconds ago — a quick note, a reaction the agent applied to an old customer message. All of that updates a naive "last activity" column. None of it is a reply from the customer, and none of it moves Meta's clock.

The failure shows up exactly as this page describes: an agent sees activity from minutes ago, sends a free-form message, and gets 131047 back anyway. The thread wasn't stale. The one direction Meta actually counts was.

The only timestamp Meta's rule cares about is the most recent message that arrived from the customer's own number, and a screen that shows anything else is answering a different question than the one 131047 asks. WabaCRM's inbox tracks that distinction directly: the header above the composer counts down from the customer's own last inbound message, not from whichever line is newest in the thread, because those are frequently not the same message.

What are Messenger's equivalent codes, and why are they different numbers?

WhatsApp gave the 24-hour failure its own dedicated code, and nothing else lives at that address. Messenger did not: the window failure sits inside error code 10, a code Meta also reuses for permission problems and unrelated rate limits, told apart only by subcode. The two subcodes that mean "the window is closed" are 2534022 — "This message is sent outside of allowed window" (fix: "Apps can only send a message to a customer within 24 hours of receiving the customer's message") — and 2018278, worded almost identically: "This message is sent outside of allowed window. Learn more about the new policy here." (Meta — Messenger Platform error codes)

A third subcode, 2018065, also sits under code 10 alongside them — though Meta's own table lists no message text for that one, so treat it as the same closed-window family with less to quote.

Worth naming a code that looks like it belongs on this list and doesn't: 1545041. Meta's table lists it twice — under code 200 and under code 551 — both times worded "This person isn't available right now." (Meta — Messenger Platform error codes) That's a blocked, deactivated, or unreachable person, a different failure with a different fix (none — don't retry), not a timing problem. Conflating the two sends a team hunting for a 24-hour fix toward a problem that was never about hours.

Messenger folds a dozen unrelated failures into one code and separates them only by subcode, where WhatsApp gave the window exactly one number that means nothing else. Alerting built on these codes has to match the full code-and-subcode pair on Messenger and can match the bare code alone on WhatsApp; treating the two the same way misses every Messenger case that was never actually about timing.

WhatsApp's own error space has the reverse problem in one specific place: a marketing template can fail to reach someone for a reason that has nothing to do with the window at all. Error 131049 looks superficially similar - a message that should have arrived did not - but it is a per-recipient marketing limit, counted across every business that messages that person, not a closed customer service window. The two are easy to conflate from a failed-send report alone.

Checked against Meta's documentation on 5 September 2026.

Which Facebook Page actions let you message someone first?

None, strictly speaking — every item on Meta's list of nine is still something the person does. But four of the nine are things the Page builds and publishes, so a person's very first action toward the business is also the action that opens the window: "A person clicks on a Click-to-Messenger ad and then sends a message to your Page," "A person sends a message to a Page via a plugin, such as the Send to Messenger or Checkbox plugin," "A person clicks on an m.me link that takes them to an existing conversation between the person and the Page," and "A person clicks a call-to-action button like Get Started within a conversation." (Meta — Send a message)

The distinction is who set the door in motion. A customer who decides to type "hi" to a Page opened the window unprompted. A customer who clicked a Click-to-Messenger ad the Page paid to run, or an m.me link the Page put in a bio, took an action the business engineered — the click still has to come from them, but the business chose where the door would be.

Every item on that list is still the person acting, even on the four where the Page built the door they walked through. That matters for planning where new conversations come from, and makes no difference to the timer itself: Meta's rule doesn't grade how a message arrived, only that one did.

Checked against Meta's documentation on 5 September 2026.

How does a comment on a post differ from a direct message?

A public comment and a private message trigger the same standard messaging window — "A person comments on a post on your Page or Instagram Professional account" sits on Meta's list of nine exactly like "a person sends a message to your Page or Instagram Professional account" does. (Meta — Send a message) What differs is what a business may do with it.

A direct message opens an ordinary 24-hour window: free-form content, no restriction beyond the timer. A comment opens the same window, but Meta also attaches a second allowance, built for the fact that a comment is public and a reply usually shouldn't be: "Private Replies allows you to send a message to a person when the person publishes a comment on one of your posts or ads, or publishes a visitor post on your Page or Instagram Professional account. The private reply can only be a single message, which will automatically include a link to the post or comment, and must be sent within seven days of the person publishing the post or comment." (Meta — Send a message)

That allowance is narrower in one direction (a single message, not an open conversation) and wider in the other (seven days, not one). Instagram's own comment and reply rules are their own, separate subject; this page covers the Facebook Page side of the same mechanism.

A comment is public, opens more than one kind of reply, and carries a seven-day allowance for a single private message; a direct message is private and governed by nothing but the ordinary 24-hour rule. Treating both replies as the same action in a support queue quietly loses that second allowance.

Checked against Meta's documentation on 5 September 2026.

What can you send once the window has genuinely closed?

On WhatsApp, one thing: an approved template message, in any category. Meta's own fix for 131047 is one short sentence — "Send the recipient a template message instead" — and templates are the only way past a closed window. What each template category costs per conversation is a separate question, covered in WabaCRM's guide to WhatsApp Business API pricing in India rather than here.

Messenger has more categories, each with its own restriction, and none behave like a WhatsApp template:

Three tags on lists like this one no longer work: "Effective April 27th, 2026, all API requests containing the Message Tags CONFIRMED_EVENT_UPDATE, ACCOUNT_UPDATE, and POST_PURCHASE_UPDATE will receive error code 100." (Meta — Send a message) An explainer written before that date and never revisited is describing tags that now fail outright.

None of the rows in that table reopen the window itself — each is a separate, sanctioned way around it, with its own content rules and its own clock. A template message and a Human Agent reply solve the same business problem, but neither is the customer replying, and neither resets anything for the message that comes after it.

Checked against Meta's documentation on 5 September 2026.

How should a team be set up so this stops happening?

Every failure mode on this page is a visibility problem first. An agent replying from the wrong number, a reaction mistaken for a reply, an echo read as a fresh customer message, a "last activity" timestamp standing in for "last customer reply" — none of these are Meta being unpredictable. They are a team working from a screen that doesn't show the one fact the rule depends on.

The fix is the same regardless of team size: track the window per conversation and per number, using only the customer's own inbound messages, and surface it before an agent hits send. That's a software problem, not a headcount one — unlimited team members at every plan level means the fix doesn't get costlier as a team grows, which matters since the failure gets more likely as headcount and numbers grow. What that looks like end to end, including what a shared inbox needs to track and how the API sits next to the phone app, is a longer conversation than this page.

It also has nothing to do with what Meta charges for the message itself. WabaCRM operates as a Meta-verified Tech Provider: Meta bills each business directly for its own messages rather than the platform reselling that fee, so this page is about software reading Meta's clock correctly, never about buying more message allowance. Whether that software carries a cost of its own beyond Meta's fees is a separate question, not the one 131047 asks.

The fix is architectural, not procedural: a shared inbox that shows the customer's own last reply per number, not the account's last activity. A shared inbox spanning WhatsApp, Messenger and Instagram, with per-number department access, is what that looks like built out — the same question answered once per conversation instead of guessed at per agent.

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