Plan your send
Presets above are typical contractual tiers — check YOUR provider agreement; throughput is a route/contract property, not a constant.
Destination local time. If the end time is earlier than the start, it's treated as an overnight window.
Queue math: why drain time isn't recipients divided by TPS
Little's law gives the intuition behind every number on this page: the average number of items sitting in a queue equals the rate items arrive times the average time each one waits. Applied to SMS sending, your "queue" is the stack of message parts waiting to be submitted, the "arrival rate" is however fast your own code tries to push them, and the only lever you actually control is how fast the far end lets you drain that queue — your contracted TPS. If you generate parts faster than TPS lets you submit them, they don't vanish; they queue, and your true finish time is total message parts ÷ TPS, not total recipients ÷ TPS. That's the exact formula this planner runs on every keystroke.
Recipients and messages-per-recipient tell you how many distinct messages you're sending. Segments-per-message tells you how many of those message parts each one actually costs once it's split for delivery. Multiply all three together and you get the number that actually matters for pacing: total message parts. That's the number this tool divides by TPS, and it's the number your provider's rate limiter is counting too.
Why bursting above your contracted TPS backfires
A contracted TPS ceiling isn't a suggestion or a soft average — it's usually enforced per-second at the SMPP bind or API layer. Submit faster than that ceiling and the excess doesn't queue politely on the carrier's side; it gets rejected outright, most commonly surfaced as an ESME_RTHROTTLED response. Retrying a rejected submission still consumes a slot in your next second's budget, so bursting can make a campaign slower overall than pacing it correctly from the start, on top of whatever retry/backoff penalty your own client or the aggregator applies. See the DLR / SMPP error code lookup for what each status code means when you see it in your logs.
Segments multiply parts, not just characters
A message that needs 2 segments instead of 1 doesn't just cost more to send — it consumes two submission slots against your TPS budget instead of one, which means it takes twice as long to clear the queue at a fixed TPS. A campaign where every message needs 3 segments takes three times as long to drain as the identical recipient list sent at 1 segment each, even though the TPS number never changed. Before you plan a send, check the UDH Segment Surgeon to see exactly how many segments your real message text produces — encoding surprises (a curly quote forcing UCS-2, for example) can silently double your segment count and therefore double your drain time.
Frequently asked questions
How long does it take to send 100,000 SMS at 10 TPS?
At 1 segment per message: 100,000 recipients × 1 message × 1 segment = 100,000 message parts. 100,000 parts ÷ 10 TPS = 10,000 seconds = 2 hours, 46 minutes, 40 seconds (about 2h47m) of continuous send time. If each message needs 2 segments instead of 1, the part count doubles to 200,000 and the same 10 TPS ceiling stretches the drain time to 5 hours, 33 minutes, 20 seconds — segments multiply directly against your throughput budget.
What does TPS actually mean for SMS sending?
TPS (transactions per second) is the maximum rate at which your specific route or contract lets you submit message parts to the carrier or aggregator. It is a property of your route and agreement, not a fixed industry constant — typical contractual tiers range anywhere from low single digits to a few hundred, and the only number that matters is the one written into your own provider agreement. Every message part your account submits, not just distinct messages, counts against that ceiling.
What happens if I send faster than my contracted TPS?
Bursting above your contracted rate causes the carrier or aggregator to reject or delay the excess submissions, most commonly surfaced in SMPP as an ESME_RTHROTTLED response. The fix is pacing: submit at or below your contracted TPS continuously rather than sending in bursts and hoping the queue absorbs the overflow. See the DLR / SMPP error code lookup tool for what each status code means in practice.
How do message segments affect total send time?
Each segment a message splits into is transmitted — and billed — as its own message part, so a message that needs 2 segments consumes two units of your TPS budget instead of one and doubles its share of your drain time at a fixed TPS. A campaign where every message needs 3 segments takes three times as long to clear the queue as the same recipient count at 1 segment each. Check the UDH Segment Surgeon tool to see exactly how many segments your message text will produce before you plan the send.