If you just want the recommendation: send the SMS first, poll its delivery status yourself, and let your own timer — not the provider — decide when the email fallback goes out. For urgent event notifications from a Node.js service, that's the entire design. The retry logic is boring on purpose, and boring is what you want at 3am.
I run a one-person SaaS. Every hour spent on notification plumbing is an hour not spent on something a customer actually asked for, so my bar is simple: write it once, in about sixty lines, never think about it again.
It took one bad night to get there. I had an incident alerter that posted an SMS and logged alert sent on a 200. I assumed a 200 meant delivered. It doesn't — it means accepted. The number had opted out of my alerts six weeks earlier, the carrier never delivered anything, and I found out about the outage roughly 3 hours later from the customer's own email, which is the single most expensive way to learn that your alerting works only on the happy path. The send call was fine. My reading of it was wrong.
How should I send an urgent event notification by SMS first and fall back to email?
Three states and one clock. The SMS is pending until a status poll says otherwise, delivered closes the incident, and anything else — suppressed number, carrier rejection, or simply nothing by the deadline — opens the email leg.
