SMS Delivery Reports Explained: Why Messages Fail in Ghana and How to Fix Them

If you cannot explain a failed SMS, you will keep paying for the same mistakes. Delivery reports (DLR) are how SplitSMS and the carriers tell you what happened after you clicked send. They are not perfect — some phones never return a receipt — but they are far better than hoping.

This article translates the statuses you will see in the dashboard and in webhooks, then gives a repair order so you do not change five things at once.

Queued or sending means SplitSMS accepted the job. Sent to network means a carrier took it. Delivered means a handset-level or network-level success came back. Failed means the route or number was rejected. Pending too long often means the network has not said yet — wait, then treat as failed if your SLA is tight (OTP).

Do not celebrate “sent” for OTP. Celebrate delivered, or a login that succeeded. Campaigns can tolerate a small fail rate. Login cannot.

Too short, letters in the field, Excel scientific notation, missing 233, extra zeros. These fail fast and should be stripped from the group. If 20% of a school list fails, the MIS export is wrong — do not keep blasting it.

Unapproved, rejected, or mistyped Sender ID is a classic “works on my phone with a test ID, fails in production” story. Check Dashboard → Sender IDs before you schedule 10,000. If the ID was approved last month and suddenly fails, check whether you switched routes or spelled it differently in the API payload.

Empty wallet stops the queue. Partial sends happen when credits run out mid-campaign. Top up, then use retry only for the unsent remainder — not the whole list, or you double-text people who already got it. SplitSMS can email you on low balance so this is not a surprise on Monday morning.

Barred, inactive, or ported numbers fail at the network. There is nothing to “fix” except removing them. Porting between Ghana networks can lag; a number that worked last term might fail this term. Cleaning after each term is cheaper than arguing with a parent whose line is dead.

Heavy URL shorteners, “WIN NOW”, fake bank language, or unicode that looks like a different brand can be filtered. If tests to your own phone work but a promo blast fails at scale, read the copy like a fraud filter. Then resend a calmer version to a small slice.

Look at fail rate by prefix (024 vs 020 vs 027) if you can. A single prefix collapsing points at a network or a formatting bug for that prefix. Uniform low delivery across prefixes points at Sender ID or account routing. A handful of fails in a huge list is normal.

Developers should log provider message ids and webhook status. Support should ask for campaign id and a sample phone, not “SMS is down.”

Retry failed-invalid? No. Retry failed-temporary or pending after 15 minutes? Once, for OTP and critical alerts. Retry the entire delivered list? Never. SplitSMS admin tools can retry insufficient-credit cases after a top-up — that is the right kind of retry.

After every large send, export or scan fails, update the group, and note the fail rate in your SMS scorecard. That is how lists get healthier and costs go down.

Open your last campaign in SplitSMS, pick ten fails, and classify them with this article. If you cannot classify them, send the campaign id to support. Guessing is how rumours about “the network” start.

A marketing blast can live with 4% failed. A login code cannot. For OTP, treat pending longer than a minute as a support event: check Sender ID, destination format, and wallet, then resend once with a new code. Do not queue three codes to the same phone in ten seconds — the user will type the first one that arrives, which may already be invalid.

Store the provider message id on the OTP row. When someone writes “I never got it,” you should see delivered, failed, or still pending before you argue. The production OTP guide on this blog covers rate limits and webhooks in more depth.

Some networks return a thin acknowledgement and never a final delivered flag. If the user received the text, your report can still look pending. That is why you should not refund or retry solely on a missing DLR when the customer says they have the SMS. Ask them to reply with the last three digits of the Sender ID they saw.

If nobody on that network is getting DLR and nobody is receiving, that is a route problem. If DLR is missing but people are logging in, do not panic-retry. Log it, and mention it to support with timestamps.

1) Wallet. 2) Sender ID spelling and approval. 3) Sample five failed numbers — format vs barred. 4) Fail rate by network prefix. 5) Copy/filter suspicion on promos. 6) Retry only the unsent or truly temporary fails. 7) Update the group. 8) Write the fail % in your monthly SMS notes.

Do this in order. Skipping to “maybe we need another provider” before step 3 is how teams churn platforms and keep the same spreadsheet.