Twilio, which operates SendGrid's messaging infrastructure, logged five separate incidents on 2 October 2026, touching SMS delivery to specific carriers, verification failures on AT&T, messaging event processing and Conversations updates. The longest of these ran over eight hours and the last one was still open at 18:44 UTC, the last update Twilio published. The faults sat on Twilio's side of the pipe, not yours.
Started
04:42 UTC
Duration
Lasted 6h 39m
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 five incidents through the day, starting at 04:42 UTC and continuing into the evening. The first was SMS delivery delays from a subset of Twilio phone numbers to Vodafone subscribers in the Netherlands, identified within 16 minutes but not resolved until 11:20 UTC, a span of 6 hours 39 minutes. A second incident, running from 06:56 to 15:04 UTC, covered Silent Network Authentication failures on AT&T in the United States, with Twilio noting that API transactions could fail over to secondary methods like SMS OTP while it investigated. A third incident affected SMS delivery from a subset of Twilio long codes to Telenet BidCo NV subscribers in Belgium, lasting 4 hours 30 minutes. A fourth, shorter incident at 17:21 UTC covered messaging event delays for the Comms API, affecting RCS, WhatsApp Business API and Apple Messages for Business event updates, and also described Bulk Messaging API callers receiving incorrect 400 error responses for Send Messages requests involving recently registered senders. That one closed in 28 minutes. The fifth, opened at 18:29 UTC, covers 500 errors on Conversations updates, affecting updating, deleting and message creation, and remains open with no resolution filed as of the 18:44 UTC update. Twilio's own component list was not broken out by affected component in this record, so the scope of each incident rests on the text of its updates alone. No user reports were filed during the window on this record. Across 22 updates, Twilio gave carrier names, time windows and partial symptom detail, but did not publish a root cause for any of the five incidents.
Learning
UptimeRobot's own probes against the API component, checked every 60 seconds from EU and North American regions, show 100% uptime over 24 hours, 7 days and 30 days, with this incident not registered against that check. That is not a contradiction. The incidents Twilio filed were narrow by design: specific SMS routes to specific carriers in specific countries, a verification method on one US carrier, event processing for particular messaging channels, and errors on one Conversations operation. A synthetic check hitting the general API endpoint from the outside has no reason to see a failure confined to SMS delivery toward one Dutch carrier or to AT&T's SNA path, because the endpoint itself kept answering normally. This is the shape of most provider-side messaging faults: the front door stays open while a specific delivery lane or feature narrows or stalls. If your own product sends SMS, runs verification, or relies on Conversations updates, watching your own endpoints would only tell you that your requests were accepted, not that delivery or processing downstream had slowed. Your monitoring covers your half, UptimeRobot now watches the provider's half too, so next time you know which side broke without guessing.
