When your article audio service goes down: what readers actually see
Every hosted service has bad days. The question worth asking before you sign is what your article pages look like when it happens. How our player behaves when it gets no answer, how failed audio jobs are retried, and what our status page will and will not claim.
Vendors love to talk about uptime. Publishers should ask a different question: when the audio service has a problem at 7 a.m. on a news day, what does my article page look like, and what do I need to do about it?
The honest answer to "will it ever go down" is yes, for any hosted tool including ours. So this post is about the second question. Everything below is taken from how our embed script, our status endpoint and our audio pipeline are actually written, not from a sales sheet.
"Down" is not one thing
An article audio service is several moving parts: the website and API, the database, the storage that serves audio files, text preparation, voice generation, billing, and the scheduler that polls your feeds. They fail independently, and the impact on your readers is completely different depending on which one is affected.
- Voice generation down: audio that already exists keeps playing. New articles wait in the queue.
- File storage down: the opposite. New audio could still be produced, but listening to existing audio is affected.
- Billing down: your readers notice nothing at all.
That is why our status page lists each component on its own line instead of a single green light. Each one is checked with a real call, not by confirming that a configuration value exists. That distinction matters: a revoked key or an exhausted quota passes a configuration check without complaint, so a status page built that way stays green for the entire outage, which is exactly when you need it. Results are cached for one minute so that everyone refreshing the page during an incident does not make the incident worse.
What a visitor sees when the player gets no answer
The player arrives on your page through a small script loaded with defer. It never holds up the article: if our servers are unreachable, your text renders exactly as it always does. The details are in our piece on player weight and page load speed.
After that, it depends on how you installed it.
Automatic mode, by page address. You place one script on your article template, and it looks up the audio that matches the page URL. If that lookup fails or returns an error, nothing is inserted. No empty frame, no dead play button, no error banner in the middle of your story. The page simply looks like a page without audio. This is a deliberate rule, spelled out in the script itself.
Per-article mode. When the script carries a specific audio ID, space is reserved from the first paint, with an animated placeholder sized like the player so the layout does not jump. If the player never reports its height (network cut, blocked origin, silent server), the placeholder fades out after five seconds instead of shimmering forever and implying something is still loading.
Either way, the outcome we designed against is the one every editor dreads: a third-party widget that breaks the article layout or holds the page hostage.
Audio that already exists
A finished audio is an MP3 file served with a one-year cache lifetime. In practice, a browser or network cache that has already fetched it can play it again without coming back to us. We are careful not to oversell this: it is not a guarantee of playback during a storage outage. What it does is soften the effect of a short outage on your most-played articles.
If you want zero dependency on us for delivery, that path exists too: take the files and serve them yourself with your own player. You give up what our player adds (listening statistics, chapters, automatic colours), which is a trade-off worth making knowingly rather than by accident.
Articles published during the outage
This is where behaviour really matters, because it is where audio goes missing without anyone noticing.
A job that fails is not dropped on the first error. It goes back into the queue and is retried, up to three attempts for an ordinary failure. A "too many requests" answer from the voice engine is treated differently: it does not count as a failed attempt, the job simply waits and resumes when the engine answers again, with a ceiling of twenty such waits so that a quota that never comes back cannot loop forever. Work already done before the failure, such as the prepared text, is kept for the next attempt rather than redone and paid for twice.
Some failures are not retried, because retrying would give the same answer. A voice that the upstream provider has withdrawn is the typical case. Those jobs fail immediately, with the cause stated.
When an audio fails for good, two things happen:
- no credits are deducted for audio that was never produced;
- you get an email in your account language, without the raw technical error. If more fail in the following hours, they are listed in the same place, and the message is sent at most once every six hours rather than flooding your inbox.
Once the component is back, you regenerate the failed items from My audios.
What our status page will not tell you
We do not publish an uptime percentage. Measuring one honestly requires an external probe with stored history, and we do not have that yet. A "99.9%" figure made up from memory is exactly the number a customer would copy into their own procurement requirements, and it would commit them, not us.
Our incident log is dated: it opened on 6 August 2026 and says so. "No incidents recorded" means since that date, not since forever.
What we do offer is a public /api/health endpoint that returns an HTTP 503 status code when any component is down, not just a flag buried in the response body. If your technical team already monitors its dependencies, they can add that address and get alerted at the same time we do.
The short version
During an outage, your articles display normally, the player steps aside instead of breaking, and queued jobs are retried. Afterwards, check My audios for anything flagged as failed and regenerate it.
And whichever tool you end up choosing, ask it the question this post answers: what do my readers see when you are down? How a vendor answers tells you more about how the product was built than any feature list.
Give your articles a voice with WeDispatch
This blog is itself voiced by WeDispatch. Curious how it sounds on your content?
Book a demo