Debug delivery by destination, not globally
SMS delivery problems often appear global in a support queue but local in the data. One country, carrier, sender identity, template, or route can be responsible for most of the failures. Start by grouping delivery outcomes before changing application code.
Country-first debugging keeps the team from chasing the wrong layer. If only one destination market is affected, the next check should be country setup, sender identity, route behavior, template review, or local filtering patterns. If the same template fails across many countries, look at application changes, account configuration, content, or provider availability. If one carrier is overrepresented, preserve enough message IDs and timestamps to escalate the pattern instead of rewriting the user flow.
- Group failed and delayed messages by country.
- Split traffic by sender identity and template.
- Compare current failure rate with the same hour, day, and use case.
- Check whether failures share a provider error category or carrier metadata.
- Preserve unknown states separately from confirmed failures.
The goal is not to prove blame immediately. The goal is to narrow the next action. A support team needs to know whether the answer is resend, wait, use a fallback channel, correct the number, or escalate with evidence. An engineering team needs to know whether the pattern is tied to release timing, webhook processing, sender selection, or a downstream delivery path.
Country and carrier debugging table
| Pattern | Possible cause | Next check |
|---|---|---|
| Failures only in one country | Route issue, sender identity mismatch, template review, or destination restriction. | Check country route, sender approval state, and recent provider notices. |
| Failures on one carrier | Carrier filtering, route quality, handset behavior, or provider-specific issue. | Segment by carrier metadata when available and escalate with message IDs. |
| Delivered is missing but sent exists | Receipt delay or uncertain receipt behavior. | Wait for the receipt window, then reconcile with provider logs. |
| OTP expires before delivery | Delivery latency longer than product code lifetime. | Compare code expiry, resend cooldown, and delivery timestamps. |
| A sender identity suddenly fails | Approval, route, or template issue. | Review originator used, registration status, and fallback sender behavior. |
Add time windows to every pattern. A single failed alert in Canada may be normal noise. A sudden cluster for one sender identity in the United States during a launch is a different operational signal. Compare the affected hour with recent baseline traffic for the same country, template, and message type. That keeps the incident response focused on real deviation instead of anecdotal support tickets.
Build an escalation packet
Provider or carrier escalation works better when the team brings evidence. A useful escalation packet includes a small set of affected message IDs, destination country, carrier metadata if available, sender identity, message template, timestamps, raw callbacks, and current user impact.
Keep the packet small and precise. Ten clear examples from the same country, sender identity, time window, and status pattern are usually more useful than hundreds of unrelated failures. Include successful control examples when you have them, because they show what changed: the same template delivered in one country but not another, the same carrier worked before a specific hour, or the same user received account alerts but not OTPs.
Make country debugging repeatable
Use Notilify to review delivery states, country pricing, sender setup, and failed-message history together.
See SMS pricing by country