Outage on US Async Endpoint
**Summary** On September 16, 2026, between 20:04 and 21:08 UTC, our US Async API returned elevated server errors. At peak, roughly 50% of async transcription requests on the US endpoint failed, and a portion of the requests that did succeed took longer than usual to complete. Our EU endpoint and real-time/streaming services were not affected. **Root cause** The failure originated in AWS SQS, the managed queuing service our transcription pipeline uses to distribute work. Specifically, the Fair Queues feature began rejecting valid messages with an `InvalidParameterValue` error on a parameter our services had been sending successfully for months. There was no deploy or infrastructure change on our side that triggered this; AWS confirmed it as a service-side issue and rolled back the change on their end later that evening. Because the affected queues sit in the path between our API and our transcription workers, requests that could not be queued failed outright, and a portion of the work t
The latest update from AssemblyAI.
State
Resolved
Started
46 d ago
2026-09-16 20:22 UTC
Lasted
1 h 15 min
until 2026-09-16 21:37 UTC
Worst impact
Major outage
Timeline
7 updatesInvestigating
2 min 3%
Identified
48 min 64%
Monitoring
25 min 33%
Updates
Times in UTCAs posted by AssemblyAI
**Summary** On September 16, 2026, between 20:04 and 21:08 UTC, our US Async API returned elevated server errors. At peak, roughly 50% of async transcription requests on the US endpoint failed, and a portion of the requests that did succeed took longer than usual to complete. Our EU endpoint and real-time/streaming services were not affected. **Root cause** The failure originated in AWS SQS, the managed queuing service our transcription pipeline uses to distribute work. Specifically, the Fair Queues feature began rejecting valid messages with an `InvalidParameterValue` error on a parameter our services had been sending successfully for months. There was no deploy or infrastructure change on our side that triggered this; AWS confirmed it as a service-side issue and rolled back the change on their end later that evening. Because the affected queues sit in the path between our API and our transcription workers, requests that could not be queued failed outright, and a portion of the work t
The issue, which was the result of an AWS service issue, has been resolved and we have continue to see good performance since implementing a fix so we are now closing this issue.
We have mitigated the issue and our Async API service is recovering.
We are seeing a reduction in the number of errors, but we are still working to fully resolve the issue.
We are continuing to investigate these elevated errors. We will provide an update as soon as possible.
The issue has been identified. This is affecting approximately 50% of all async transcriptions on the US endpoint.
We are currently investigating an issue that is affecting all customers using our Async API on our US endpoint. Users will be receiving a server error. We will update with more information as we learn more. This began at 8pm UTC.
Affected components
1AssemblyAI in the last 90 days
Full historyIncidents in 90 days
13
Days with an incident
10
Median duration
31 min
This incident
2.4× the median
Other AssemblyAI incidents
All incidentsAssemblyAI·Real-time STT: 502 errors related to change to temporary tokens
We have continued to see good performance after the rollback and are now marking this issue as resolved.
AssemblyAI·Increased Processing Times and Errors on EU Endpoint for Universal-3 Pro Async model
This incident has been resolved. Between approximately 15:05 and 15:45 UTC, async transcription requests using Universal-3 Pro on our EU endpoint took longer than usual to complete, and some requests failed. Processing times have returned to normal ranges and any requests that failed during this window can be safely resubmitted.
AssemblyAI·Increased Processing Times and Errors on US Endpoint for Universal-3.5 Pro Async model
This incident has been resolved. Between approximately 1:35p and 2:20p UTC, async transcription requests using Universal-3.5 Pro on our US endpoint took longer than usual to complete, and some requests failed. Processing times have returned to normal ranges and any requests that failed during this window can be safely resubmitted.
AssemblyAI·Rejected Sessions on US Endpoint for Universal-3.6 Pro Realtime Model
From 10:30a - 12:30a UTC users experienced rejected connections when connecting to our Realtime Universal-3.6 Pro model on our US endpoint. Users received a 3005 Session Cancelled error message on connection. This issue has been resolved and the Realtime US endpoint for Universal-3.6 Pro is functioning normally. The EU Realtime endpoint was not affected.
AssemblyAI·Increased processing times and errors for Universal-3.5 Pro on the EU async endpoint
This incident has been resolved. Between approximately 08:20 and 10:45 UTC, asynchronous transcription requests using Universal-3 Pro and Universal-3.5 Pro on our EU endpoint took longer than usual to complete, and some requests failed. Processing times have returned to normal ranges. Any requests that failed during this window can be safely resubmitted.
Follow AssemblyAI
Your coding agent knows when AssemblyAI is down, and tells you when a failure is theirs, not yours. You can also get AssemblyAI 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 "assemblyai" and tell me if AssemblyAI 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=assemblyai/feed subscribe https://outages.cc/feed.xml?providers=assemblyaiFAQ
Go from tracking outages to fixing production issues with Polylane.
Try Polylane