SMS Delivery Latency: How to Measure and Reduce Delays
Late authentication messages and late alerts generate support tickets faster than almost any other messaging fault. They are also the fault most often misdiagnosed, because the phrase "the SMS was slow" covers at least five separate delays, only some of which involve a route at all.
Build a timestamp ledger first
Before changing anything, record five timestamps per message, in UTC, and keep them together so the gaps can be read directly.
- Created: the moment your application decided to send, before any queueing of its own.
- Request started: the moment your application actually transmitted the submission, which separates your own queueing from the request itself.
- Submitted and acknowledged: the moment the submission was accepted for onward handling.
- Downstream status event: the time carried in a delivery receipt or status event, where one is supplied.
- Callback received: the moment your system actually processed that status event.
The gaps tell the story, but read them precisely. Created to submitted and acknowledged covers your own queueing plus request transmission, transport and acceptance — not your queue alone, which is why the request-started timestamp is worth recording. Submitted to status event is the onward path. Status event to callback received covers the provider dispatching the callback, transit, any callback retries and your own endpoint and ingestion, so a wide gap there narrows the search rather than proving your ingestion is the culprit.
One caution that changes conclusions: a delivery receipt is a network status event, not a measurement of handset arrival and certainly not of the recipient reading the message. Receipt timing and semantics vary by route and by provider, as public status documentation illustrates. Treat receipt time as the best available proxy, label it as such, and do not build a promise on it.
Read the tail, not the average
Report p50, p95 and p99 for each gap, per destination and traffic type. The median tells you whether the normal case is healthy; p95 and p99 are duration thresholds that expose the slow tail, not a count of affected users. Compare each against what the use case actually needs. The SRE monitoring guidance makes the case plainly: averages conceal the tail, and the tail is what generates complaints. Keep failed and rejected requests in a separate series, because a fast rejection otherwise flatters your latency figures.
A symptom-to-cause table
| Symptom | Likely area | Next check |
|---|---|---|
| Created-to-request-start gap growing | Your own application queue or worker capacity | Queue age and worker saturation at the time of the spike |
| Submission accepted but slowly, steady rate ceiling visible | Rate limiting somewhere on the path | Compare your submission rate with the agreed rate and look for queueing responses |
| Delay confined to one destination or network | Route or destination-side behaviour | Compare a matched cohort on another destination and check recent route changes |
| Delay confined to one sender or template | Sender registration, template or content handling | Check sender rules and error codes for that sender rather than overall delivery |
| Status event timestamps early, callbacks late | Provider callback dispatch, transit and retries, or your endpoint and ingestion | Compare dispatch and arrival times where available, then check callback endpoint latency, retries and backlog before assuming ingestion is the cause |
| Everything late during a fixed window each day | Peak saturation | Segment volume and queue age against the peak profile |
Rate-limit queueing is worth calling out because it is so often invisible from the application side. Twilio's documented queueing error is a provider-specific example of messages waiting because of a sending-rate or sender-level limit; the general lesson is that a submission which returns quickly can still sit in a queue you cannot see. For MessageTrade, throughput and enabled functions are agreed per customer, which makes 'what rate am I actually entitled to' a solution-design question rather than a guess — the natural starting point for a managed SMS gateway for SaaS applications discussion.
What actually reduces perceived delay
- Remove your own queueing from the critical path for authentication traffic, and keep it separate from bulk sends.
- Send fewer segments where a shorter template crosses a segment boundary: that reduces capacity and cost, although on its own it does not guarantee faster delivery.
- Separate traffic classes so a promotional batch cannot sit in front of a passcode.
- Where supported and agreed, align message validity with the message's usefulness; enforce passcode expiry in the application and do not assume network validity prevents every late arrival.
- Set application-side passcode expiry from your security and usability policy rather than simply extending it, and tell the user how long the code lasts.
- Give the user a controlled resend with a visible cooldown, rather than a button that can be pressed five times.
Be sceptical of two common suggestions. Moving compute closer to users does not shorten the mobile network's own handling of a message, and route labels do not guarantee speed for a particular destination or sender. Both may help; neither is a general cure, and neither should be promised.
The expiry trap
A recurring pattern in authentication support tickets is a passcode that arrives, but arrives after the application has already invalidated it. From the user's point of view the message is broken even though it was delivered. Align validity in the network, expiry in the application and the wording shown on screen, and audit all three together whenever any one of them changes. Alignment reduces the mismatch; a network validity period is not a guarantee that no message will ever arrive late.
Latency work is measurement first, change second. A team that can point at a p95 gap in one specific interval will fix the problem far faster than a team comparing delivery percentages.
Discuss delayed OTP and alert delivery
Tell us which destinations and traffic are arriving late, what your application measures today, and how your passcode or alert expiry is set. We can then discuss where the delay is likely to sit and what can be examined for your service.
Sources and further reading
Independent references are general context, not evidence of MessageTrade capabilities, partnerships or performance.
Related guides
- SMS Gateway Scalability: Throughput, Queues and Capacity
Scaling SMS is rarely about adding servers. It is about knowing which rate limit binds first, whether your queue is deep or old, and how much backlog a peak really creates.
- SMS Failover and Redundancy: Designing Safer Retries
Redundancy in SMS is less about uptime slogans and more about knowing which failures may be retried, which must be reconciled, and which must simply stop.