An Azure search service with built-in artificial intelligence capabilities that enrich information to help identify and explore relevant content at scale.
Hi Valentin Baca,
From what you described, this kind of error usually happens when the Speech service in a specific region temporarily runs out of available synthesis workers. It is generally not related to your subscription quota or any configuration problem in your code.
There are a few signs in your error that point to this situation.
The response shows StatusCode ResourceExhausted with the message saying there is no free synthesizer available. The WebSocket connection is closing with code 1013. The issue appears during periods of higher traffic. The same workload works in another region such as East US but fails in North Europe.
When these things appear together, it usually means the regional service pool is under heavy demand at that moment. If all synthesizer workers in that region are busy, the service starts rejecting new synthesis requests even though your subscription still has capacity. Because the workers are temporarily unavailable, retrying the request during the same busy window can still fail.
A few practical things that often help in situations like this.
First, try routing a small portion of requests to another region as a quick comparison. Since you already saw the same workload succeed in East US, that strongly suggests the issue is regional rather than something in the application.
Second, if your application sends requests in bursts, it can help to spread them out slightly. Even if the total number of requests is within limits, short spikes can sometimes trigger this behavior.
Third, if you are processing longer or bulk text synthesis jobs, batch style processing tends to be more stable than many real time synthesis calls during busy periods.
It is also worth occasionally checking Azure Service Health or Speech service updates because regional capacity events sometimes show up there, even if everything initially looks normal.
Since your setup has not changed and the same calls work in another region, this does not look like a regression in your code or SDK usage. It is more consistent with temporary availability fluctuations in the voice synthesis pool of that region.
If the behavior continues only in North Europe while other regions remain stable, using a simple multi region fallback approach is usually a reliable way to handle it until the regional capacity stabilizes.
Hope this helps explain what might be happening. If you notice the same behavior appearing in other regions as well, it would be interesting to see whether the pattern is similar.
Do let me know if you have any further queries.
If this answers your query, please do click Accept Answer and Yes for was this answer helpful.
Thankyou!