AssemblyAI

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.

Resolved: Between 23:30 and 23:37 UTC on September 13, 2026, async transcription requests experienced elevated turnaround times due to an unexpected spike in processing load. We scaled out additional capacity and turnaround times returned to normal levels. Requests submitted during this window were processed, with some taking longer than usual to complete.

This incident has been resolved. From 14:15-14:45 UTC customers experienced increased latency when using our Universal 3.5 Pro Realtime model on the US endpoint. The EU endpoint was not affected. Sessions continued to function during this time without any errors.

The fix has been implemented and latency has recovered as of 14:45 UTC. The team is continuing to monitor the situation.

The issue has been identified and our team is working on a fix.

We are currently investigating an issue where there is increased latency for our Universal 3.5 Pro Realtime model on the US endpoint. This began at 14:15 UTC.

This incident has been resolved. Between approximately 13:40 and 14:40 UTC, asynchronous transcription requests on our US endpoint experienced elevated latency and errors. Processing times and error rates have returned to normal ranges and the backlog has cleared.

A fix has been implemented and we are monitoring recovery.

We have identified the cause of the elevated error rates affecting asynchronous transcription requests. Our engineering team is actively restoring capacity, and error rates should improve as this completes. We will continue to provide updates as more information becomes available.

We’re seeing elevated latency and errors on async transcription submissions, and our on-call team is actively investigating. Capacity is scaling out now, and we’re monitoring recovery.

This incident has been resolved. From 13:00–13:12 UTC, users creating new streaming sessions using the EU endpoint were receiving a 3005 close code.

We are continuing to monitor for any further issues.

A fix has been implemented and our team is monitoring the results. Users can now create new realtime sessions successfully.

The issue has been identified and a fix is being implemented.

We're currently investigating an issue affecting users on our Universal 3.5 Pro Realtime model, where new streaming sessions could not be created on our EU endpoint. This occurred from 13:00–13:12 UTC. Affected users are seeing a 3005 close code. Users on the US endpoint are unaffected.

This incident has been resolved. Processing times for pre-recorded transcription requests using Universal-3 Pro and Universal-3.5 Pro have returned to normal ranges and the backlog has cleared.

Processing times for pre-recorded transcription requests using Universal-3 Pro and Universal-3.5 Pro are returning to normal ranges and the backlog has largely cleared. We are continuing to monitor to ensure stability.

We have identified the cause of the elevated processing times affecting pre-recorded transcription requests using Universal-3 Pro and Universal-3.5 Pro. Our engineering team has addressed a capacity constraint and is working to restore full capacity. Processing times will remain elevated while the backlog clears, and some customers may see requests queued or throttled. We will continue to provide updates as more information becomes available.

We're currently seeing longer than usual processing times for asynchronous transcription requests using Universal-3 Pro and Universal-3.5 Pro. Requests are being accepted and are completing, but time to completion is elevated while our queues work through a backlog.

This incident has been resolved. The affected webhook events remained queued and were delivered after service recovered; no events were lost. The queue is now clear, and no customer action is required.

A fix has been implemented and we are monitoring the results.

The issue has been identified and a fix is being implemented.

We are currently investigating an issue that is affecting webhook delivery on our Async EU Endpoint. This began at 2:30p UTC. Customers are receiving delayed webhook deliveries on the EU endpoint. This does not affect customers using webhooks on our US endpoint.

This incident has been resolved.

A fix has been implemented and we are monitoring the results.

We are continuing to work on a fix for the issue. The API is stable and the errors subsided at 5:11pm UTC.

Our team has identified the issue and a fix is being released.

We are currently investigating an issue where users on our us-east-1 endpoint are experiencing 503 errors when using temporary tokens with our Realtime API. This began at 4:49pm UTC.

This incident affected a subset of Universal-3.5 Pro streaming sessions in the us-east region on July 31 between 20:15 and 22:15 UTC. Affected sessions connected successfully but did not process incoming audio, so no transcript was returned while the connection remained open. Other regions, other streaming models, and our asynchronous API were unaffected. We apologize for the disruption to your workflows. If you have any questions, please reach out to support@assemblyai.com.

This incident affected newly created Universal Streaming English sessions in the us-west region on July 7 between 15:00 and 15:10 UTC. Affected sessions were cancelled with error code 3005 shortly after connecting and did not return transcripts. Sessions already in progress, other regions, and other streaming models were unaffected. Service returned to normal at 15:10 UTC. We apologize for the disruption to your workflows. If you have any questions, please reach out to support@assemblyai.com.

