SMS messages sent through Twilio, which underpins SendGrid's messaging stack, were delayed in reaching Proximus network subscribers in Belgium for 6 hours and 20 minutes. The fault sat inside Twilio's delivery path to a specific carrier, not in your own integration.
Started
23:11 UTC
Duration
Lasted 6h 20m
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?
The incident began at 23:11 UTC with Twilio reporting SMS delivery delays specifically between Twilio's network and Proximus subscribers in Belgium. Twilio said the cause had been identified from the first update, but it did not name that cause in any of the six updates it posted. Over the next three hours it repeated the same holding message twice, at 00:16 and 02:17, each time pushing the next check further out, first by one hour then by two then by four. At 02:18 UTC, one minute after the third identified update, Twilio reported a recovery and moved to monitoring service stability, then posted a second monitoring update at 04:24. The incident was marked resolved at 05:30 UTC, giving a total span of 6 hours and 20 minutes from first report to resolution. No components are listed as affected on SendGrid's own status breakdown for this entry, and no user reports were filed during the window. This was a single, isolated incident for the day, not a cluster of separate problems. Twilio's own history shows this kind of thing is not rare: 201 incidents logged in the last 90 days, with a median duration of 5 hours 57 minutes, so this outage ran close to that typical length rather than standing out as unusually long or short. At no point did Twilio publish a root cause, so if you are trying to explain this to your own users, the honest answer is that the cause is not on the record.
Learning
UptimeRobot's own probes against SendGrid's API, run from EU and North America every 60 seconds, stayed at 100% uptime through this entire window, and that reading is accurate: the API itself was reachable and responding. What broke was not the API but a narrower delivery path, SMS routing from Twilio specifically to one carrier, Proximus, in one country, Belgium. A synthetic check against an API endpoint has no way to see that kind of carrier-specific delay, because the request succeeds, the message queues, and the failure happens downstream in telecom routing that your monitoring never touches. This is a common shape for messaging outages: the control plane looks fine while a specific delivery lane is degraded, and the two facts do not contradict each other, they describe different layers. If your product sends SMS through Twilio to Belgian numbers and users complained of delays that night, your own uptime dashboard would have shown green the whole time, and that is expected, not a bug in your monitoring. Your monitoring covers your half, UptimeRobot now watches the provider's half too, so next time you know which side broke without guessing.
