How often do cloud dictation and note-taking apps go down?

Cloud dictation and note-taking apps post incidents less often than a busy week suggests, but the pattern differs by app. In the 90 days to October 28, 2026, Granola posted 8 incidents ¹, Read AI 7 incidents ², Otter.ai 5 incidents ³ and Wispr Flow 4 incidents ⁴. Fathom, Tactiq and Trint each posted 2 incidents ⁵, and Rev posted 0 incidents ⁶.

Those are counts of what each company posted, not a ranking of which app is most dependable. An app that transcribes entirely on your device has no server of its own to go down, so it does not appear here at all.

Granola posted the most, and nearly all of it was rated major or critical

Eight apps have a status page with a history we can read. Granola posted the most incidents. Read AI came next, then Otter.ai, then Wispr Flow. Fathom, Tactiq and Trint were level with one another, and Rev posted none.

Severity tells a different story from volume. The table below includes the number of incidents each company rated major or critical. Granola rated most of its incidents that way, and so did Otter.ai. Wispr Flow posted incidents but rated none of them major or critical, as did Rev, which posted none at all. Wispr Flow is therefore the only one of the eight with incidents on its page and none rated at the top two levels.

Meeting-note apps:

Dictation apps:

Transcription services:

The chart puts every service we track on one scale, including the speech-to-text APIs, so you can see the apps in context. Our page on speech-to-text API outages covers those.

A count shows posting habits more than reliability

Each row carries the same caveat: counts show how often each company posted, not how reliable it is compared with the others. Some post every slowdown. Others post only large outages. The impact rating is the company's own.

Two apps with the same count can be very different. Fathom, Tactiq and Trint all posted the same number, yet that tells you nothing about how long their incidents ran or how many users noticed. A company that posts a note for each short blip looks worse on paper than one that stays quiet.

The ratings need the same care. Granola's high share of major or critical incidents may mean its team reserves the page for serious problems, or it may mean its problems were serious. The data cannot tell which.

What these counts do not measure

• Only the status page. A problem that the company never posted does not count.
• Meeting processing only, for Fathom. Its count covers the meeting processing components picked from its component list. The other apps are counted on the page as a whole, because their pages are mainly about the speech product.
• No duration. A short incident and a long one count the same.
• Full history required. A figure is published only when the page's history reaches back the full 90 days. An app with a newer page or no machine-readable history is left out.
• Apps that run on the device are excluded. They have no service to go down, so a status page would be empty by design. That is a fact about architecture, not a score.
• Zero is not proof. Rev's count of 0 incidents ⁶ means nothing was posted, not that nothing happened.

Why an app on your device cannot have this kind of outage

A cloud app sends your audio to a server, gets text back, and depends on that server being up. If the server fails, dictation stops, a meeting recording may not be processed, or notes arrive late. A recorded meeting is a special case: the recording itself may be safe, but the transcript waits for the service.

An app that recognizes speech on your own computer or phone does not make that trip. It can still fail in other ways, such as a bug, a full disk or a model that will not load, but it cannot be taken down by a remote outage. Yap, which we make, works this way on Mac and Windows, which is why it has no status page in this dataset. That is a design difference, not a claim about quality, and a cloud app can be the right choice for features that need a server, such as shared notes or calendar-connected meeting bots.

What this means for choosing how to dictate

1. Decide whether you need the cloud. If you dictate alone, a tool on the device avoids the question. If you need meeting bots, shared workspaces or team search, you accept a server dependency.
2. Read the status page of any cloud app you rely on. A page that explains causes and shows fixes is a better sign than a bare count.
3. Keep a fallback. Know what you will use when your main tool is down: the built-in dictation on your computer or phone, or a second app. For a meeting, record locally as well as in the app.
4. Do not over-read small gaps. A difference of a few incidents between two apps mostly reflects how each writes its page.

For a wider comparison of the products themselves, see our market overview. To compare costs, see the data on speech-to-text pricing.

Where to go next

Every row, its window and its history are in the full dataset. For how cloud speech recognition works, read the guide to speech-to-text APIs and the overview of speech recognition.