Why WhatsApp automation stops working after 24 hours

The one rule that governs every delayed automation step

You may send an ordinary free-form message only while a customer service window is open, and a window is open for 24 hours after the customer’s most recent message to you. Every automated step that runs later than that is outside the window, and outside the window the only message type WhatsApp permits is a pre-approved template.

This is not a BNex limit or a vendor setting. It is how the WhatsApp Business Platform works, and it applies identically whether a human or an automation presses send.

The consequence for automation is easy to miss at design time and unavoidable in production: the same workflow step behaves differently depending on when it fires. A step that runs two minutes after an inbound message is inside the window and can send anything. The identical step, delayed by 26 hours, is outside the window and can send only a template — and if no approved template is bound to it, the step sends nothing at all.

What actually fails, and why it looks like nothing happened

A delayed step that has no approved template to fall back on does not error visibly to the customer — it simply does not arrive. From the builder’s side the sequence ran; from the customer’s side the message never existed.

• Day-2 follow-ups fail silently. A sequence that sends a nudge the next day is already past the window unless the customer replied in between.
• Cart and booking reminders land outside the window whenever the customer has not written back, which is exactly when a reminder is most useful.
• Long nurture sequences break at the first delayed step. The first message usually works — it fires while the window is open — which is why the failure is often blamed on the later step rather than on the window.
• Retries mask it temporarily. If a step retries and the customer happens to reply, the window reopens and the retry succeeds — making the failure look intermittent rather than structural.

The window restarts on every inbound message — and that changes the design

Each new message from the customer restarts the 24 hours from that moment. So a sequence is not blocked forever by a closed window — it is blocked until the customer next writes in, which means the design question is what your automation does while it waits.

Two workable patterns follow from this. The first is to bind every step that can run outside the window to an approved template, so the step has a legal message to send. The second is to reschedule: hold the step until the customer next messages, then run it inside the reopened window as free-form text.

The second pattern is cheaper per message but unpredictable in timing — it depends on the customer. The first is predictable but can only ever say what an approved template is allowed to say, which is a real constraint on wording.

How to design a sequence that survives the window

1. 1

   Classify every step by when it runs

   Walk the sequence and mark each step with the maximum delay before it fires. Any step whose delay can exceed 24 hours is an outside-the-window step and must be planned as one.

2. 2

   Bind a template to every outside-the-window step

   Those steps can only send approved templates. If a step has no approved template attached, it has no message it is permitted to send — decide now whether it sends a template or waits.

3. 3

   Keep the persuasive content inside the window

   Templates are reviewed and cannot say whatever you like. Free-form messages can. Put the flexible, conversational content in the steps that fire while the window is open and keep the delayed steps factual and template-shaped.

4. 4

   Submit templates before the sequence goes live

   A step bound to an unapproved template does not send. Submit early enough that approval completes before the sequence is meant to run, and check the approved set rather than assuming a submission succeeded.

5. 5

   Handle the customer who never replies

   Decide explicitly what happens to a contact whose window never reopens. Without a decision, the sequence either stalls indefinitely or keeps attempting steps that cannot be delivered.

Automated sends compete with your broadcast limit

Your messaging limit caps the number of unique recipients you can reach in 24 hours, and automated sends count against it exactly like a broadcast does. A campaign and a workflow firing on the same day are spending the same allowance.

What happens when a human answers in the middle

A human reply is just a message sent into the same conversation. It does not restart the window on its own — only the customer’s message does — but it does mean an automation and a person can act on the same contact without either knowing about the other unless the workflow is built to notice.

• Guard against double-replying. A workflow that sends a nudge to a contact an agent is already handling looks like a system talking over a colleague.
• Decide who owns the conversation after handoff. Common patterns are to pause the workflow for that contact, or to end it outright, but it must be a decision rather than an oversight.
• Sending a template to a customer in an active conversation is legal but jarring. Outside the window it may be the only option; inside the window prefer free-form.

How to test a sequence before it goes live

Test the timing, not just the content. A sequence validated by reading each step in the builder will still fail if the steps fire outside the window, because the failure is caused by when a step runs rather than what it says.

• Send a real message from a test phone, run the full sequence, and note which steps arrive and which do not.
• Leave the window to expire deliberately — wait past 24 hours — and confirm every delayed step either delivers a template or waits as designed.
• Confirm each outside-the-window step has an approved, not merely submitted, template attached.
• Check that a contact who never replies reaches a defined end state rather than stalling.

Common questions

Related reading