This incident has been resolved. Async transcription processing times on the US endpoint have returned to normal ranges and webhook deliveries are operating normally.

We have been monitoring the queue drain and transcription pickup delays caused by the backlog. Processing times are returning to normal ranges on the US endpoint and the backlog has cleared. We are continuing to monitor.

We have identified the issue causing elevated processing times for async transcriptions on the US endpoint and have addressed the root cause. The system is recovering, but processing times remain elevated while the backlog clears. Webhook deliveries may also continue to be delayed.

We are seeing increased processing times for pre-recorded (async) transcriptions on the US endpoint. Webhook deliveries may also be delayed. We are currently investigating.

**What happened** An issue related to our speaker diarization service caused certain requests to hang until they timed out. This lead to a backlog of requests to our async API creating a processing queue across our US transcription pipeline, which slowed and timed out transcription requests more broadly, including requests that were not using speaker diarization. --- **When** Impact ran from approximately 15:00 to 16:25 UTC on June 25, 2026 \(about 1 hour 25 minutes\). The most severe disruption was in the first 45 minutes \(15:00–15:45 UTC\); remaining delays and timeouts cleared shortly after. Full recovery was confirmed by ≈16:40 UTC. --- **What services were affected** On our US async API endpoint transcription requests during this window saw processing delays and timeouts. Our EU async API endpoint was not affected and operated normally throughout.

This incident has been resolved.

Our API is continuing to recover and incoming transcriptions are returning to normal processing. We are continuing to monitor the situation.

The root cause has been addressed and our system is slowly working through the transcript backlog, which is causing slower processing on our US async endpoint.

A fix has been implemented and our API is slowly beginning to recover normal processing.

The issue has been identified and a fix has been released.

We are currently investigating an issue with async transcriptions on the US endpoint that use speaker labels. This is resulting in timeouts for all transcriptions with speaker labels enabled for files under 2 minutes long. This began at 15:00 UTC.

The issue affecting EU pre-recorded transcription for Universal-3-Pro and Universal-3-5-Pro has been fully resolved, the fix was implemented at 10:05 UTC. 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.

A fix has been implemented and requests to the EU versions of Universal-3-Pro and Universal-3-5-Pro no longer show degradations. We are continuing to monitor to ensure stability.

Our engineering team has identified the issue and is actively working to implement a fix. We will continue to provide updates as more information becomes available.

We are currently investigating degradations affecting only traffic to the EU versions of Universal-3Pro and Universal-3-5-pro for pre-recorded audio transcription.

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

Account signups and upgrades have recovered and we are seeing successful new account creation. Our team is continuing to monitor and clean up a small number of affected accounts. We will provide a final update once fully resolved.

We are currently experiencing degraded performance with new account signups and provisioning due to an upstream issue with our billing provider. Existing accounts and API usage are unaffected. New users may experience errors or delays when creating an account. Our team is actively working with our provider to resolve the issue and will provide updates as more information becomes available.

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.

A fix has been implemented and the EU endpoint is recovering. Processing times and error rates are stabilizing.

This incident has been resolved.

A fix has been implemented and we are monitoring the results.

The issue has been identified and a fix is being implemented.

We are currently investigating an issue affecting billing balance updates and notifications. Some customers may notice that their account balance is not reflecting the most up-to-date usage. Additionally, the following notifications may not be delivered as expected: - Low balance and $0 balance alerts - Autopay confirmation emails - Custom email alerts for usage spend and threshold notifications Our team is actively working to identify the root cause and restore normal functionality. We will provide updates as more information becomes available.

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

The root cause of the slowdown has been addressed and turnaround times have once again returned to the normal range. We will continue to monitor traffic going forward to ensure continued good performance.

We have identified an issue that is causing elevated processing times for requests that are using Universal-2 for pre-recorded audio. Most requests are still completing successfully, but we are also seeing a small increase in errors as a result of some requests timing out. Our team has identified the root cause of this issue and is working to resolve it as quickly as possible. Request using Universal-3 Pro are unaffected by this issue.

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.

The capacity constraint has been addressed and the transcription queue is actively clearing. Processing times should return to normal within the next few minutes. We are continuing to monitor to ensure stability.

We are currently experiencing degraded async transcription performance. Some customers may see increased processing times or throttled requests. Our engineering team has identified the issue and is actively working to restore full capacity. We will continue to provide updates as more information becomes available.

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.

