SMS throughput, throttling and queuing

Submission speed and delivery speed are different things, and most "SMS is slow" tickets dissolve once the two are separated.

Your bind has a rate

Your connection has an agreed throughput (messages per second). Submit faster than that and messages queue on our side - they are not lost, they are waiting. Sustained submission above your rate grows the queue and the tail latency; the fix is either pacing your submission or agreeing a higher rate.

Destinations have rates too

Some destination networks throttle inbound international SMS, and registered routes in regulated markets sometimes carry per-sender rate limits. A campaign that submits in one burst can deliver over a much longer window on such destinations - that is the destination's policy, not queue misbehaviour.

Campaign hygiene that avoids the ticket entirely

1. Tell us in advance about large campaigns or televoting-style bursts: expected volume, destinations, window. We pre-clear the fraud controls (bursts look like spam floods to monitoring) and confirm the route can take the rate - see "Fraud controls on wholesale traffic".
2. Spread submission across the window rather than front-loading.
3. Watch your DLR return rate during the send - a healthy campaign shows DLRs flowing steadily behind submissions.

Reporting a throughput problem

Include: submission timestamps and rate, message IDs from the start and end of the affected window, destination(s), and whether DLRs eventually arrived (slow) or never arrived (something else - see the DLR guide). If the queue is on our side we will say so and show you the drain rate.