Twilio logged 13 separate incidents on 30 September 2026, nearly all of them SMS delivery delays or failures to specific carriers in specific countries. The longest ran 29 hours 53 minutes, affecting delivery to Metfone, Viettel, Beeline and Sotelco subscribers in Cambodia, and the fault sat with Twilio's carrier routes, not with your own setup.
Started
00:43 UTC
Duration
Lasted 11h 58m
Source
IsDown
Next time
Twilio is degraded. Is your product working?
An incident on their side does not always mean an outage on yours, and the only way to know is to already be watching your own endpoints. Set that up in under a minute and you will be notified the next time your own site is affected. And there will be a next time.
50 monitors for your own websites. No card.
Affected components: Lookup SIM Swap, Legacy Identity MatchAndAttributes, SMS, Latin America, SMS, Europe, Verify, SMS, APAC, SMS
What happened?
Twilio published 73 status updates across 13 incidents on this day, and the pattern was consistent: SMS messages failing or delaying to one carrier in one country, while everything else kept working. Guatemala's Tigo network was hit twice, once for 11h 58m starting at 00:43 and again for 2h 34m starting at 22:08. Colombia saw delays to Claro short codes for 3h 39m and separately to multiple networks for 8h 13m. The worst single incident was the Cambodia one, affecting Metfone, Viettel, Beeline and Sotelco subscribers, running from 07:18 to a resolution the next day, 29h 53m later. Twilio's updates on that incident show it moving through investigating, identified, and two separate monitoring stages before resolving, which tells you the fix was not immediate even once the cause was known internally. A separate Messaging Logs API incident ran 6h 58m, meaning customers trying to check delivery logs for other messages may have hit errors on top of whatever carrier delay they were already dealing with. The Verify incident affecting China lasted only 1h 18m and Twilio's own resolution note says it determined there was no customer impact, which is a stronger read than most of their closures. The Verizon Lookup API incident ran 11h 54m with elevated failures and latency, separate from the SMS issues entirely. No user reports were filed during this window, and no post-mortem has been published for any of the 13 incidents.
Learning
Twilio's own 30 day history shows 528 incidents with a median duration of 5 hours 22 minutes, so a day with 13 incidents and one running nearly 30 hours is within the range this provider operates in, not a one-off. UptimeRobot's probes against Twilio's API stayed at 100% uptime over 24 hours, 7 days and 30 days, and that is correct: these probes check whether the API responds, not whether a message actually lands on a specific carrier's network in Cambodia or Colombia. A failure like this lives entirely downstream, in the handoff between Twilio and a local mobile operator, which is invisible to any check that only confirms the API accepted your request. If your own monitoring watches your endpoints and your integration with Twilio, it will show green through exactly this kind of outage, because your code did its job correctly. The lesson is to treat carrier-specific delivery delays as a distinct failure mode from API availability, and to expect Twilio's own status page, not your dashboards, to be the first place such a problem shows up. Your monitoring covers your half, UptimeRobot now watches the provider's half too, so next time you know which side broke without guessing.
