If you send MMS over Twilio Long Codes to GCI subscribers in the United States, messages have been delayed since 03:16 UTC on 26 September 2026. Twilio has confirmed the fault on its side and the incident is still open, with no resolution filed as of the last update at 10:31 UTC.
Started
03:16 UTC
Duration
Not closed by vendor
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: MMS Long Code, North America
What happened?
Twilio's status page opened this incident at 03:16 UTC, describing MMS delivery delays from a subset of Twilio Long Codes to GCI network subscribers in the United States. One component is listed as affected: MMS Long Code, North America. Twilio posted six updates over the course of the day, at 03:16, 04:17, 06:20, 10:24, 18:25 and 10:31 UTC, and every one of them repeats the same wording almost verbatim: customers may be experiencing delivery delays, the team is investigating, another update will follow. None of the six updates narrows the cause, names a fix, or gives a count of affected messages. The gap between updates stretched from one hour early on to as long as sixteen hours by the 18:25 posting, which tells you Twilio itself had nothing new to report for long stretches of the day. No resolution has been filed, so the incident remains open with the last word dated 10:31 UTC. No user reports were filed during this window on our side, which is consistent with this being a narrow, carrier-specific delay rather than a broad outage of the MMS path. This is a single-incident day, affecting one component, tied to one specific downstream carrier.
Learning
Twilio's own probes watch the API layer across the EU and North America, and they show 100% uptime over the last 24 hours, 7 days and 30 days, with this incident not even registered against that check. That is not a contradiction. The fault here sits in message delivery to a specific carrier network, GCI, not in whether the Twilio API accepts and answers your requests. Your API calls can succeed every time while the messages they trigger sit delayed somewhere between Twilio and that carrier's network. This is the shape to recognise: the layer you can ping from outside stays healthy while a narrower delivery path downstream breaks, and nothing in a simple HTTP check would ever show it. Twilio's own history over the last 90 days includes 530 incidents with a median duration of 5 hours 20 minutes, so delays of this kind are not rare for this provider. Your monitoring covers your half, UptimeRobot now watches the provider's half too, so next time you know which side broke without guessing.
