How often do speech-to-text APIs have outages?

Most speech-to-text APIs post incidents on their status pages every few weeks, but the number varies a lot from one company to the next. In the 90 days to October 28, 2026, AssemblyAI posted 14 incidents ¹ and Gladia posted 14 incidents ². That is level: both posted the same number. Deepgram posted 9 incidents ³, Speechmatics 5 incidents ⁴, and Rev AI 0 incidents ⁵.

Read those as posting counts, not as a reliability ranking. The rest of this page shows the numbers, what they leave out, and how to use them when you pick an API.

AssemblyAI and Gladia posted the most, Rev AI posted none

Five APIs have a status page with a machine-readable history that our readings can use. Over the window from 2026-07-30 to 2026-10-28, AssemblyAI and Gladia were at the top and level with each other. Deepgram posted fewer than either of them, and Speechmatics fewer than Deepgram. Rev AI's speech components show no incident at all.

The table also gives the number of incidents each company rated major or critical. AssemblyAI had the most of those, Gladia came next, then Speechmatics, then Deepgram. Rev AI had none, because it posted no incidents.

The chart shows every service we track, not only the APIs, so you can see where the five APIs sit next to meeting-note and dictation apps. Our page on cloud dictation and note-taking apps covers those.

A high count can mean a company posts more, not that it fails more

Every row carries the same warning: the counts show how often each company posted, not how reliable it is compared with the others. Some companies post every slowdown. Others post only large outages. A company that writes a short incident for each brief latency spike will look worse than one that stays silent about the same spike.

Impact ratings work the same way. The "major or critical" label is the company's own judgment, applied by its own staff with its own thresholds. One team's "major" can be another team's "minor". Speechmatics shows this well: among the five, it had the largest share of its incidents rated major or critical, even though it posted far fewer incidents than AssemblyAI or Gladia. A company that posts rarely may be reserving its page for serious events, which pushes the share up.

What these counts do not measure

Several limits apply, and you should keep them in mind before you quote a number.

• Only what the company chose to post. An outage that never reached the status page is not counted. A slow day that only some customers saw may not be either.
• Speech components only, for most rows. For Deepgram, AssemblyAI, Speechmatics and Rev AI, the count covers the speech-to-text components, picked out of a longer list. An incident on a billing portal or a dashboard does not count here.
• Not a measure of downtime. An incident can be brief or last a long time. The count says nothing about duration, how many customers were hit, or which regions.
• Full history required. A figure is published only when the page's history reaches back the full 90 days. An API whose page is newer, or whose history is not machine-readable, is not in the set.
• Some providers are left out. Status pages that mostly cover other products and list no components (OpenAI, ElevenLabs, Mistral) are excluded, so their speech APIs are not here. Open models, which you host yourself, have no vendor status page.
• A zero is not a guarantee. Rev AI's count of 0 incidents ⁵ means no incident was posted. It does not prove nothing went wrong.

What this means when you choose an API

Do not pick or drop an API because its count is a few higher or lower than another's. The difference between a count of 9 incidents and a count of 14 incidents is small next to the effect of how each team writes its status page.

Use the numbers for these things instead.

1. Read the history itself. Open each candidate's status page and read a few incidents. Look at how fast the company posted, how clearly it described the impact, and whether it explained the cause afterward. Transparent reporting is a good sign in a vendor.
2. Test on your own traffic. The only reliable measure of uptime for your use is your own. Send a steady stream of short requests to each shortlisted API for a few weeks and log failures and latency.
3. Plan for failure. Whatever the count, any cloud API can go down. For live captions or voice agents, build in a retry, a timeout, and a second provider you can switch to. For batch transcription, queue the work and retry later.

If price matters as much as uptime, compare the shortlist on speech-to-text pricing too. For a wider look at the products behind these APIs, see our market overview.

Where to go next

The full dataset lists every service we track, with the history of each reading, the window, and which components were counted: the full dataset. For background on how these services work and what to compare, read the guide to speech-to-text APIs and the overview of speech recognition.