Outage of some public API endpoints on Nov 2
Telnyx public API endpoints had an outage on Nov 2. User authentication was mainly affected. No calls or messages were affected. Telnyx reports that the incident is resolved. The cause was identified and a fix is in place.
State
Resolved
Started
2 h ago
2026-11-02 19:58 UTC
Lasted
16 min
until 2026-11-02 20:14 UTC
Worst impact
Notice
Timeline
2 updatesMonitoring
16 min 100%
Updates
Times in UTCAs posted by Telnyx
The cause of the problem was identified and a fix has been in place and tested. The incident has been resolved. Thank you and we apologize to those not able to log in during the affected window.
There was outage on Nov 2 from 19:47 UTC to 19:54 UTC on some Telnyx API endpoints. We are still determining the total scope and impact, but indications are that it was primarily around user authentication. No calls or messages were affected. We apologize for any interruptions.
Telnyx in the last 90 days
Full historyIncidents in 90 days
25
Days with an incident
19
Median duration
2 h 34 min
This incident
90% shorter than the median
Other Telnyx incidents
All incidents
Telnyx·Messaging API Latency
Telnyx reports latency on the Messaging API and on webhook delivery for delivery receipts. Message sending is not affected. Telnyx is still investigating.
Telnyx·Messaging Webhook Delays
We believe the issue is now resolved
Telnyx·Delays with Messaging Webhooks, Mission Control Number and Porting ordering/configurations
Our team found the root cause of this issue to be due to a network blip leading to various service issues. It was confirmed to be brief and all services are now caught up as of 15:15UTC.
Telnyx·Telephony tokens 503s error
A rollback was applied at ~15:54 UTC and credential creation has been healthy since 15:58 UTC.
Telnyx·Unexpected wireless voice usage and charges
Resolved
Follow Telnyx
Your coding agent knows when Telnyx is down, and tells you when a failure is theirs, not yours. You can also get Telnyx incidents in a feed reader or in Slack.
Install the outages.live MCP server, so that when something breaks you can tell if the cause is a provider we depend on and not my code. It reads the official status pages of cloud, AI, payment and developer providers and gives you their incidents as MCP tools.
Add it as a remote MCP server named "outages" at https://outages.cc/mcp (Streamable HTTP, no authentication), with your CLI command or your MCP config file.
Then:
1. Make sure it connects and shows the tools get_provider, list_feed and send_feedback.
2. Call get_provider with "telnyx" and tell me if Telnyx has a problem right now.
3. From now on, when a call to a third-party service fails or becomes slow, call get_provider for that service before you change my code.Paste this into any coding agent. It adds the server with its own MCP setup.
https://outages.cc/feed.xml?providers=telnyx/feed subscribe https://outages.cc/feed.xml?providers=telnyxFAQ
Go from tracking outages to fixing production issues with Polylane.
Try Polylane