Processes are continuing to work normally, and all affected accounts have been fixed, so we are not moving this issue to resolved.

This incident is resolved. To summarize, this incident began at 9am UTC and a fix was implemented around 10am UTC. This incident affected async requests to our EU endpoint and resulted in an increase in processing time and errors.

This incident has been resolved.

We have continued to see processing times remain in the normal range and are now marking this issue as resolved.

The issue affecting async transcription processing has been fully resolved. All systems are operating normally. We apologize for the disruption to your workflows. If you have any questions, please reach out to support@assemblyai.com.

Resolved – Content Safety Errors | April 6, 2026 Incident Window: 18:14 – 20:06 UTC Current Status: Resolved ✅ On April 6, 2026, during the incident window, customers using our Content Safety feature for Pre-recorded STT experienced errors for their requests. What happened: A configuration change inadvertently prevented our systems from processing Content Safety requests. This caused all Content Safety-enabled transcription jobs for Pre-recorded STT to fail during the affected period. Who was affected: Customers with the Content Safety feature enabled who submitted Pre-recorded STT requests between 18:14 and 20:06 UTC. What we did: Our team detected the issue and reverted the configuration change, fully restoring Content Safety functionality by 20:06 UTC. We sincerely apologize for the impact this had on your workflows. If you have any questions, please contact our team at support@assemblyai.com, and we'll be happy to assist.

The AWS Bedrock issues have been resolved, and we have once again seen success rates for Claude models, including Sonnet 4.6, return to normal levels.

From approximately 10:10am to 10:28am PT we experienced longer-than-usual processing times for transcription of pre-recorded audio. The root cause of this slowdown has been identified and resolved, and response times are back within normal ranges. Our team will continue to monitor traffic to ensure continued good performance.

The billing issue that caused unexpected multiple auto-refill charges for a subset of Universal-3-Pro customers on February 28, 2025, has been resolved. Refunds have been issued to the affected customers.

This incident has been resolved.

The negative balance error affecting a small number of accounts has been resolved. This issue was an unintentional error that occurred as a result of our ongoing billing system migration. Our team is continuing to monitor the situation to ensure full stability. We apologize for any disruption this caused and thank you for your patience.

This issue has been resolved and LLM Gateway requests using Haiku 4.5 are continuing to complete normally.

**Summary: January 29 Outage** On January 29, our Async Transcription and LLM Gateway went down for 25 minutes, followed by two hours of degraded performance. Here's what happened. Our traffic has been steadily increasing and we received an influx of batch transcription jobs that were higher than usual. Autoscaling did what it should—spun up workers. We ran out of spot instances, fell back to on-demand, then hit AWS's Elastic Network Interface limit. Every ECS task needs an ENI. With no ENIs available, our authentication service couldn't rotate its tasks. It scaled to zero. Everything stopped. When we tried to recover, a Lambda function meant to help with failures was hammering the AWS API with describe calls, rate-limiting the very operations we needed to bring things back. A tool built for recovery was blocking recovery. **What actually went wrong:** We didn't monitor ENI utilization and our authentication service shared resources with batch workers. Traffic spike in one starved the other. **What we're doing:** Short-term: ENI alerts, isolate auth on dedicated capacity, fix the Lambda. Medium-term: Full multi-region for everything. This was preventable. We had the warning signs and didn't connect them. We're sorry, and we're fixing it.

We have continued to see good performance, and traffic is once again working normally so we are marking this issue as resolved.

This increase in errors was inadvertantly caused by a change that was made around 8:30am PT, which was immediately reverted when our team noticed the increase in errors. We have continued to see good performance since that rollback and are now marking this issue as resolved.

We have continued to see good performance since releasing the earlier fix and are now marking this issue as resolved.

This incident has been resolved.

Cloudflare has restored normal operation, and access to our documentation and Google Authentication is fully restored. All services are functioning as expected, and the incident is now resolved.

From 8p GMT on November 14, 2025 - 2:20p GMT on November 15, 2025, users connecting to our Streaming API using our US endpoint `wss://streaming.assemblyai.com/v3/ws` from Europe, Africa, and eastern Asia were experiencing SSL certificate validation errors. While the underlying SSL misconfiguration was resolved shortly after engineering engagement, some customers experienced extended connection failures during this window. Additional safeguards have since been implemented to prevent similar issues..

This incident has been resolved.

We have continued to see good performance and success rates for Slam-1 and are now marking this issue as resolved.

We have continued to see good performance for requests using Slam-1 and are now marking this issue as resolved.

This incident has been resolved.

We have continued to see good performance for pre-recorded audio so we are now marking this issue as resolved.

We have continued to see good performance since rolling back the update that was identified to be the cause of this issue, so we are marking this issue as resolved.

From 8a - 10a GMT there was an issue related to the pick-up time of our non-English language models. This caused an increase in processing time for pre-recorded transcriptions. Our Engineering team has released a fix and all transcriptions should now be processing normally.

Aside from a small window of about five minutes around 12:10pm PT where turnaround times were slightly higher than usual, we have continued to see turnaround times within the expected ranges so we are now closing this issue.

We experienced an issue with our Streaming API between 09:00 GMT and 10:04 GMT. This resulted in reduced quality of service for streaming sessions and some sessions were closing unexpectedly. A fix was implemented and our Streaming API is now functioning normally.

