If you were sending SMS through Twilio to Proximus subscribers in Belgium on 27 September, delivery was delayed for 6 hours and 20 minutes. Twilio says it identified the cause on its side and worked through the night to clear it.
Started
23:11 UTC
Duration
Lasted 6h 20m
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: SMS, Europe
What happened?
Twilio's status page shows one incident on this day, affecting SMS delivery from Twilio to Proximus network subscribers in Belgium. It started at 23:11 UTC and was marked resolved at 05:30 UTC, a span of 6 hours and 20 minutes. Twilio posted six updates across that window. The first three, at 23:11, 00:16 and 02:17, all repeat the same line: delays are happening, the cause has been identified, and a fix is in progress, with the next update window stretching from 1 hour to 2 hours and then 4 hours. At 02:18 Twilio reported a recovery in delivery and switched to monitoring stability, then followed up at 04:24 still monitoring before resolving the incident at 05:30. At no point does Twilio name the actual fault, whether it sat with Twilio's platform, with Proximus's network, or with the interconnect between the two. No post-mortem has been published to fill that gap. No user reports were filed during the window on this page, so the only account of impact is Twilio's own. The affected component list names one entry: SMS, Europe.
Learning
Twilio's own probes watch the api component from Europe and North America, and that component held 100% uptime across the 24 hour, 7 day and 30 day windows, with this incident not registered against it. That is not a contradiction. SMS delivery to a specific carrier like Proximus is a downstream path, separate from API availability, and a delay there can sit entirely outside what an API health check or your own endpoint monitoring would ever see. Your integration can report success at the API call level while the message itself stalls somewhere between Twilio and the receiving network. This is the shape to recognise: the request succeeds, the message does not arrive on time, and nothing in your own stack shows why. Twilio's 90 day history lists 528 incidents with a median duration of 5 hours 22 minutes, so a multi-hour SMS delay is not unusual for this path. Your monitoring covers your half, UptimeRobot now watches the provider's half too, so next time you know which side broke without guessing.
