Elevated Latency and Errors for Batch STT (US)
An issue affecting some of our pre-recorded transcription servers slowed request processing. As requests took longer to complete, some customers saw elevated latency or received 429 errors. We identified and mitigated the issue, service has returned to normal.
The latest update from Deepgram.
State
Resolved
Started
34 d ago
2026-09-28 17:53 UTC
Lasted
1 min
until 2026-09-28 17:53 UTC
Worst impact
Degraded
Timeline
2 updatesResolved
1 min 100%
Updates
Times in UTCAs posted by Deepgram
An issue affecting some of our pre-recorded transcription servers slowed request processing. As requests took longer to complete, some customers saw elevated latency or received 429 errors. We identified and mitigated the issue, service has returned to normal.
We are investigating elevated latency and 429 errors affecting some pre-recorded (batch) STT requests.
Affected components
2Deepgram in the last 90 days
Full historyIncidents in 90 days
17
Days with an incident
16
Median duration
1 h 27 min
This incident
100% shorter than the median
Other Deepgram incidents
All incidentsDeepgram·Elevated errors from authentication services at one datacenter
Between 15:17 and 15:45 UTC on October 29, an issue with authentication services at one of our US datacenters caused some API requests and Voice Agent sessions to fail with 5xx errors, and some transcription callbacks sent from that datacenter to carry an invalid Dg-Token header. A fix was deployed at 15:45 UTC and error rates returned to normal. This incident is resolved. All systems are operational.
Deepgram·Elevated Latency and Errors for Batch STT
Between 19:27 and 21:53 UTC on October 22, some pre-recorded (batch) requests intermittently had elevated latency, and some timed out. This incident is resolved. All systems are operational.
Deepgram·Elevated 5xx Errors
Between 16:00 and 17:09 UTC on October 22, some API requests returned 5xx errors because of an issue with authentication services at one of our datacenters. This incident is resolved. All systems are operational.
Deepgram·Elevated 503 errors for bath Flux TTS requests
This issue has been resolved.
Deepgram·Elevated 503 errors for Aura-2 TTS
This issue has been resolved.
Follow Deepgram
Your coding agent knows when Deepgram is down, and tells you when a failure is theirs, not yours. You can also get Deepgram 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 "deepgram" and tell me if Deepgram 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=deepgram/feed subscribe https://outages.cc/feed.xml?providers=deepgramFAQ
Go from tracking outages to fixing production issues with Polylane.
Try Polylane