Twilio, which underpins SendGrid's messaging infrastructure, 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, affecting Metfone, Viettel, Beeline and Sotelco subscribers in Cambodia, ran 29h 53m. This was carrier-level and network-level trouble on Twilio's side, not anything within your control.
Started
00:43 UTC
Duration
Lasted 11h 58m
Source
IsDown
Next time
SendGrid 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.
What happened?
Twilio's status history for the day shows 13 incidents, most following the same pattern: SMS delivery delays or failures between Twilio and one or two mobile carriers in a single country. Guatemala's Tigo network was hit twice, once at 00:43 for 11h 58m and again at 22:08 for 2h 34m. Other affected routes included Claro in Colombia, Vodafone in the Netherlands, multiple networks in Chile, Wind Tre in Italy, Kolbi in Costa Rica, and a separate Colombia incident covering multiple networks via short codes. The Cambodia incident was the largest, starting at 07:18 and not resolving until 13:09 the next day, 29h 53m later. Twilio's updates on that one show it moved from investigating to identified within an hour, then sat in identified status through several hour-count extensions before Twilio reported a recovery at 06:40 and finally resolved it at 13:09. A separate Messaging Logs API incident, starting 06:12, caused higher latency and errors fetching logs for just under 7 hours, which is an API-layer problem rather than a carrier one. A Lookup API incident affecting Verizon transactions in the United States ran 11h 54m overnight into the next day. One incident, delivery failures from Verify to China, was resolved by Twilio with a note that it determined no customer impact actually occurred. No user reports were filed in this window. Twilio has not published any post-mortem explaining root cause for any of these incidents.
Learning
UptimeRobot's own checks against SendGrid's API stayed green throughout, with 100% uptime over the past 24 hours, 7 days and 30 days, and that reading is accurate: the API itself was reachable and functioning. What broke instead sat further downstream, inside Twilio's carrier interconnects and delivery pipelines for specific mobile networks in specific countries, a layer that an external uptime check against the API endpoint cannot see. If your own monitoring only pings your endpoints or the SendGrid API, it will tell you your integration is up, which it is, while messages to a particular carrier quietly stall or fail for hours. This is the pattern worth recognising: the API accepts the request and reports success, but delivery to the end carrier is delayed or dropped somewhere outside both your system and the API surface. Over the past 90 days Twilio has logged 201 such incidents with a median duration of 5 hours 57 minutes, so this kind of carrier-specific delay is routine rather than exceptional. Your monitoring covers your half, UptimeRobot now watches the provider's half too, so next time you know which side broke without guessing.
