WhatsApp broadcast not delivered: what to check

Choose one failed recipient and one successful recipient from the same campaign, if available. Compare the sending number, template, language, send time and latest status. Use internal record IDs in your investigation; redact phone numbers from shared screenshots.

If every message stopped before sending, inspect the campaign or connected number. If only some failed, inspect their individual results. A campaign summary hides these differences.

Business app: check the app's current broadcast requirements and the recipient relationship. Business Platform/API: use message IDs, delivery callbacks and provider errors. Advice about app broadcast lists does not diagnose an API queue.

Queued: the platform accepted work, but the sender may not have attempted delivery. Check campaign eligibility, pauses and connection health.

Sent: sending progressed, but this is not proof that the recipient received it. Check for a later delivered or failed event.

Delivered: investigate a different issue if the customer says they cannot find it. Do not treat the absence of a read receipt as delivery failure.

Failed: read the code and detail for that message. No recent update: inspect the status or callback path before concluding that delivery failed.

Keep the provider message ID and the time of each event. An older event should not overwrite a newer fact in your investigation.

Review the exact template name, language and required values. Confirm it remains approved and available to the sender. A working English template does not establish that another language variant is ready.

Then check permission, opt-outs, sending restrictions and the number or template quality state. Do not remove suppression rules to make the success count larger. Where a provider error has several possible causes, preserve that uncertainty instead of labelling every affected recipient invalid.

The template troubleshooting guide covers approval problems. Use the broadcast setup guide to inspect the campaign itself.

Confirmed failure with a corrected cause: retry only the eligible failed subset through the documented recovery process. Timeout or unknown result: reconcile the message ID and latest status first. Opt-out or an active restriction: stop; another attempt is not a fix.

Fictional incident: a campaign shows 40 queued messages after the browser timed out. Do not create a second campaign. Check whether the original jobs exist and whether any already have provider message IDs. The browser result and the sending result are separate.

If support needs to investigate, send the campaign ID, request ID, message ID, redacted error detail and timestamps through the verified support route. Never include API keys.

Use one row per affected message: last confirmed state, event time, error code, cause checked, next action and owner. Add the final result after recovery. This makes recurring failures visible without copying customer conversations into a spreadsheet.

Review the failed subset after the fix. A successful API response is still not delivery evidence. Keep the original campaign for comparison and record which messages were retried.