We have continued to see good performance for the last ~6 hours so we are marking this issue as resolved. To prevent future issues, we have made some improvements to allow Slam-1 to scale more effectively.

This incident has been resolved.

We had a brief period earlier where processing times for requests using the Slam-1 beta model took longer than expected. This slowdown occurred from approximately 7:37am PT to 7:57am PT and has now been resolved. Our team is continuing to monitor traffic to ensure continued good performance.

This incident has been resolved.

From 8:07pm to 8:22pm ET, transcriptions created with Slam-1 would have eventually resulted in a "Server error, developers have been alerted". Our team promptly looked into the issue and restored Slam-1 functionality.

This incident has been resolved.

We have continued to see payment being processed normally so we are marking this issue as resolved.

This incident has been resolved.

We have continued to see good results and are now marking this issue as resolved. We suspect that only a small number of transcripts were affected as P50 and P90 response times were within reasonable thresholds throughout, with only P99 response times being affected initially.

This incident has been resolved.

This incident has been resolved.

We have continued to see good results over the last several hours and are now marking this issue as resolved.

This incident has been resolved.

We experienced a customer-facing incident that impacted transcription turnaround times for our async endpoint.

This issue has been resolved and all dashboard information is now properly updating.

On Tuesday, February 25th from 1:01 AM to 1:08 AM Eastern Time, our service experienced a brief disruption during a routine database maintenance. During this 7-minute window, some API requests returned 500 errors, while other transcription requests were temporarily delayed in our processing queue. Any transcripts successfully queued were automatically retried and processed by our systems. Our team quickly identified the issue, reverted the changes, and fully restored service functionality by 1:08 AM. We continue to actively monitor our Async API to ensure everything is operating normally.

We have continued to see good performance and previously affected users are reporting that the issues are resolved on their end as well so we are marking this issue as resolved.

On January 3th, 2025 and on January 8th, 2025, we experienced two incidents that resulted in service disruptions and performance degradation for our asynchronous API. **Root Cause Analysis** Increased demand for the AssemblyAI asynchronous API has required changes to our datastore infrastructure to maintain performance and reliability. * **January 3th:** Transcription Record Service system did not scale out aggressively enough to properly service the traffic. We identified a misconfiguration in the scaling policies that constrained the service’s ability to scale out. This resulted in degraded performance for and high latency time for all requests during the 1 hour window. * **January 8th:** Our team deployed a configuration update to our infrastructure that unexpectedly caused a redeployment of the transcription record service. This resulted in failures for all customer requests during the 20-minute window while the transcription record service was redeployed and scaled back out to handle current traffic. While both of these incidents impacted the same service, the underlying cause of each incident was different. **Resolution and Next Steps** To prevent similar incidents in the future, we have: * Adjusted the auto-scaling rules of the Transcription Record Service to scale more aggressively with additional performance metrics * Implemented additional pre-deployment validation checks on infrastructure code changes * Strengthening our infrastructure configuration management processes * Improving the communication cadence to the [status page](https://status.assemblyai.com/) throughout the incident lifecycle **Customer Commitment** We apologize for any inconvenience or disruption these incidents may have caused. We are committed to providing a reliable and high-performing service and are taking steps to prevent similar incidents from occurring in the future. As always, you can rely on the [status page](https://status.assemblyai.com/) for up to date API information on our current status and health.

On January 3th, 2025 and on January 8th, 2025, we experienced two incidents that resulted in service disruptions and performance degradation for our asynchronous API. **Root Cause Analysis** Increased demand for the AssemblyAI asynchronous API has required changes to our datastore infrastructure to maintain performance and reliability. * **January 3th:** Transcription Record Service system did not scale out aggressively enough to properly service the traffic. We identified a misconfiguration in the scaling policies that constrained the service’s ability to scale out. This resulted in degraded performance for and high latency time for all requests during the 1 hour window. * **January 8th:** Our team deployed a configuration update to our infrastructure that unexpectedly caused a redeployment of the transcription record service. This resulted in failures for all customer requests during the 20-minute window while the transcription record service was redeployed and scaled back out to handle current traffic. While both of these incidents impacted the same service, the underlying cause of each incident was different. **Resolution and Next Steps** To prevent similar incidents in the future, we have: * Adjusted the auto-scaling rules of the Transcription Record Service to scale more aggressively with additional performance metrics * Implemented additional pre-deployment validation checks on infrastructure code changes * Strengthening our infrastructure configuration management processes * Improving the communication cadence to the [status page](https://status.assemblyai.com/) throughout the incident lifecycle **Customer Commitment** We apologize for any inconvenience or disruption these incidents may have caused. We are committed to providing a reliable and high-performing service and are taking steps to prevent similar incidents from occurring in the future. As always, you can rely on the [status page](https://status.assemblyai.com/) for up to date API information on our current status and health.

All previously queued transcription requests have now completed processing. New requests are being processed within standard response times. Please retry any requests that failed during this incident. Service has been fully restored.

We have continued to see good performance since the fix was released so we are marking this issue as resolved.

We have continued to see requests to our Streaming service complete successfully, so this issue is now being marked as resolved.