On 24 September 2026, Twilio logged nine separate incidents affecting SMS routes across several countries, plus Conversation Intelligence, SendGrid's Link Branding feature, Elastic SIP Trunking and Event Streams. The longest ran 116h 54m, a Brazil SMS delay that Twilio's status page says was resolved in stages. All nine were faults on Twilio's side of the connection.
Started
06:56 UTC
Duration
Lasted 21h 51m
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: SendGrid Email Activity, SendGrid Statistics, SendGrid Marketing Campaigns, Event Webhooks, SMS, Middle East & Africa, Origination US1, Termination US1, Termination AU1, Termination IE1, Origination AU1, Origination IE1, SendGrid Website, Conversation Intelligence, SMS, Europe, SMS, Latin America, SMS, APAC
What happened?
Twilio's status page recorded nine incidents starting at 06:56 UTC and running across 16 components in total. The pattern for the day was regional SMS trouble: delivery failures to Telkomsel in Indonesia, delivery delays to Datora in Brazil, receipt delays to MTN in Cameroon, delivery delays and failures to MTS in Belarus, and receipt delays to Ooredoo in Algeria. Each of these affected one carrier route in one country, not SMS as a whole. The Brazil incident was the longest of the day at 116h 54m, moving through repeated "identified" updates before two separate recovery notices and a final resolved mark. Outside SMS, Twilio also reported a delay in Conversation Intelligence transcript and operator results, an HTTP 500 error on Link Branding creation with Auto SSL enabled, a batch of failing transfer calls in Elastic SIP Trunking with error code 32204, and a service disruption in Event Streams that Twilio said could cause event data loss or delivery delays. Twilio logged 66 status updates across these nine incidents in total. No user reports were filed during the window on this page. Twilio has not published a post-mortem explaining root cause for any of the nine incidents, so beyond the identified/monitoring/resolved labels in its own updates, the cause is not on the record.
Learning
UptimeRobot's own probes against Twilio's API, checked from the EU and North America, stayed at 100% uptime for 24 hours, 7 days and 30 days, and this incident was never registered as ours. That is not a contradiction. These incidents sat in specific carrier SMS routes, a transcription queue, a link branding endpoint, a trunking feature and an event delivery pipeline, none of which is the plain API reachability check that external uptime monitoring runs. A synthetic check from outside can pass cleanly while a message to one carrier in one country sits delayed or undelivered, because the failure lives inside Twilio's delivery or processing path rather than at the front door. If your own product only pings Twilio's API endpoint, you would have seen exactly what UptimeRobot saw here: green, with no sign of the SMS delays your users were actually hitting. Your monitoring covers your half, UptimeRobot now watches the provider's half too, so next time you know which side broke without guessing.