The AWS Bedrock issues affecting some Claude models through LLM Gateway, mainly Sonnet 4.6, are still occurring, but the frequency of those errors has gone down. We are continuing to closely monitor the issue for a resolution.

AWS Bedrock is currently experiencing issues that are leading to an increase in errors for Claude models. This increase in errors seems to be primarily with Sonnet 4.6, but could also affect other Claude models. We are working with their team to monitor the status of this issue and will provide additional updates as soon as we know more. LLM Gateway models from other providers are currently unaffected by this AWS Bedrock issue.

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.

We are aware of an issue that caused unexpected multiple auto-refill charges for a subset of customers using Universal-3-Pro today, February 28, 2025. Our team is actively investigating the root cause and working to resolve it as quickly as possible. We apologize for the inconvenience and will provide further updates as they become available.

This incident has been resolved.

A fix has been implemented and we are monitoring the results.

The issue has been identified and a fix is being implemented.

We are currently investigating an issue that is resulting in degraded Speaker Identification and Translation tasks.

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.

Our team has identified the root cause of the negative balance error currently affecting a small number of accounts. A fix is actively being rolled out and we will continue to monitor the situation closely until full resolution is confirmed.

We are currently investigating a billing issue affecting a small number of customer accounts. Impacted accounts are receiving a negative balance via the API, which is preventing transcription requests from completing and returning errors instead. Our team is actively working to identify and correct all affected accounts. We apologize for the disruption this has caused to your workflows and will provide updates as the investigation progresses.

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

The increased error rates with Haiku 4.5 that we were seeing earlier have subsided but we are continuing to monitor traffic on our end to ensure continued good performance.

We have identified an issue with the AWS hosting of our Claude Haiku 4.5 model, which is leading to increased 429 errors when using LLM Gateway with the Haiku 4.5 model. This issue is not currently affecting other LLM Gateway models, and retries for requests using Haiku 4.5 are often successful. We are working with our provider to resolve the issue as quickly as possible.

**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 cleared the backlog, and turnaround times are back to normal. Our team continues to actively monitor the situation. We will provide a post-mortem when available.

We are continuing to work through the backlog, and turnaround times are improving. Our team continues to actively monitor the situation. We will provide updates as more information becomes available.

We are continuing to see requests being completed. We are working through a backlog of requests, resulting in elevated turnaround times while we recover. Our team continues to actively monitor the situation. We will provide updates as more information becomes available.

We are seeing requests beginning to successfully complete and have moved to the monitoring phase. Some requests are still returning 500 errors. Our website is down, and logins may be affected. Our team continues to actively investigate and monitor the situation. We will provide updates as more information becomes available.

We are seeing requests beginning to successfully complete and have moved to the monitoring phase. Some requests are still returning 500 errors. Our team continues to actively investigate and monitor the situation. We will provide updates as more information becomes available.

We are currently investigating an issue affecting our Async and LLM Gateway services, which are returning 500 errors. Our team is actively working to identify and resolve the problem. We will provide updates as more information becomes available. All streaming API and EU endpoint services are running normally. This incident is isolated to NA API endpoints for async + LLM gateway.

We are continuing to investigate this issue.

We are currently investigating an issue affecting async + LLM gateway services. More updates to come as we learn more.

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

We are seeing significant signs of recovery and processing of queued transcripts. Our team will continue to monitor the situation.

The team has identified the issue and it is caused by an AWS Operational Issue on their Amazon Elastic Compute Cloud (Ireland). Our team is in touch with AWS and monitoring the situation: https://health.aws.amazon.com/health/status

This issue is also affecting the EU DELETE endpoint. Some DELETE requests for transcriptions are resulting in an error.

Our team is actively investigating an issue that is causing increased latency for transcriptions using the EU endpoint for pre-recorded transcriptions. Customers may experience transcripts being queued. This is not affecting streaming usage on the EU endpoint.

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 experienced a spike in connection issues for new streaming sessions between 8:30 and 8:35am PT. These errors affected requests for both NA and EU regions. These connection issues have subsided, but our team is working to ensure continued good performance.

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

We have released a fix that has resolved the unexpected responses we were seeing when Claude models were used. Everything is working normally now, but we will continue to monitor traffic to ensure continued good performance.

We have identified the root cause of this issue and are working to release a fix.

We are currently investigating an issue with LLM Gateway that is causing unexpected responses when using Claude models. This issue is not affecting LLM Gateway requests using other models. We are working to identify and resolve the root cause of these issues.

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.

