SMS notification systems for business: alerts, gateways and reliability

An alert is only useful if it arrives while it still matters. A "your server is down" text that lands 40 minutes late is a postmortem footnote. A delivery window that shows up after the driver has left is a support ticket. SMS is still the channel ops and IT teams reach for when email is too slow and push notifications depend on an app being installed. It has failure modes that most "SMS gateway" marketing pages leave out.

This post covers what an alerting team needs to decide: which kind of notification API to use, what delivery guarantees actually exist (fewer than you'd hope), how to design fallback, and how to write alert content that gets through 10DLC and toll-free filtering. We make Ready, so we'll say where it fits, and where it doesn't.

What an SMS notification system actually is

Strip away the branding and every SMS alert system has the same four parts:

1. A trigger. A monitoring tool, an order system, a scheduler or a person decides a text needs to go out.
2. A sending API. Your code calls a provider over HTTPS. The provider hands the message to carrier infrastructure.
3. A registered sender. In the US that means a 10DLC number on a registered campaign, a verified toll-free number or a short code. Unregistered traffic gets filtered by carriers. Registration is a requirement, not a nice-to-have.
4. A feedback loop. Delivery receipts, inbound replies and opt-outs come back through webhooks so your system knows what happened.

The "gateway" is the second part. If you want the longer definition, see What is an SMS gateway?. The part that decides whether alerts arrive is usually the third, and the part teams forget to build is the fourth.

Choosing a notification API

There are roughly three kinds of provider. The right one depends on how much compliance plumbing you want to own.

Here's the honest version. If you send purely internal machine alerts, at volume, and you have engineering time to build registration and opt-out handling, a raw CPaaS costs less per segment. That's a fine choice. Ready makes more sense when you'd rather not build that layer, or when you're a platform sending alerts on behalf of many customers. In that case each customer needs its own brand registration, numbers and opt-out list, and sub-accounts handle that separation.

What a send looks like

On Ready, a single alert is one request:

POST https://api.tryready.com/v1/messages
X-API-Key: <your key>
Idempotency-Key: 6f1c2a9e-3b7d-4e0a-9c51-2d8f4a7b1e03
Content-Type: application/json

{
  "to": "+12125550199",
  "body": "Acme Ops: Checkout API error rate above 5% since 14:02 UTC. Runbook: acme.co/rb/12. Reply STOP to opt out.",
  "consent_attested": true
}

The Idempotency-Key header matters more for alerts than for almost anything else. Monitoring systems retry. Network calls time out after the provider has already accepted the message. Without a key, a flapping alert can text the on-call engineer six times. The pattern is covered in how to stop duplicate texts from your SMS API. For one alert to a whole list, POST /v1/messages/bulk takes up to 100 recipients per call, so a 5,000-person list is 50 calls. Full reference: docs.tryready.com/api/messages and docs.tryready.com/api/bulk-messages.

Delivery SLAs: what's real and what isn't

No SMS provider can promise you a delivery SLA on carrier delivery, and you should be suspicious of any that implies it. A provider controls its own API uptime and how fast it hands messages to carrier infrastructure. After that, the message is in carrier networks that publish no rate card and make no per-message guarantees. Phones are off, out of coverage or roaming. A delivery receipt tells you the handset network accepted the message. It does not tell you a human read it.

What you can plan around is throughput. That is the number that actually decides how late your alerts land.

The throughput math nobody does until an outage

Carriers meter segments per second, per campaign. These are round approximations, because carriers don't publish exact figures:

• A fresh standard 10DLC campaign with no brand vetting: about 1 to 4 segments per second.
• Higher use-case tiers: tens of segments per second (roughly 10 to 75).
• T-Mobile also caps brands per day by trust score: about 2,000, 10,000, 40,000, 100,000 or 200,000 messages a day, lowest score first.

Worked example (assumptions stated): a status-page outage alert to 5,000 customers on a fresh standard campaign, at an assumed 3 segments per second.

• One-segment message: 5,000 ÷ 3 ≈ 1,667 seconds, or about 28 minutes before the last customer gets it.
• Add one emoji and stretch the copy to 140 characters. Unicode drops the limit to 70 characters per segment (67 multipart), so that's 3 segments: 15,000 segments ÷ 3 ≈ 83 minutes.

At 2,000 messages a day on the lowest T-Mobile tier, that list doesn't finish the same day on T-Mobile at all. That's the case where brand vetting ($79 Standard / $179 Enhanced, one-time) can pay for itself. Vetting raises the trust score, which moves the daily cap only if it crosses a tier. It does not change the per-second rate. More on why sends lag your code in SMS API rate limits.

The practical takeaways: keep alerts to one GSM-7 segment (160 characters, no emoji), and send the people who need the alert first, ahead of the full list.

Quiet hours: know what holds your message

Ready holds sends outside permitted local hours based on the recipient's area, and sends them later. Held texts are charged only when they go out. For customer notifications, that rule reduces TCPA exposure. For a 3 AM page to an on-call engineer, a held text is a missed page. Read how quiet hours hold each kind of text at docs.tryready.com/compliance#quiet-hours and test your real alert path at night before you depend on it. Don't make SMS the only channel for anything that has to wake someone up. Campaigns, drip campaigns and automations wait up to 24 hours for the window; a one-to-one or API text is held only if the window opens within 6 hours, otherwise it is refused and must be resent; a one-to-one reply to someone who texted you in the last 24 hours goes out at any hour.

Fallback: plan for the text that doesn't land

Ready does not fail over between carrier providers. Your fallback has to live in your own system, which is where it belongs anyway. A sane escalation ladder looks like this:

1. SMS first. It's fast and reaches people without an app.
2. Check the feedback. If no delivery receipt or acknowledgment arrives within your window, escalate. Webhook payloads are documented at docs.tryready.com/api/webhooks. Build against the docs, not against guesses.
3. Second channel. Push, email or your paging tool.
4. A human call. The Ready Dialer gives you click-to-call from the dashboard at $0.025/min. Only answered time is billed, so a ring-out costs nothing. It's manual calling, not an auto-dialer, so treat it as a person picking up the phone, not as automated escalation.

For alerts to people you already have an ongoing thread with, a blue line (iMessage) is worth a look. It costs $99 a month per line plus 6 cents a segment, and it shows your business name and photo on iPhones. Limits apply: up to 50 new conversations a day per line, and campaigns send from regular numbers, not the blue line. That makes it a fit for one-to-one alerts, not list-wide ones. See SMS API with iMessage fallback and docs.tryready.com/guides/imessage.

Writing alert content that gets through 10DLC and toll-free

Registration approval is half the job. The other half is sending what you registered.

• Register the right use case. Account notifications, delivery notifications and security alerts are their own use cases. If you register "marketing" and send reminders, or the reverse, you're asking for filtering. See matching use case to what you actually send.
• Don't mix promos into alerts. "Your order shipped! Use code SAVE20 on your next one" turns a delivery notification into marketing. Carriers filter on content, not just on registration.
• Name the sender. Start with the business name so the recipient knows who it is.
• Include opt-out language. "Reply STOP to opt out" belongs in alert flows too. On Ready, STOP is honored automatically and carries across campaigns. Opted-out numbers are refused up front and not charged.
• Avoid shortened links from public shorteners. Use your own domain.
• Toll-free has its own path. Toll-free numbers need verification rather than 10DLC registration. The content rules are similar: a clear sender, a consistent use case, opt-out handling. Ready sends on registered 10DLC numbers, so if toll-free is a hard requirement, confirm that with any provider before you build.

Consent still applies to alerts. consent_attested: true is your promise that the recipient agreed to texts. Ready records that attestation per send (who sent, to how many, when) as an audit trail. It is not a per-contact consent record: your own system has to keep each person's opt-in time, wording and source. Compliance is ultimately the sender's responsibility. These tools reduce risk; they don't remove it.

What alerts cost

Ready's Standard rate is $0.0075/segment, plus a $0.0045 carrier fee per segment. Replies you receive are billed the same way.

Worked example: the 5,000-customer outage alert above, kept to one segment, comes to 5,000 × $0.0075, plus 5,000 × $0.0045 in carrier fees. The emoji version is 3 segments, so it triples both. Registration is $25 at submit (the first month). After that it's $25/mo for registration + $2 per number, and most approvals take 2 to 7 days. Enterprise pricing is custom, so talk to us.

Ready's all-in prices per segment include the carrier fee but not screening: Scrub lists and Number validation, the two switches in Settings under Compliance, each add $0.003 per segment when switched on, shown as screening on your bill, and both are off by default. Unless you turn the opt-out footer off, the first text to each contact, and one again from time to time, also gets "Reply STOP to opt out" and your business name if the message does not already have them, so a text close to the segment limit can bill one more segment.

The practical takeaway

A reliable SMS alert system is less about the gateway and more about the plumbing around it:

• Register the use case you actually send.
• Keep alerts to one plain-text segment.
• Send with idempotency keys.
• Do the throughput math before an outage.
• Know when quiet hours hold a message. Campaigns, drip campaigns and automations wait up to 24 hours for the window; a one-to-one or API text is held only if the window opens within 6 hours, otherwise it is refused and must be resent; a one-to-one reply to someone who texted you in the last 24 hours goes out at any hour.
• Build fallback in your own system.

If you want to test the path, Ready's first 20 texts are free one-to-one sends, so use them before you register. To send, you add a card and get a number, which is $2 a month with the first month charged when you get it. You can sign up here and send a test alert to your own phone in a few minutes.