WhatsApp message sent but not delivered: what each status means and what to do about it

Jignesh Vora runs a six-person sales team for a kitchenware wholesaler in Rajkot. On a Tuesday morning his team sent a Diwali price-list template to 4,000 retailers from the WhatsApp Business Platform. By lunch the report read 3,520 delivered, 310 still on one tick, 170 failed. His first message to his provider was “whatsapp broadcast message not delivered, please check”. The numbers are invented; the questions behind them come up every week.

Nothing was broken. One tick, two ticks, two blue ticks and a red triangle each mean something exact, and Meta publishes the meanings in its status webhook reference. This article covers the status ladder, why a message sits at sent, the failure codes a business actually meets, the opt-out webhook, and the pricing fields since 1 October 2026. Our glossary defines the terms used here.

What do sent, delivered and read mean on a WhatsApp message?

Sent means Meta’s servers sent it, delivered means the phone received it, and read means it was displayed in an open chat. Each one proves only that much.

Meta’s status reference, updated 14 September 2026, lists five values and their equivalents in the WhatsApp app:

Status	In the app	What Meta says it means	What it proves
sent	One tick	”Successfully sent from our servers”	Meta sent it on. Nothing about the phone
delivered	Two ticks	”Successfully delivered to the WhatsApp user’s device”	The phone has it. The person may not have looked
read	Two blue ticks	”Displayed in an open chat thread in the WhatsApp user’s device”	The chat was open with your message on screen
failed	Red triangle	”Failure to send or deliver the message”	It will not arrive. An error code says why
played	Blue microphone	”The first time a voice message is played”	Voice messages only, reported since 17 March 2026

Two details on the same page matter when counting. A status is only considered read if it has been delivered, and when a person receives a message while the chat is already open, Meta sends the read webhook without a delivered one first. A report that keeps “delivered” and “read” as separate buckets undercounts delivery unless it treats read as delivered too. And an emoji reaction you send only ever gets a sent status, per Meta’s reaction messages page.

Why is a WhatsApp message sent but not delivered?

Because the phone has not received it yet. Sent is Meta’s side; delivered is the customer’s side, and the gap between them is the customer’s phone, network and account.

The usual reasons, in the order we check them:

• The phone is off, out of signal, or has data switched off. The message waits on Meta’s side, which, as our send-message guide notes from Meta’s reference, keeps trying for 30 days by default and only 10 minutes for authentication templates.
• The number is no longer on WhatsApp, or the app is very old. This eventually comes back as failed with code 131026, which Meta describes as “unable to deliver message”: not a WhatsApp number, the latest terms not accepted, or an outdated app version.
• The person has blocked your business number. Meta’s status page lists no status for this, so nothing in the webhook tells you. A message that stays on one tick for days to a number that is otherwise active is the only hint you get.
• The SIM is in a drawer. Retailers in Jignesh’s list keep a second number for suppliers and switch that phone on when they order. It will deliver next Thursday.

Our position: a message that has sat at sent for 48 hours is not fixed by resending. The resend also sits at sent, and if the first was a marketing template, a resend inside 24 hours risks the retry behaviour covered in our error 131049 article. Note the contact as “one tick since 14 Oct”, and drop numbers that never reach delivered across three sends.

Delivered but not read: what does it tell you?

It tells you the message reached the phone and the chat has not been opened on screen since. That is all.

Read is reported only when the message is displayed in an open chat, and WhatsApp lets people switch off read receipts in their privacy settings. Meta’s status reference does not say how messages to those people are reported, so assume no read status ever arrives for some share of your list. Treat the read count as a floor and compare it across your own campaigns; our marketing ROI guide shows the arithmetic, including why a read rate is divided by delivered, not by sent.

One practical use: a payment-due template delivered on Monday and not read by Wednesday earns a second utility template on Thursday. Read on Monday, a second one is nagging.

What the status webhook actually carries

The send request itself only returns a message ID; from then on the webhook is the only source of truth. Every status arrives on the messages webhook field as an entry in a statuses array, with that ID, the status, a timestamp and the recipient. A trimmed delivered update:

{
  "statuses": [
    {
      "id": "wamid.<MESSAGE_ID>",
      "status": "delivered",
      "timestamp": "<UNIX_TIMESTAMP>",
      "recipient_id": "<USER_PHONE_NUMBER>",
      "biz_opaque_callback_data": "<YOUR_OWN_TAG>",
      "pricing": {
        "billable": true,
        "pricing_model": "PMP",
        "type": "regular",
        "category": "marketing"
      }
    }
  ]
}

biz_opaque_callback_data is a string you set when sending, echoed back on every status for that message. Put your campaign ID in it and reporting stops depending on a lookup table.

The pricing block appears on the sent status and on one of delivered or read, not both. Meta’s page says billable will be deprecated in a future version, and that type and category together are the fields to read.

The errors array appears only on failed statuses, with a numeric code and error_data.details; Meta says to build handling around those, not the title, which will eventually be deprecated.

