Speech-to-Text Service Outages: Incidents on Status Pages

Outages on cloud speech services are common but uneven. Of the 13 services in this dataset, Gladia posted 14 incidents ¹ and AssemblyAI posted 14 incidents ² on their own status pages in the window from July 30 to October 28, 2026. At the other end, Rev posted 0 incidents ³ and Rev AI posted 0 incidents ⁴. The pattern that matters most is not the count but the severity: Granola posted 8 incidents ⁵, and most of them were rated major or critical.

These are counts of what each company chose to post, not a ranking of reliability. Read them as a record of how often a service tells its users something went wrong.

API providers post the most incidents, but few are rated severe

The speech-to-text API group has the widest spread. Gladia and AssemblyAI are level at the top, each with 14 incidents ¹ and 14 incidents ². Deepgram follows with 9 incidents ⁶, and Speechmatics with 5 incidents ⁷. Rev AI, with 0 incidents ⁴, sits alone at the bottom.

Most API incidents were not rated major or critical. Deepgram's 9 incidents ⁶ include only a single severe one, and Gladia's and AssemblyAI's severe counts are a minority of their totals. A likely reason is that API providers run granular pages with a component per model, region or feature, and they post a short notice for a regional slowdown or a degraded model. Developers who build on these APIs expect that level of detail, so more incidents are posted, and most are minor.

Deepgram, Speechmatics, Rev AI and AssemblyAI are counted on their speech-to-text components only, so a failure in another part of their platform is not in these figures.

Meeting-notes apps post fewer incidents, but more of them are severe

The five meeting-notes services are Granola (8 incidents ⁵), Read AI (7 incidents ⁸), Otter.ai (5 incidents ⁹), Fathom (2 incidents ¹⁰) and Tactiq (2 incidents ¹¹). Fathom and Tactiq are level, and both are well below the other three.

Taken together, the meeting-notes group posted fewer incidents than the API group, yet most of its incidents were rated major or critical, where only a minority of the API group's were. Granola has the most severe incidents of any service in the table, and nearly all of its incidents carry that rating. Otter.ai is similar: most of its incidents were severe, and its severe count is the same as AssemblyAI's even though it posted far fewer incidents in total.

Why would the groups differ? A meeting-notes app is one product with one pipeline: join the call, record, transcribe, summarize. When the pipeline stops, every user is affected at once, and the company has little room to call it minor. An API provider with many regions and models can post a narrow incident without touching most customers. That is our reading of the pattern, not something the status pages state, and the table lets you check it against each row.

Fathom is counted on its meeting-processing components only, which narrows its figure to the part of the product that handles the recording and the notes.

The one dictation app in the data had no severe incidents

Wispr Flow is the only dictation app that qualified, with 4 incidents ¹², none rated major or critical. That is a count in the middle of the table, above the transcription services and below the API leaders. One row cannot stand for a whole category, and the data does not allow a claim about dictation apps in general.

Many dictation tools are missing for a structural reason. Apps that run on the device have no service to go down, so they do not have a status page and are excluded. Large providers whose pages mostly cover other products and list no components (OpenAI, ElevenLabs, Mistral) are excluded too, because their speech incidents cannot be separated from the rest. For the wider picture of who makes what, see our market overview.

Transcription services were the quietest

The two transcription services are Rev with 0 incidents ³ and Trint with 2 incidents ¹³. Trint is level with Fathom and Tactiq on count. Neither service posted anything like the volume of the API leaders.

A zero needs careful reading. Rev and Rev AI both posted 0 incidents ⁴ in the window, and that can mean a stable service, a company that posts only large outages, or a page that is rarely updated. Nothing in the counts separates those cases.

What the data cannot tell you

The counts have four limits that readers should keep in mind.

• Posting habits differ. Some companies post every slowdown, and others only large outages. A high count can reflect openness as much as trouble. A page with few incidents is not proof of a quiet quarter.
• Impact ratings are the company's own. "Major or critical" is the provider's label, and there is no shared scale. One provider's major incident may be another's minor one.
• Scope differs by row. Some rows cover speech components only, one covers meeting processing only, and the rest carry no component filter. The rows are comparable in kind but not identical in what they count.
• Incidents have no duration or size. A single long outage and a single brief blip each count once. The data does not say how many users were affected, for how long, or in which region.

The window is also short and recent. A figure is published only when a page's history reaches back the full window, so services with newer or shorter histories are absent. A single window can be shaped by one bad week, and these counts are tracked weekly, so they will move.

What this means for choosing a service

If you build a product on a speech API, expect incidents and plan for them. A retry policy, a timeout and a fallback provider matter more than a low count on a status page. When you compare vendors, read each page's incident history, not only the count: a provider with many short incidents and one with a few long ones are different risks. Accuracy and price belong in the same decision, and our speech-to-text pricing data and the guide to speech recognition cover those.

If you depend on a meeting-notes app, the severity pattern is the useful signal. Most of the incidents in that group were severe, so keep a second way to capture the meeting, such as a local recording, for calls you cannot redo.

If you only dictate to write, a cloud service is one option among several. A service that runs on the device has no status page and no server to fail, which is why it does not appear here.

Every row in the dataset