On 1 October, Twilio (whose status page also covers SendGrid) filed six separate incidents affecting SMS and voice delivery to specific carriers and countries, running from 00:26 to past midnight. The longest, a voice call failure and delay issue to DigiMobil in Spain, ran 12h 14m. All six were carrier-side or network-routing problems on Twilio's own infrastructure, not faults in your account.
Started
00:26 UTC
Duration
Lasted 7h 24m
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 logged six incidents through the day, each tied to a specific carrier route rather than the platform as a whole. The first, starting at 00:26, covered SMS delivery delays from Twilio to Algar Telecom (CTBC) subscribers in Brazil, running 7h 24m before resolving at 07:35. A second, starting at 08:32, hit SMS delivery to DigiMobil (Movistar) subscribers in Spain, lasting 4h 54m. Around the same window, a third incident starting at 09:35 affected SMS delivery receipts from a subset of Twilio short codes to multiple US networks, running 3h 12m, with Twilio noting that message delivery itself could succeed even while receipts lagged. The longest incident of the day started at 10:40: voice call failures and post dial delay from Twilio phone numbers to DigiMobil subscribers in Spain, lasting 12h 14m and passing through three separate "monitoring" updates before final resolution at 22:51, which suggests the fix did not hold on the first or second attempt. A fifth incident, starting at 18:38, affected A2P campaign registration submissions generally rather than a single country, lasting 4h 57m. The sixth, starting at 23:01, covered SMS delivery delays from a subset of Twilio phone numbers to Jio subscribers in India, running 7h 41m into the next day. Across all six, Twilio's updates named the cause as "identified" in most cases but never published what the underlying fault actually was. No user reports were filed in this window. Twilio's own 90 day history on this status page shows 204 incidents with a median duration of 5 hours 57 minutes, so a day with six carrier-specific incidents is within the pattern this account typically shows, not an anomaly.
Learning
UptimeRobot's own probes against the API component, run from both EU and North America regions, stayed at 100% uptime across 24 hours, 7 days and 30 days, and none of the six incidents were registered against that probe. That is not a contradiction. These incidents were carrier-specific routing problems, affecting SMS and voice delivery to named networks in Brazil, Spain, the US and India, which sit downstream of the API endpoint that external monitoring checks. A simple API health check can return a clean 200 response while a message queued against it silently stalls or fails on its way to a specific mobile network. This is the shape of failure to watch for with any messaging provider: the control plane answers normally while the delivery path to one carrier degrades. Watching your own endpoints only tells you that your request was accepted, not that it arrived. Your monitoring covers your half, UptimeRobot now watches the provider's half too, so next time you know which side broke without guessing.
