About Azure Speech Custom Endpoint scaling

@Siarhei Lukashenka - Based on the current Azure Speech Service documentation, Microsoft does not provide a customer-configurable setting to increase the number of pre-warmed/standby instances or reserve a larger baseline capacity for a hosted Custom TTS endpoint. Azure Speech manages scaling automatically, and customers cannot directly configure the minimum number of backend instances kept ready to serve requests.

It is also important to distinguish quota from service capacity. Quota defines the throughput limit available to the resource, whereas autoscaling and backend capacity determine how quickly the service can accommodate a sudden increase in demand. The Speech Service documentation explains that when traffic increases rapidly, throttling can occur while the service is scaling to meet the additional demand; in that situation, simply increasing the quota does not resolve the underlying scale-out delay.

For sudden traffic spikes, Microsoft recommends gradually ramping the workload where possible and implementing retry logic with appropriate backoff rather than sending a large instantaneous increase in traffic. These measures can reduce the likelihood of transient failures while the service is scaling.

For your specific question, however, there is currently no documented mechanism to request or configure a larger always-warm pool for a hosted Speech endpoint.

If you continue to see ResourceExhausted: No tokens available for passthrough (WebSocket Error 1013) while remaining within your expected quota and traffic limits, I recommend opening an Azure Support request. The Speech engineering team can then review the backend telemetry for your particular endpoint, region, voice, and traffic pattern to determine whether backend capacity or scale-out behavior is contributing to the failures and whether any service-side mitigation is available.

If possible, please provide the region, voice/custom endpoint, approximate request/concurrency level during the burst, and UTC timestamps of several failed requests. Also, if the same requests succeed after a short retry delay, that would be useful information when investigating whether the failures are transient.

References:

• Azure Speech quotas and limits: Azure Speech quotas and limits
• Azure Speech Service documentation: Azure Speech Service documentation

Hope this help!

Yes, that is a plausible explanation, but I would be careful about treating the ResourceExhausted: No tokens available for passthrough (WebSocket Error 1013) message as direct evidence that you've hit a quota limit.

The key distinction is that Azure Speech quotas define what you are allowed to consume, whereas a custom TTS endpoint must still have sufficient runtime capacity available to serve incoming requests. As a result, it is possible to see ResourceExhausted errors during a sudden burst even when your measured request rate is below the configured quota. [learn.microsoft.com]

One aspect worth checking is whether the burst creates a very high number of simultaneous synthesisation requests rather than simply a high requests-per-second rate. Custom endpoints have concurrency-related limits and internal capacity constraints that can become the bottleneck before an overall quota is reached.

A useful test is to compare these two scenarios:

• A steady load at the same average throughput.
• A short, sharp burst that reaches the throughput immediately.

If the steady load succeeds but the burst produces 1013 errors, that strongly suggests a transient capacity or scale-out effect rather than a quota exhaustion issue.

I would also monitor:

• Peak concurrent synthesis requests.
• Connection establishment rate for WebSocket clients.
• Percentage of requests failing only during burst windows.
• Whether failures disappear after a brief retry delay.

If errors occur only during sudden traffic spikes and recovery is quick, that aligns with temporary backend capacity availability while the service adjusts to the new demand. If the same errors continue at a stable and sustained load level, then the issue is more likely related to endpoint-specific concurrency or service capacity rather than autoscaling lag alone. [learn.microsoft.com]

Help make this community better for everyone: if this answer resolved your issue, please accept it or leave an upvote. If not, share more details in a comment so we can continue the discussion and find the right solution.