If you send MMS through Twilio long codes to GCI subscribers in the United States, you've likely seen delivery delays since 03:16 UTC on 26 September 2026. The fault sits on Twilio's side of the network, and it was still open as of their last update at 10:31 UTC.
Started
03:16 UTC
Duration
Not closed by vendor
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 opened this incident at 03:16 UTC, reporting that customers "may be experiencing MMS delivery delays from a subset of Twilio Long Codes to GCI network subscribers in the United States." That single sentence is the entire description given throughout the day. Twilio posted five further updates, at 04:17, 06:20, 10:24, 18:25 and 10:31 UTC, each repeating the same wording and each only extending the promised time to the next update, from one hour out to a full 24 hours. No root cause has been given at any point. No component list accompanies this incident, so there is no breakdown of which Twilio or SendGrid services besides MMS delivery are implicated. The incident remains open, with no resolution timestamp on record. Separately, one user report in the window, filed from Brazil at 21:48 UTC, said "Sendgrid website not loading," but Twilio's status page does not tie that to the MMS delay incident, and no update addresses website availability at all. Over the past 90 days SendGrid has logged 206 incidents with a median duration of 5 hours 57 minutes, and across all time it has averaged 8.5 incidents a month, so an incident of this length and vagueness is not unusual for this provider. Twilio's own update cadence here, stretching from hourly checks to a 24 hour gap, suggests this one has been slow to pin down internally as well.
Learning
UptimeRobot's own probes against SendGrid's API, run from both EU and NA regions every 60 seconds, show 100% uptime over the last 24 hours, 7 days and 30 days, and this incident is not registered against that monitoring. That is not a contradiction. The fault described here is MMS delivery to a specific carrier network, GCI, over a subset of long codes, which is a narrow path through Twilio's messaging infrastructure that sits well downstream of the API endpoint your monitoring and UptimeRobot's probes both check. An API can accept and queue a message perfectly while the message itself stalls somewhere in carrier handoff, and that is exactly the shape of failure on record here. If your own product only watches whether your calls to SendGrid succeed, you would see green through this entire incident even as messages to affected GCI subscribers sat undelivered. This is the general pattern worth remembering: delivery failures further down the pipe often don't show up as API errors at all. Your monitoring covers your half, UptimeRobot now watches the provider's half too, so next time you know which side broke without guessing.
