Bulk alert SMS delivery succeeds when the sending rate stays inside carrier limits while the alert queue drains in priority order. Alerts are bursts, and a burst that exceeds the per-SIM rate triggers throttling exactly when the message matters most. The delivery layer must therefore be designed around pacing, queue hierarchy, and delivery monitoring, not around raw hardware capacity.
The core tension is simple: the audience is fixed, the window is short, and the per-SIM rate is capped, so the only variables are the number of SIMs, the number of carriers, and the queue order. This guide shows how to set those variables correctly before the alert, not during it.
This guide is the first sub-article of the mass notification hub. The compliance side of the same problem is covered in the alert compliance guide.
Alert Delivery Is a Throughput and Timing Problem
An alert has a deadline: the message must arrive before the action it warns about. That makes delivery a throughput problem, because the audience must drain within the window, and a timing problem, because every recipient should receive it at roughly the same moment. The two constraints together set the sending rate and the fleet size.
The numbers make the constraint concrete: a utility with 80,000 recipients and a 30-minute notice window needs a sustained rate of about 2,667 messages per minute, which at 50 messages per minute per SIM means at least 54 SIMs across two carriers, plus headroom. The figures are illustrative, but the method is the point.
The SMS gateway product line provides the queueing and pacing layer, and the SIM fleet provides the parallelism that turns the rate into a window.
Build the Queue Hierarchy for Priority and Geography
The queue hierarchy has three levels: the alert queue, the segment queues, and the SIM queues. The alert queue holds the burst, the segment queues split it by geography or risk tier, and the SIM queues pace the actual sends per SIM. The highest-risk segment drains first, and each SIM queue stays under the carrier's per-SIM limit.
The SIM queues should expose per-SIM rate and current depth, so an operator can see which SIM is approaching its limit before it throttles.
| Queue level | Function | Control |
|---|---|---|
| Alert queue | Holds the burst | Priority above all traffic |
| Segment queues | Split by geography and risk | Risk-tier order |
| SIM queues | Pace per SIM | Per-SIM rate limit |
Pace Messages Per SIM and Per Carrier
Pacing is the number that keeps the burst legal: each SIM can sustain a rate set by the carrier, and the fleet multiplies that rate by the number of SIMs. The gateway should pace per SIM and per carrier, spread the burst across the fleet, and avoid hammering a single SIM, because a throttled SIM drops the very messages the alert needs to deliver.
Pacing should also vary by recipient class: high-risk recipients such as critical facilities are sent first with a tighter window, while general recipients follow at a normal pace. The pacing plan and the queue hierarchy should be one document.
The sustainable rate must be measured on the actual carrier with a staged test, not taken from a catalog number.
Monitor Delivery Reports During the Rollout
The rollout should be watched in real time: queue depth, delivery rate, and failure codes per SIM. A delivery-rate drop mid-rollout is a signal to slow the remaining batches or add carriers, and a failure-code spike identifies the SIM or route to pull. The monitoring view should show the same numbers the operations team uses to decide, not a post-event report.
The failure-code mix is the diagnosis: a jump in expired codes means the window is too slow, a jump in rejected codes means registration or content, and a jump in throttled codes means pacing. The mix tells the operator which lever to pull.
| Rollout metric | Alert threshold | Action |
|---|---|---|
| Delivery rate per SIM | Drops 20 percent | Rotate or add carriers |
| Queue depth | Grows past a minute | Check the batch order |
| Failure-code mix | Rejected codes rise | Review registration |
| Expired codes | Rise at the window end | Speed up the pace |
The same delivery-report discipline protects SMS verification at scale, where a late code is equally final.
Test the Burst With a Staged Drill
Run a staged drill before the real alert: send an increasing percentage of the audience, measure the rollout window, and confirm no SIM throttles. The drill should include a second alert arriving while the first is draining, because real operations do not wait for the queue to empty. Record the results, because the drill data is what the sizing math should be based on.
The drill should include failure injection: throttle one SIM, cut one carrier route, and confirm the fleet rebalances without stalling the window. A drill without failure injection tests only the happy path.
The Sizing Formula for Alert Windows
The window equals the audience divided by the sustained sending rate: if the audience is 50,000 and the fleet sustains 2,500 messages per minute, the window is 20 minutes. If the notice needs to reach everyone in 10 minutes, the fleet must sustain 5,000 per minute, which means more SIMs or another carrier. The formula is simple; the per-SIM rate is the part that must be validated.
The formula should be run twice: once for the planning number and once with the validated rate from the drill, because a per-SIM rate that is 30 percent lower than the catalog number changes the window and the fleet size. Document both numbers so the sizing decision is traceable.
The runbook should name who decides to pause or accelerate a live rollout, because the decision cannot wait for a meeting when the window is running.
The pause decision should be based on the monitoring thresholds, not on intuition: a delivery-rate drop below the floor for two minutes, or a queue that stops draining, triggers the pause and the carrier check.
The same thresholds should be written into the alert configuration, so the pause and resume decisions are enforced by the system and reviewed by the operator.
For the compliance rules that apply to the same rollout, see the alert compliance guide, and for the consent and opt-out workflow behind business messaging, see the consent workflow guide.
Telarvo Expert Views
The window is the design target, and pacing is the mechanism. We tell teams to validate the per-SIM rate with a staged drill, keep the alert queue above everything else, and watch the delivery report live. An alert that throttles in the first minute fails the whole notice.
— Messaging Operations Engineer, Telarvo Store
Validation note: per-SIM rates and carrier limits vary by market; validate with a staged drill on the real network.
Conclusion
Bulk alert delivery works when the queue hierarchy protects the burst, pacing stays under per-SIM limits, and the delivery report is watched live, with the sizing formula validated by a staged drill.
Key Takeaways for Delivery Teams
Size the window from the audience and the validated per-SIM rate. Keep the alert queue above all other traffic. Pace per SIM and per carrier. Watch delivery reports live during the rollout. Run a staged drill before the real alert.
Questions to Ask Before You Launch
Ask what your validated per-SIM rate is, how the queue hierarchy is configured, and how the dashboard shows delivery live. Ask Telarvo Store for the gateway configuration that matches your window and a drill plan.
FAQs
Why does pacing matter for alerts?
Exceeding the per-SIM rate triggers throttling, which drops the very messages the alert needs to deliver, and the drop happens exactly at the start of the burst when the window matters most.
How do I calculate the rollout window?
Divide the audience by the sustained sending rate, and add SIMs or carriers until the window fits the notice's deadline, then re-run the math with the drill's measured rate.
What should I monitor during a rollout?
Queue depth, delivery rate, and failure codes per SIM, watched live rather than after the event, with the failure-code mix pointing to the right lever.
How do I test an alert burst?
With a staged drill that sends an increasing percentage, measures the window, confirms no SIM throttles, and injects at least one failure to test rebalancing.
Is the per-SIM rate a fixed number?
No. It varies by carrier, plan, and market, so it must be measured with a staged test rather than assumed, and the measured number should replace the planning number in the sizing formula.