← Back to Monitoring GuidesDeveloper Tools

When Twilio Goes Down: A Survival Guide for Your Team

Signups dropped to zero an hour ago. Not slowed — zero. You dig in: new users register, reach the phone verification step, and never receive their SMS code. Without the code, they can't finish signing up. Twilio's SMS delivery is degraded in your users' region, and every verification message is stuck in a queue.

What Happens on Your Team

The Full-Stack Developer

Notices the signup funnel is broken at the verification step. Checks the app — it's sending the SMS requests to Twilio, getting 201 Created responses. So the API works. But messages aren't arriving. The issue is downstream delivery, not the API call itself.

The real cost: Twilio failures are often subtle. The API can accept your request (201 Created) while actual message delivery fails or delays. Your code looks like it's working — it got a success response — but users never receive anything. This is the hardest kind of failure to detect.

What they should have had: A monitor on Twilio's API endpoint plus tracking of your own delivery webhook. When delivery callbacks stop arriving or report failures, you know the problem is delivery, not your code — and you can warn users or switch to a fallback.

The Product Manager

Gets escalated a support theme: 'I'm not getting my 2FA code.' Dozens of tickets. Checks with engineering — the app is sending codes. Spends an hour confirming it's a Twilio regional delivery issue, not a bug in their auth flow.

The real cost: When 2FA codes don't arrive, users are locked out entirely. They can't log in, can't reset, can't do anything. Every minute of SMS delivery failure is a wall of locked-out users and support tickets — and the team burns time confirming it's not their fault.

What they should have had: Monitoring on Twilio's status and the app's SMS-sending endpoint. When delivery degrades, the alert fires. The team posts a status update ('SMS codes may be delayed') and offers an alternate login path — instead of fielding tickets blind.

The On-Call Engineer

Twilio had a 20-minute API outage at 2 AM. Voice calls and SMS both failed. By the time anyone checked in the morning, it had recovered. The only evidence was a gap in sent messages and a cluster of failed-delivery logs overnight.

The real cost: Communication API outages are transient and easy to miss after the fact. If nobody was watching during the window, the outage is invisible — except for the users who needed a code at 2 AM and couldn't get one.

What they should have had: Continuous monitoring with incident history. Even a self-resolving Twilio outage gets recorded — when it started, how long it lasted. That history informs whether you need a backup SMS provider for critical flows like authentication.

Why Monitor Twilio?

Twilio powers critical flows — SMS verification codes, two-factor authentication, appointment reminders, alerts. When Twilio has issues, your users can't receive login codes, your notifications silently fail, and you may not notice until signups drop or complaints roll in.

What to Monitor

your-app.com/api/sms-healthApp endpoint that checks Twilio API reachability

status.twilio.comTwilio's own status for regional and service-level incidents

your-app.com/api/webhooks/twilioYour webhook receiver for Twilio delivery callbacks

What You Should Actually Do

1Create an app endpoint that checks Twilio API reachability and monitor it externally
2Monitor your Twilio delivery webhook receiver — if delivery callbacks stop, message delivery may be failing even when the API accepts requests
3Track Twilio's official status page for regional SMS and voice incidents
4For critical flows like 2FA, consider a fallback provider — and monitor both so you know when to switch
5Set up alerts that reach a channel other than SMS — if Twilio is down, an SMS-based alert won't reach you

Twilio's Official Status Page

Twilio publishes real-time status at status.twilio.com. Monitoristic doesn't replace this — it complements it. The official page tells you when Twilio reports an issue. Your own monitor tells you when your connection is affected, often before the status page updates. You also get push alerts instead of checking a webpage manually.

Twilio sits in the middle of your most critical user flows — verification, authentication, alerts. When it fails, users get locked out and you often can't tell whether it's your bug or Twilio's outage. Monitoring both the API and your delivery webhooks gives you the answer fast, so you can communicate and fall back instead of debugging blind.

Frequently Asked Questions

Can I monitor Twilio's SMS delivery directly? +

You can monitor Twilio's API reachability with an HTTP check, and you can track your delivery webhook to see if status callbacks are arriving. Actual end-to-end delivery is harder to test automatically, but monitoring the API plus webhook callbacks catches most issues.

Why do my SMS messages get accepted but not delivered? +

Twilio's API returning 201 Created means it accepted your request, not that the message was delivered. Delivery can still fail or delay due to carrier issues, regional outages, or filtering. Monitor your status callback webhook to detect delivery failures.

How should I alert myself if Twilio is down? +

Don't rely on SMS alerts for Twilio outages — if Twilio is down, the alert won't arrive. Use Telegram or webhook-based alerts (to Slack/Discord) so your downtime notifications don't depend on the service that's failing.

How is this different from status.twilio.com? +

Twilio's status page reports platform-wide incidents by service and region. Your monitor checks how Twilio is working for YOUR app specifically — whether your API calls succeed and your delivery callbacks arrive. Account-specific issues like rate limits or number problems won't appear on Twilio's status page.