Delivery and read status
Connect records what Meta tells it about an outbound message and nothing beyond that. A returned message id makes a message sent; each status callback afterwards is matched on that id and stored as it arrives, along with the category Meta billed the conversation under. Where nothing is reported, the message shows no status rather than an assumed one.
The states, and what each one proves#
- Uncertain
- Handed to Meta, no message id back yet. Not the same as failed and not the same as sent.
- Sent
- Meta returned a message id. That id is stored, because every later status is matched on it.
- Delivered
- Meta reported the message reached the recipient's device.
- Read
- Meta reported the recipient opened it — only where the recipient's own settings allow that.
- Failed
- Meta refused it or gave up, with a reason. A rate-limit code is reported as a rate limit, not as a broken message.
The gap between *uncertain* and *sent* is small in time and large in meaning. A system that marks a message sent the moment it hands it over will report success for messages that never left, which is the failure argued against in Why 'sent' must require provider evidence.
A status also carries Meta's own conversation category — service, utility, marketing or authentication. That is the category the conversation is billed under, and it is stored because it is the only trustworthy number for what a conversation cost: the categories differ by roughly 7.5 times in price, so counting messages instead would understate a marketing month badly.
Why the last two rows carry a caveat#
Delivery and read reporting arrive as separate callbacks from Meta, at whatever moment Meta sends them, and a callback can be late or never come at all. Connect does not normalise that into a comforting fiction: it stores what it is given and shows nothing where it was given nothing. A message with no delivery report is not a failed message and it is not a delivered one.
Read receipts carry a further caveat that has nothing to do with Connect: a recipient can turn them off. On a chat where they are off, a message can be read attentively and never reported as read. Treating an absent read receipt as evidence of an unread message is a mistake the data does not support.
Do not build a rule that chases a customer because a message shows no read receipt. On this channel that rule fires on people who read every word, and it is the fastest way to make an attentive customer feel harassed.
What status should actually change#
| What you see | What it justifies | What it does not justify |
|---|---|---|
| Failed, with a window reason | A different approach — an approved template, or another channel | Resending the same message |
| Failed, with a rate-limit code | Waiting: Meta is saying slow down, not that the message is wrong | Retrying immediately, or editing the message |
| Failed, with a credential reason | Checking the configuration; other sends are probably failing too | Assuming the customer is unreachable |
| Sent, nothing since | Waiting. A callback may still be in flight | Concluding the message was lost |
| Delivered, no reply after a reasonable time | A follow-up, on a channel that is open | A second identical message |
| Read, no reply | Patience, or a call | Repeating yourself |
A repeated failure on one contact is worth escalating rather than retrying, and that is what Needs You exists to hold. An operational problem a person should look at is a first-class entry there, not a line in a log nobody reads.
Where the status is visible#
The outbound message on the conversation carries its own state, and the decision log — #/autonomy-audit — carries the record of what was decided and what happened, including refusals. The two answer different questions: the conversation answers "did this message go", the decision log answers "why was this sent at all, and under which rule".
Neither surface invents information. If Meta is silent about a message, both will be silent about it too, and that consistency is worth more than a hopeful default. The channel's own usage view adds the third question — what the last thirty days cost, split by billed category rather than by message count.
Questions#
Why does an email show more delivery detail than a WhatsApp message?
The two platforms report different things. Email delivery evidence comes from the sending provider's own acknowledgement; WhatsApp status is whatever Meta posts back on its status callbacks, which is a message id, a state, and the category the conversation was billed under.
Can I get a report of messages that failed?
Failures are visible on the conversations they belong to and in the decision log, and a repeated failure escalates into Needs You. Asking the Connect Assistant about recent activity is usually the quickest route to a list.
Does a delivered status mean the customer got a notification?
It means Meta reported delivery to the device. Whether a notification was shown, silenced or ignored is not something Meta reports, and Connect does not claim it.