Fix a message that didn't send

A message didn’t arrive. Before you look at the contact’s phone or blame the channel, work through the checks below in order: they are ordered by how often each one turns out to be the cause, and the first two account for most of them. This page is written for WhatsApp, because that is where the rules are strictest. Messenger, Instagram, Telegram and SMS are simpler and are called out where they differ.

​

Start here

​

1. The 24-hour window

WhatsApp only lets you send a free-form message to someone within 24 hours of their last message to you. Outside that window, the only thing WhatsApp accepts is an approved template. This is Meta’s rule, not DMLY’s, and nothing in DMLY can widen it. So the first question is always: when did this contact last message you? Open the conversation in the Inbox and look at the timestamp on their last inbound message. If it is more than a day old, the window is closed, and:

• A free-form message will not go.
• An approved template will.

See WhatsApp limits for the window and the messaging tiers in full.

​

2. Template approval

If the window is closed, everything depends on whether Meta has approved the template DMLY wants to use. DMLY ships a set of its own system templates for things like booking confirmations and invoice notifications (their names all start with dmly_) and submits them to Meta when you connect a WhatsApp number. DMLY will only use a template Meta has approved. Not one that is pending, not one that was rejected. That leaves three outcomes for any automated WhatsApp notification: That last row is the single biggest cause of “the notification never arrived.” It is a deliberate choice: sending a free-form message outside the window would be silently rejected by Meta and would show in DMLY as a phantom Sent. Skipping is honest; it’s just quiet.

​

Check and fix it

Open your WhatsApp Templates and look at every template whose name starts with dmly_. Any that is not approved is a hole in your notifications.

​

3. Is the contact reachable at all?

If it works for some contacts and not others, the contact is the variable. DMLY treats a contact as unreachable on a channel if any of these is true:

• They opted out. An opt-out blocks messaging on every channel, permanently, until it’s reversed. See contacts and privacy.
• They’re blocked. A blocked contact is never messaged.
• They have no identity on that channel. A contact with a phone number is not automatically a WhatsApp contact; DMLY needs to have actually reached them on WhatsApp, or matched them to it, before it can send there.
• The messaging window is closed: check 1 again.

​

Automated notifications go to WhatsApp whenever they can

DMLY is WhatsApp-first, and that is the routing rule: an automated notification goes out on WhatsApp whenever the contact has a phone number on file and you have a WhatsApp number connected, whatever channel they first came in on. Someone who arrived through Telegram, Messenger or SMS is still reached on WhatsApp once you have their number. When WhatsApp isn’t an option (no phone number on file, or no WhatsApp number connected) or can’t carry the message (no approved template with the window closed), the other channels ticked for that notification pick it up: the channel they came in on, plus SMS or email if you have those switched on. See Notifications. Replies inside a conversation work the other way round. A flow answers on the channel the message arrived on; this rule is only about the notifications DMLY sends on its own. The practical consequence: a contact with no channel at all and no phone number (an imported row with only an email, say) has nowhere for an automated message to go. It is skipped, silently. (A channel-less lead who does have a phone number is fine: if a WhatsApp number is connected, DMLY attaches that phone to WhatsApp and sends there.)

​

4. Permanent or retryable

Once you have an actual failure to look at, the question is whether it will fix itself. Retryable: a rate limit. A rate-limited broadcast is put back in the queue and tried again a few seconds later, and writes nothing to Logs while it waits. A timeout or an outage at Meta is not retried; it is recorded as a permanent failure straight away. Permanent: the send will never succeed as-is, and DMLY records it on the Logs page. A send the channel rejected writes a row starting Failed <platform> send to …, whatever sent it: an Inbox reply, an invoice notification, an AI reply, a broadcast message, an automation step. An automation step’s message writes a second row as well, send_failed, which names the flow and the step it came from. Both carry the raw reason from Meta, which is what you act on. Some failures are a missing setup rather than a bad recipient. The reason recorded on the message tells you which: All four are workspace setup, not the contact. None of them will resolve on their own.

​

5. What Logs shows

Open Configurations → Reports and select the Logs tab, then select Filters and set Status to Error. Set Event to Messages: a failed send is logged as a Messages entry with an Error status, not under Errors. Errors is a different category, for faults while processing an inbound message, so filtering there hides the row you came for. Leaving Event on All events works too. Then read the Logs page guide for what the rows mean, but two traps matter here specifically. And silence in Logs is not proof. By this point on the page you know three separate ways a message can fail to arrive without writing a single row:

• It was skipped for a pending template with the window closed.
• It was skipped because the contact wasn’t reachable: no record at all.
• It’s mid-retry: nothing is written until it fails permanently.

That’s why the order on this page matters. Logs is where you finish, not where you start.

​

Next