Twilio logged four separate incidents on 22 October 2026, touching SMS delivery to carriers in Nigeria and Mali, billing processing, and inbound RCS messaging. One of the four, SMS delays to Malitel subscribers in Mali, is still open. The faults sat on Twilio's side of the platform, not yours.
Started
01:15 UTC
Duration
Lasted 5h 5m
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: PHONE NUMBERS, Speech Recognition (Gather Speech) US1, Realtime Transcriptions US1, Realtime Transcriptions, Intelligent Alerts, SMS, Middle East & Africa, RCS Messaging
What happened?
Twilio's status page recorded four incidents starting at 01:15 UTC and running through the day. The first affected SMS delivery from Twilio to MTN network subscribers in Nigeria, moving from investigating to identified to monitoring before being marked resolved at 06:17 UTC, a span of 5 hours 5 minutes. A second incident, billing processing delays and failures on the platform, opened at 01:29 UTC and was closed 58 minutes later, though Twilio's own final update only says it was "analyzing the impact," not that a fix was confirmed. A third incident hit inbound RCS events, with users seeing elevated HTTP 500 and 503 status codes, identified within minutes and resolved in 46 minutes. The fourth incident, SMS delivery delays and failures to Malitel subscribers in Mali, started at 12:42 UTC and has only one update on record, the initial investigating note. Twilio has not filed anything further on that one, so it is still open as far as the public record shows. None of the four incident pages name a root cause beyond "identified the cause" for the Nigeria SMS issue, without saying what that cause was. No user reports were filed during the window for this page. The affected components list only shows SMS for the Middle East and Africa region and RCS Messaging, which matches the carrier-specific and RCS-specific nature of three of the four incidents. Twilio's 90 day history shows 526 incidents with a median duration of 5 hours 43 minutes, so a day with four separate filings is within its normal pattern rather than exceptional.
Learning
UptimeRobot's own probes against Twilio's API, run from the EU and North America every 60 seconds, show 100% uptime over the past 24 hours, 7 days and 30 days, and none of them registered this incident. That is not a contradiction. These failures were carrier-routing problems (SMS to specific networks in Nigeria and Mali), a billing pipeline issue, and an RCS inbound event delay, none of which touch the core API path that a generic uptime probe checks. Your own monitoring, pointed at your product, would show the same thing: green, because your application layer and the API endpoint were both reachable the whole time. The actual fault sat deeper, in how Twilio routes messages to specific carriers or processes billing and RCS events internally, and that only shows up in Twilio's own status page, not in a ping to their API. If you ship SMS to Nigeria or Mali, or rely on RCS delivery timing, you would have seen delivery delays or failures without any corresponding drop in your own checks. Your monitoring covers your half, UptimeRobot now watches the provider's half too, so next time you know which side broke without guessing.