A fix has been implemented and our team is monitoring the results. Slam-1 has resumed normal processing.

The issue has been identified and a fix is being implemented.

We are currently investigating an issue where there has been delayed processing of transcripts on Slam-1, specifically in our us-west-2 region. This began at 5:43 UTC. Customers will experience queueing or erroring of transcripts when using our Slam-1 model. Our Universal model is not affected by this incident.

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.

Our documentation is now accessible and all users can sign-in to the dashboard using Google Authentication. We will continue to monitor the situation in case anything changes.

Due to the ongoing incident with Cloudflare, our documentation is unable to be accessed and users cannot use Google Authentication to sign in to their dashboard.

Due to the ongoing incident with Cloudflare, our documentation is unable to be accessed and users cannot use Google Authentication to sign in to their dashboard.

This incident has been resolved.

A fix has been implemented and we are monitoring the results.

The issue has been identified and a fix is being implemented.

We are continuing to investigate this issue.

We are currently investigating an issue that is leading to longer-than-usual processing times for pre-recorded audio transcriptions using the Slam-1 model that is resulting in some transcripts being returned with server errors. Requests using the Universal model, which is enabled by default, are not affected by this issue.

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

Success rates and processing times have returned to the normal range, but we are monitoring traffic to ensure continued good performance.

We are once again seeing occasional issues where some requests using the Slam-1 model are taking longer than normal to process or failing with a server error. Retries are typically successful and requests using the Universal model are unaffected.

We are continuing to see success rates in the normal range and no longer than usual processing times but we will continue to monitor traffic to ensure continued good performance.

We are starting to see success rates return to the normal range, but we are still working to ensure that the issue has been fully resolved.

We are currently seeing some Slam-1 requests fail with a server error as we are restarting services while working to address this issue. We suggest holding off on retries for the time being or retrying those requests using Universal until normal processing has been restored. We will release another update here as soon as we are seeing an increase in success rates.

Our team has identified the issue causing the delay in processing requests using Slam-1 and is actively working to resolve the issue.

We are currently investigating an issue that is leading to longer-than-usual processing times for pre-recorded audio transcriptions using the Slam-1 model. Requests using the Universal model, which is enabled by default, are not affected by this issue.

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

Success rates and turnaround times for requests using Slam-1 have returned to normal ranges, but we are continuing to monitor traffic to ensure continued good performance.

We are still seeing good success rates for requests using the Slam-1 model, but we are still seeing occasional slower-than-usual processing times, which we are working to address.

We are once again starting to see requests using Slam-1 succeed, but we are still working to fully resolve the issue. We will follow up with another update once the issue has been fully mitigated.

We are now seeing increased error rates and failures for requests using the Slam-1 model so we are elevating this issue to a partial outage. Requests using Universal are working normally, so consider using that model as a short-term workaround if needed. Our team is working to resolve this issue as quickly as possible.

We are currently seeing longer-than-usual turnaround times for pre-recorded audio transcriptions that are using our Slam-1 model. Requests using the Universal model are unaffected. We are working to address this issue and will provide an update here as soon as possible.

This incident has been resolved.

Account creation and updates are once again working normally, but we are continuing to monitor the situation to ensure continued good performance.

We are currently experiencing an issue with new account creation due to the ongoing AWS issues that may affect the ability of newly created accounts to use our API or Playground.

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

We have released a fix to address the small increase in errors we were seeing and are monitoring to ensure continued good performance.

Our team has identified where the errors are occurring in our pipeline and is currently working to identify and resolve the root cause. This issue is currently only affecting an extremely small percentage of total pre-recorded audio traffic. 99%+ of requests are still completing successfully.

Our team is currently investigating an issue that is causing an increase in server errors for our pre-recorded audio speech-to-text feature. This issue is only affecting a small number of requests, but it is affecting requests to both Universal and Slam-1 models. If you experience a server error we suggest retrying the request as those will likely be successful.

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.

We have continued to see stable performance throughout the day. The Streaming API is operating normally and we are monitoring the effects of recent changes to ensure continued service stability. Our team continues working to determine the root cause of the earlier connection failures.

Our team is still investigating the cause of the elevated errors, but the Streaming API is still continuing to function normally.

The Streaming API has now returned to full functionality. Our team is still investigating the root cause of this issue.

