On 29 September 2026, Twilio's Flex Plugins CLI was degraded for 3h 19m, unable to publish plugins. The fault sat on Twilio's side of the Flex Plugins build pipeline, not in your own code.
Started
13:56 UTC
Duration
Lasted 3h 19m
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: Flex Plugins
What happened?
Twilio logged one incident on this day, affecting the Flex Plugins CLI. It started at 13:56 UTC when Twilio reported that the CLI was degraded and could not publish plugins. Twilio said its engineering teams had already identified the issue and were working on a patch, with a follow-up promised within an hour. That follow-up arrived at 14:52 UTC, still showing the same degraded state and no patch yet, with the next update window pushed out to two hours. At 16:43 UTC Twilio moved the incident to monitoring, saying the CLI was operating normally again but that they would keep watching for stability. The incident was marked resolved at 17:12 UTC, 3h 19m after it began. Twilio's resolution note went further than usual: it specified that version 7.1.3 of the Flex Plugins CLI carried the fix, and that anyone affected needed to upgrade to that version to resume publishing. That detail matters, because it means the incident did not simply clear itself when Twilio's systems recovered. If you were blocked on publishing a plugin during the window and never upgraded, you may still be blocked. No user reports were filed during the window on this page. Twilio's status history shows 528 incidents in the last 90 days with a median duration of 5 hours 22 minutes, so this one resolved faster than Twilio's typical incident.
Learning
UptimeRobot's own probes watched Twilio's API component across the EU and North America through this window and recorded 100% uptime for the day, the week and the month. That is not a contradiction. The probes check whether the API responds, and it did. The Flex Plugins CLI is a narrower, specific publishing path that sits on top of the API, and it was the part that broke. A tool used to publish Flex plugins failing to publish is exactly the kind of fault that a general health check cannot see, because the check never attempts the action that was actually degraded. If your own monitoring only watches your endpoints, it will tell you your product is fine while the vendor's internal tooling quietly blocks a specific workflow underneath you. This incident also needed a version upgrade to fully clear, which is not something an uptime check would ever surface. Your monitoring covers your half, UptimeRobot now watches the provider's half too, so next time you know which side broke without guessing.
