Here's a thing that quietly breaks incident response: your alerting email is technically "delivered" the moment it hits the recipient's mail server, but it isn't seen until someone opens it. Between greylisting, spam scoring, retry backoff, and the fact that a decent chunk of alert email lands in a folder nobody watches, the gap between "sent" and "read" can stretch from seconds to hours. For a marketing digest, fine. For an outage at 2:14 AM, that gap is your SLA leaking.
Full disclosure: I work for Ready, an SMS platform. So I have an obvious bias toward "text them." But I'm not going to pretend SMS is the answer for every alert — most of your notifications should stay in email or Slack, and I'll draw that line explicitly below. This is a channel-selection guide, not a sales pitch to text everyone about everything.
The two numbers that decide the channel: latency and open rate
Every alert has an implicit deadline. The question is whether email meets it.
- Latency. SMTP is a store-and-forward protocol with retries measured in minutes, not milliseconds. A well-tuned pipeline usually delivers in seconds, but "usually" isn't a guarantee, and greylisting alone can add a first-attempt delay of a minute or more. SMS on registered 10DLC routes generally lands in a few seconds and — critically — surfaces on the lock screen without anyone opening anything.
- Open rate. Opted-in SMS gets read at rates people usually estimate in the 90%+ range, most within a couple of minutes. Alert email — especially automated, no-reply, high-volume alert email — routinely sees open rates that are a fraction of that. Frame these as rough industry approximations, not lab numbers, but the direction is not in dispute.
So the decision rule is simple: if the alert has a tight deadline AND the recipient reading it is the action, SMS earns its place. Otherwise, don't spend a segment on it.
Which alerts justify SMS
Sort your alerts by "what happens if this is seen 30 minutes late." The ones where 30 minutes of delay is a real cost belong on SMS.
| Alert type | Deadline sensitivity | Channel |
|---|---|---|
| Production outage / hard down | Minutes | SMS (+ pager) |
| Security event (new admin, suspicious login, key leaked) | Minutes | SMS |
| Payment failure on a live account | Hours, but recovery decays fast | SMS |
| Usage limit hit / quota exhausted (mid-run) | Minutes to hours | SMS |
| Approaching usage limit (80%) | Days | Email / in-app |
| Weekly uptime summary | None | Email digest |
| Feature announcement | None | Email / in-app |
| Failed background job (retryable) | Low | Slack / email |
The pattern: SMS for the events where a human's fast reaction changes the outcome. The failed-payment case is its own worked example — we've written up the dunning window math and the recovery timing separately, but the short version is that recovery odds decay by the hour, which is exactly the profile that argues for a channel that gets read now.
The alerts that should NOT go to SMS
This is where a lot of teams overreach and start earning opt-outs on a channel that's supposed to be sacred.
- Anything on a digest cadence. If it can wait until morning, it can be an email. Nightly rollups, weekly reports, "here's what changed" — none of these have a deadline.
- Retryable, self-healing errors. A background job that failed and will retry doesn't need to wake anyone. Route it to Slack or a log.
- Low-severity warnings. "You're at 80% of your quota" is a heads-up, not an emergency. Email it.
- Anything that isn't actionable by the recipient. If the person getting the text can't do anything about it, you're just training them to ignore the channel.
The failure mode is predictable: teams wire up SMS for outages, it works, so they start piping everything through it. Six weeks later the on-call engineer has muted the sender and the one alert that mattered goes unread. Guard the channel.
Consent scoping: transactional alerts are not marketing, but you still need it right
Here's the nuance product teams get wrong. Critical system alerts to your own users about their own account are transactional — they're not the same consent bucket as marketing blasts. But "transactional" is not a magic word that exempts you from everything.
A few things to get right:
- Scope the opt-in at signup or in settings, and keep the two consents separate. A user agreeing to receive outage and security alerts about their account is not agreeing to receive your product-launch texts. Track them as distinct permissions so a marketing STOP doesn't kill their security alerts — and vice versa.
- Honor STOP regardless. Ready's automatic STOP/opt-out handling propagates an opt-out so the contact can't be messaged again. If a user opts out of everything, respect it, and make sure your product surfaces an alternate channel (email, in-app) so they're not flying blind on security events.
- Quiet hours are trickier for alerts. Marketing sends get held outside permitted local hours automatically — that's a TCPA exposure reducer and the right default. But a genuine security or outage alert is arguably time-critical enough to override quiet hours if your consent language and use case support it. Don't assume; scope it deliberately and document why. If you're new to this, the quiet-hours rules explainer is worth a read before you flip that override on.
Either way you'll need proper 10DLC registration behind the traffic, because unregistered A2P gets carrier-filtered and your "critical" alert never arrives — which defeats the entire point. The SaaS-specific 10DLC guide covers what to register and how the campaign types map to alert traffic.
Throughput: can the channel actually keep up during a real incident?
The ugly truth about outage alerts is that they arrive in bursts. A regional failure doesn't page one customer — it pages hundreds simultaneously, and every second of send latency compounds the delay you were trying to avoid.
Ready runs over multiple carrier providers for redundancy, which matters more for alerting than for marketing: if one route degrades, you don't want your incident notifications degrading with it. Registered 10DLC throughput scales with your brand's trust score, and higher-volume senders can raise their daily limits with optional brand vetting ($40 Standard / $100 Enhanced, one-time) — worth it if you're fanning out large alert bursts, unnecessary for most.
The point isn't a throughput number I can promise you. It's that alerting is the one use case where you should size your registration and route redundancy for the worst moment, not the average one.
A worked cost example
Say you're a SaaS with 8,000 active accounts and you send critical alerts only — call it an average of 2 alert texts per account per month across outages, security events, and payment failures. Most alerts fit in one 160-character GSM-7 segment; assume a modest 1.3-segment average for the longer security messages.
- 8,000 accounts × 2 alerts × 1.3 segments = 20,800 segments/month
- On Ready Standard: 20,800 × ($0.02 + $0.0045 carrier) = 20,800 × $0.0245 = ~$510/month
That's well under the 50,000-segment threshold where the Growth rate ($0.016/segment, applied automatically) kicks in. If your alert volume ever crosses that line in a calendar month, the discount applies on its own — you don't pick a plan. For a channel that measurably shortens your incident response and recovers failed payments, $510 to reach 8,000 accounts reliably is not the line item to optimize. You can sanity-check your own numbers against current pricing.
The practical takeaway
Route by deadline, not by habit. Outages, security events, and live payment failures — where a human reading it in minutes changes the outcome — belong on SMS. Digests, retryable errors, and low-severity warnings belong in email or Slack, and keeping them there is what protects the SMS channel's near-100% read rate.
Scope your consent so transactional alerts and marketing sends live in separate buckets, register your 10DLC properly so the alerts actually deliver, and size your throughput for the incident, not the average day.
If you want to wire this up, Ready ships the 10DLC registration, STOP handling, quiet-hours controls, and multi-carrier routing in one place — you can start with 2,500 free credits, no card required, and test a real alert path before you commit a single production notification to it.