Between 1:30p and 1:40p GMT there were an increased number of new streaming sessions that were failing to be established. Customers would have received the error message "received 3005 (registered) Session Cancelled: An error occurred; ".

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 are currently investigating an issue that is causing a small increase in turnaround times for STT services for pre-recorded audio for some requests. Traffic as a whole is still completing within the range of normal turnaround times. We will provide additional updates as we learn more.

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.

We have continued to see good performance with no instances of increased errors over the last couple of hours ,but are continuing to monitor to ensure there are no further issues.

We are still seeing good performance with the Slam model and requests completing as expected, but we are still working to fully resolve the root cause to prevent issues in the future.

We are seeing Slam-1 requests complete successfully once again, but we are still working to fully resolve the root cause of this issue.

We are once again experiencing issues with Slam-1 where requests are failing with a "Server error, developers have been alerted" error. Note: This issue is only affecting requests using Slam-1 as the `speech_model`. Changing the `speech_model` to Universal will allow requests to complete successfully. See this section of our documentation for more information on specifying a speech model: https://www.assemblyai.com/docs/speech-to-text/pre-recorded-audio/select-the-speech-model

We have resolved the issue that was affecting Slam-1 and are now seeing requests being processed successfully. We will continue to monitor traffic to ensure good performance, but everything is working as expected at the moment.

We are continuing to investigate the issues affecting Slam-1. Currently, all requests using Slam-1 as the `speech_model` are failing with a "Server error, developers have been alerted" error. Our team is working to resolve this issue as quickly as possible. Note: This issue is only affecting requests using Slam-1 as the `speech_model`. Changing the `speech_model` to Universal will allow requests to complete successfully. See this section of our documentation for more information on specifying a speech model: https://www.assemblyai.com/docs/speech-to-text/pre-recorded-audio/select-the-speech-model

We are currently investigating an issue with Slam-1 that is preventing the successful completion of transcription requests using the model. We will share additional information as it becomes available. Please note this issue is only affecting requests using Slam-1 as the `speech_model`. Universal is unaffected.

This incident has been resolved.

A fix has been implemented and all customer dashboards should now be up to date. We are continuing to monitor the situation.

The issue has been identified and a fix is being implemented.

Our team is still currently investigating the root cause of this delay.

We are currently investigating an issue where there is a delay in new transcriptions showing up under the Transcription History tab of the dashboard.

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.

The English transcript formatting issue is now considered resolved. We are monitoring to ensure continued stability. Please re-run any affected transcripts to ensure correct formatting.

We are experiencing a formatting issue affecting English transcripts. Transcripts will continue to process successfully, but formatting may appear incorrect or incomplete. We're actively investigating this issue.

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.

A fix has been implemented and we are monitoring the results.

The issue has been identified and a fix is being implemented.

We are currently investigating an issue that affects payment processing for accounts upgrading from the free tier to the pay as you go tier.

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

Our billing provider looks to have resolved the issues that were affecting them, and we are once again seeing payments complete as expected. We are monitoring the situation to ensure good performance going forward.

We are currently experiencing issues that are affecting customers' abilities to add funds to their accounts. This is affecting some new and existing users. Our team is actively investigating the problem and working with our payment processor to resolve this as quickly as possible.

This incident has been resolved.

We have continued to see payments processing normally, so we are marking this issue as resolved.

Payment processing has returned to normal. We are closely monitoring payments to ensure continued good performance.

Our billing provider is currently performing database maintenance to resolve the issues they have been experiencing. We will provide further updates once the maintenance has concluded and we have been able to reevaluate performance.

We are seeing some fund deposits processing successfully, but we are still seeing some requests fail, so we are still actively working with our billing provider to resolve this issue.

We are once again seeing issues with payments not being successfully processed by our billing provider and are investigating this with them.

The issue that was affecting payments has been resolved and we are once again seeing payments successfully processed by our payment provider. Will will continue to monitor to ensure good performance. Note: If you received an email that your Auto-pay has been disabled, please log in to the dashboard to reenable Auto-pay for your account.

We are continuing to work with our billing provider to resolve this issue. This issue is currently affecting customers who are adding funds to their account both manually and via Auto-pay as well as new users trying to upgrade and add funds to their account.

We are currently experiencing an issue with our billing provider that is affecting customers' ability to add funds to their accounts. Our team is actively investigating the problem and working with our payment processor to resolve this as quickly as possible.

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.

The system has been stabilized and we are continuing to monitor the results.

The issue has been identified and a fix is being implemented.

We are currently investigating an issue causing degraded turnaround times for the Realtime API due to a slowdown in ASR processing. More updates to come as we learn more.