Twilio logged five separate incidents on 28 September 2026, hitting SMS delivery in Spain and Brazil, voice calls to Vodafone UK, and a brief Flex alert. The longest, an SMS delivery receipt delay to CTBC network subscribers in Brazil, ran for 40h 23m before Twilio marked it resolved. All five were faults on Twilio's side, not yours.
Started
08:26 UTC
Duration
Lasted 5h 12m
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: Flex Application Platform, SMS, Latin America, Voice, Europe, SMS, Europe
What happened?
Twilio's status page recorded five incidents starting at 08:26 UTC and running into the next day. The first was SMS delivery failures from Twilio to multiple networks in Spain, opened at 08:26 and resolved 5h 12m later after Twilio reported a recovery and then confirmed normal service. The second affected voice calls from a subset of Twilio mobile numbers to Vodafone subscribers in the United Kingdom, starting at 10:45 and lasting 16h 57m, with four separate investigating updates before Twilio observed recovery and later resolved it. The longest ran from 13:25 to the following day, a 40h 23m stretch of SMS delivery receipt delays from Twilio to CTBC network subscribers in Brazil. Twilio's own text on that one is specific: message delivery itself could still succeed, but the receipts confirming delivery were delayed, and Twilio said it had identified the cause at 14:12 yet kept pushing the next update window out to as long as 24 hours before monitoring and then resolving it. A fourth incident was a Flex Application Platform alert that Twilio's own engineers investigated and closed within 1h 55m, stating plainly that there was no noticeable customer impact. A fifth entry logged a Bulk Messaging API problem with elevated HTTP 503 errors and timeouts, but the dates in that filing point back to 16 September, not the 28th, so treat it as a late write-up of an older event rather than a same-day fault. No user reports were filed during this window. Twilio's status page is the only record here, and each entry above reflects what that page said and when, not what any customer reported.
Learning
UptimeRobot's own probes against Twilio's API, run from the EU and North America, showed 100% uptime across the last 24 hours, 7 days and 30 days, and none of them registered against this incident. That is not a contradiction. A basic API health check can return a normal response while a specific route, like SMS delivery to networks in Spain or Brazil, or voice termination to one UK carrier, fails for Twilio's downstream partners. These are routing and carrier-interconnect problems inside Twilio's network, the kind of fault that sits below the layer a simple reachability check can see. If your own monitoring only watches your endpoints calling Twilio's API, you will see green while your messages or calls quietly fail to land. That is the gap this kind of day exposes: your dashboards and Twilio's status page can both be telling the truth at the same time, about different layers. Your monitoring covers your half, UptimeRobot now watches the provider's half too, so next time you know which side broke without guessing.
