Twilio, which underpins SendGrid's status infrastructure, logged seven separate incidents on 25 September 2026, all affecting SMS and voice delivery to specific carriers and countries rather than the core API. The longest ran 19 hours 59 minutes, affecting Cellularone subscribers in NE Arizona. None of this was a fault you could have fixed on your end.
Started
02:24 UTC
Duration
Lasted 19h 59m
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 page recorded seven incidents on 25 September 2026, starting at 02:24 UTC with SMS delivery delays from a subset of Twilio Short Codes to Cellularone subscribers in NE Arizona, United States. That incident ran the longest of the day, 19 hours 59 minutes, moving from investigating to identified to monitoring before resolving at 22:23 UTC. A second incident hit SMS delivery from Twilio to Claro subscribers in Brazil, starting at 03:49 UTC and lasting 4 hours 42 minutes. A third affected User Authentication Identity Gateway API calls and latency for Verizon in the United States, running from 06:34 to 12:45 UTC, 6 hours 13 minutes. Later in the day, voice call post dial delay hit a subset of Twilio phone numbers calling into Brazil for 7 hours 50 minutes, and SMS delivery to Etisalat subscribers in the United Arab Emirates was delayed for 7 hours 3 minutes. A sixth incident cut SMS delivery from a subset of Twilio Short Codes to T-Mobile subscribers in the United States for 2 hours 28 minutes. The day closed with a short, separate fault in the Twilio Verify "Try it out" feature for trial accounts, lasting 1 hour 27 minutes. Across all seven, Twilio's own updates describe symptom and scope but never state a root cause. No components are listed as affected on the status page beyond the incident titles themselves, and no user reports were filed during the window on our side. Twilio published 40 status updates across the day; the pattern across incidents is the same each time, investigating, identified or monitoring, then resolved, with no retrospective filed afterwards.
Learning
Every one of these seven incidents was a carrier-specific or feature-specific delivery problem, the kind of fault that lives in the path between Twilio and a mobile network or in a narrow feature like trial Verify, not in the core API surface that uptime checks usually watch. Our own probes against SendGrid's API, run from the EU and North America every 60 seconds, measured 100% uptime over 24 hours, 7 days and 30 days, and that reading is accurate: the API itself answered normally throughout. At the same time Twilio's status page is also accurate in saying SMS and voice calls to specific carriers and countries were delayed or failing for hours. Both things are true because they are measuring different layers, the API endpoint against the downstream delivery path to a named carrier network. If your product sends SMS through Twilio to Cellularone, Claro, Verizon, Etisalat or T-Mobile subscribers, a green API check would have told you nothing about messages stuck in that specific lane. Your monitoring covers your half, UptimeRobot now watches the provider's half too, so next time you know which side broke without guessing.
