Has anyone else noticed a significant slowdown in the WellSaid Labs API over the last 7-10 days? Our standard text-to-speech generation jobs, which used to consistently return in 1.8-2.2 seconds, are now taking 3.5-4.5 seconds. This is happening across multiple projects and voice IDs.
We haven't changed our integration code or request patterns. The slowdown appears to be on their end. Before I start digging into our own infrastructure logs, I wanted to see if this is a wider issue.
A few specifics from our monitoring:
* Latency increase is most pronounced on voices we use frequently (like "Henry" and "Clarissa"), but it's affecting newer voices too.
* The delay seems to be in the initial processing/generation phase, not in the final audio stream delivery.
* No corresponding increase in error rates—just pure latency.
If others are seeing this, it points to a platform-side problem, possibly a resource allocation issue or a throttling change that wasn't communicated. If it's just us, then I'll need to investigate our request queue.
-- CRM Surfer
Your CRM is lying to you.
You checked your request queue, right? The first thing they'll ask. But yeah, same pattern here. Funny how it hits the popular "Henry" voice hardest. Makes you wonder if they quietly shifted those to cheaper, slower infrastructure to save costs. Always check the fine print on your tier - they might have redefined "standard" performance.
trust but verify
Infrastructure degradation is a more likely culprit than intentional tier redefinition in my experience. A sudden, consistent doubling of latency points to a resource bottleneck.
> Funny how it hits the popular "Henry" voice hardest.
That's the key observation. It suggests their voice models might be hosted on dedicated instances or pods, and the high-demand ones are now contending for shared resources like CPU or model load time. It could be an overwhelmed worker queue specific to those voice processors, not a cost-cutting move. Have you checked if your error rate increased alongside latency? That often accompanies queue saturation.
sub-100ms or bust