Webhook delivery is not tidy either. Meta’s webhooks overview says an endpoint answering anything other than HTTP 200 is retried with decreasing frequency for up to 7 days, and retries go to every subscribed app, so duplicates happen. The same message ID with the same status arriving twice should change nothing in your records.

Which failure codes does a business see most?

A handful. Meta’s error-codes page lists dozens; these explain most of a failed column, with Meta’s wording paraphrased.

Code	What Meta says	What to do
131026	Unable to deliver: not a WhatsApp number, terms not accepted, or an outdated app	Mark the contact. Do not retry
131047	More than 24 hours since the person last replied	Send an approved template instead of free text
131049	Not delivered “to maintain healthy ecosystem engagement” (the per-user marketing cap)	Wait at least 24 hours. Never auto-retry. See our 131049 article
131050	The recipient chose to stop receiving marketing messages from your business	Do not retry. Flag as opted out. Subscribe to user_preferences
131048	Restrictions on how many messages this number can send, often because messages were blocked or flagged as spam	Stop the send; check quality status in WhatsApp Manager
131042	A problem with the payment method	Fix billing in Billing Hub. On prepaid accounts this can arrive on the webhook after the send call succeeded
132015	Template paused for low quality	Fix the template, wait for approval
131064	Messaging limit reached because of template classification violations	Review categories; the restriction lifts after the enforcement period

131048 and 131064 are account-level: stop the campaign and read our messaging limits guide first. 131049 and 131050 are per person: information about the list, not the account.

The customer tapped “stop”: the user_preferences webhook

WhatsApp gives people a way to stop marketing messages from a business inside the app, and Meta tells you through the user_preferences webhook. The page, updated 13 August 2026, says it fires when a user stops marketing messages and again if they resume, with category set to marketing_messages and value set to stop or resume. It does not fire for the “Interested” or “Not interested” feedback a person can give through WhatsApp’s offers and announcements setting.

What you do with it is arithmetic, not law. A marketing template to someone who has stopped fails with 131050 and never arrives, and each one is a contact attempted, failed and listed again next time. So on stop, the contact’s marketing flag goes off the same minute; on resume, it goes back on. The category is marketing messages, so a utility template such as a payment reminder is unaffected. Pair it with your own opt-out words, because a customer who types “STOP” in the chat is a message you must act on yourself; our opt-in and DPDP guide covers the records to keep.

What the pricing fields say since 1 October 2026

Since 1 October 2026, "type": "regular" with "category": "service" means a reply that is being charged, and that combination is new.

Through 30 September, Meta’s pricing page said non-template messages inside the customer service window were not charged, and the webhook showed free_customer_service on all of them. From 1 October each business phone number has 1,000 free service message deliveries a month. Replies within that allowance still report free_customer_service; replies after it report regular and are billed at ₹0.115 per delivered message to an Indian number before GST on Meta’s October 2026 rate card. Utility templates sent inside the window now report regular too. Marketing templates always did, and anything inside a Click-to-WhatsApp free entry point window still reports free_entry_point and costs nothing.

The live status page adds a subtype of paid_exempt for service messages that stay free under Meta’s policy for eligible governments and non-profits. Reactions stay free and do not use up the 1,000, per Meta’s changelog entry of 29 September 2026.

The October cost guide has the India rate table.

For non-developers: what the ticks in a campaign report mean

Your campaign report is a tally of these statuses, nothing more. Sent is Meta’s side. Delivered is the phone. Read is the chat opened. Failed carries a code, and the code says whether the problem is the person (131026, 131049, 131050), the template (132015) or the account (131048, 131064).

Back in Rajkot: of Jignesh’s 170 failures, 112 were 131026, mostly old retailer SIMs that had left WhatsApp, 41 were 131049 and 17 were 131050. The 310 on one tick were shop numbers switched off for the day; 260 delivered by the weekend. Nothing to fix, two things to clean: the 112 dead numbers come off the list, and the 17 who stopped marketing are flagged so the next festive send never attempts them.

Troubleshooting: symptom, likely cause, what to do

Symptom	Likely cause	What to do
Whole campaign stuck at sent	Delivery in progress, or your webhook endpoint is down	Check the endpoint returns 200; Meta retries for up to 7 days
A few hundred stuck at sent after 48 hours	Phones off, no data, number abandoned	Wait; clean the list of repeat offenders
Many 131026	Old list with numbers no longer on WhatsApp	Remove them before the next send
131049 climbing during festive weeks	Per-user marketing cap across every business	Trim the list to recent readers; no retries
Everything failing with 131048 or 131064	Account-level restriction	Stop sending; check quality in WhatsApp Manager
Read count far below delivered	Read receipts off for some people, chats not opened	Compare read rate across your own campaigns only

Two habits for whoever owns the inbox. Mark incoming messages as read through the API within 30 days, as Meta’s mark-as-read page allows, so customers see the blue ticks they expect. And store every status against the message ID and the contact, with the code on failures, so the list is cleaned from that record before each campaign rather than after it.