SMS delivery is not deterministic: routing defines behavior
blog.bridgexapi.io
blog.bridgexapi.io
https://www.schneier.com/blog/archives/2016/08/nist_is_no_lo...
I have yubikeys. Lots of people can do authenticator codes on their phones. Stop using SMS already. As you're discovering, it's garbage for that purpose, even for you as the developer. Even emailing the code would be better.
I think what’s interesting is that a lot of systems still rely on it anyway (reach, fallback, onboarding), but treat it like it’s deterministic.
In practice, I’ve seen more issues from unpredictability than just security — timing, routing behavior, stuff you can’t really see.
So even if teams accept the trade-offs, they still don’t really understand how delivery behaves.
Have you seen similar issues in systems that still use SMS as fallback?
Hourly, the shortest lead time was one hour. And you're talking about 45 seconds.
What you’re describing is kind of what I keep running into too — people don’t really try to understand delivery, they just design around the fact that it’s unreliable.
Longer lead times, retries, fallback channels, etc.
Which works, but it also means the actual behavior stays a black box.
Did you ever notice differences between providers or routes, or was it basically opaque the whole time?
Everything is unreliable. Always design for unreliable. That's my major gripe with most docs and tutorials from any of these services. They only describe what happens during success. They never go into detail on what happens when things go wrong. Your only option is to wait for it to blow up and learn from experience. In the meantime, assume it is going to blow up, try to catch it and log as much of the blowup as possible. Never assume it will work. Assume it won't work and be happy when it does.
This is why you should lean toward something like an authenticator. You can control the whole experience. Rely on unreliable services as little as you can.
Most APIs expose sending, but hide execution.
You submit a message and get "delivered" back, but everything that actually determines behavior is hidden: routing, timing, execution path.
This becomes a real problem in systems like OTP, fraud alerts or transactional messaging, where timing matters more than delivery itself.
The same request can behave differently across executions, but without visibility into routing, you can’t explain or control it.
This post breaks down why that happens and what control actually means at the infrastructure level.
How do people debug delivery issues today when timing is inconsistent?
Most tools seem to expose status, but not execution.
Curious how others approach this in production systems.