Live

Elevated errors and delays for Universal-3 Pro, Universal-3.5 Pro and Universal-3.6 Pro

0

AssemblyAI reports elevated errors and delays for pre-recorded transcription requests that use Universal-3 Pro, Universal-3.5 Pro and Universal-3.6 Pro in all regions. The Asynchronous API is affected. Streaming is not affected. AssemblyAI reports that error rates and processing times are back to normal, and it is monitoring for stable performance.

State

Monitoring

Started

1 h ago

2026-11-02 21:42 UTC

Ongoing for

1 h 11 min

Worst impact

Degraded

Timeline

4 updates
21:4222:0022:1822:3622:53
DegradedUpdate postedTimes in UTC

Identified

1 h 5 min 92%

Monitoring

6 min 8%

Updates

Times in UTC

As posted by AssemblyAI

Monitoring2026-11-02 22:48 UTC

Error rates and processing times have returned to normal. We're monitoring to make sure performance remains stable.

Identified2026-11-02 22:45 UTC

We've applied a fix and error rates have dropped significantly. Some pre-recorded requests using Universal-3 Pro, Universal-3.5 Pro and Universal-3.6 Pro may still take longer than usual to complete while we work through the backlog.

Identified2026-11-02 22:09 UTC

Error rates are decreasing as our rollback progresses, and we're continuing to work on fully resolving the issue. Some requests may still fail or take longer than usual to complete.

Identified2026-11-02 21:45 UTC

We've identified an issue causing a significant portion of pre-recorded transcription requests using Universal-3.5 Pro and Universal-3.6 Pro to fail or take longer than usual to complete, across all regions. Streaming is not affected. We've identified the cause and are rolling back a recent change, and we're beginning to see recovery.

Affected components

2
Asynchronous APIAPIs - Asynchronous API

AssemblyAI in the last 90 days

Full history
90 days agoToday

Incidents in 90 days

13

Days with an incident

11

Median duration

28 min

This incident

2.5× the median

How long each incident lasted, on the day it started. The outlined bar is this incident.

1 h 18 min
median 28 min
90 days agoToday

Other AssemblyAI incidents

All incidents

AssemblyAI·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.

Resolvedresolved 5 d ago

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.

Resolvedresolved 27 d ago

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.

Resolvedresolved 27 d ago

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.

Resolvedresolved 28 d ago

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.

Resolvedresolved 28 d ago

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.

Prompt
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.

RSS
https://outages.cc/feed.xml?providers=assemblyai
Slack
/feed subscribe https://outages.cc/feed.xml?providers=assemblyai

FAQ

Go from tracking outages to fixing production issues with Polylane.

Try Polylane