Azure Speech Fast Transcription repeatedly returns HTTP 429 despite very low usage — UK South, S0

Yes. Fast Transcription can return HTTP 429 even at very low observed usage.

Supported causes in the available guidance are:

1. Service-side rate limiting and transient throttling The Fast Transcription API enforces rate limits, and 429 is explicitly called out as a retryable condition.
2. Idle-to-active scale behavior A documented Microsoft Q&A resolution states that after the service has been idle, the first request can trigger scale-up and may be temporarily rejected with 429 while resources are being allocated.
3. High-concurrency or temporary service pressure The official guidance notes that rate limiting can occur during high-concurrency operations, and the service is described as elastic. That aligns with transient backend pressure even when the application itself is not sending many requests.

The provided material does not confirm any UK South-specific capacity limit, any Albanian-specific limit, or any S0 resource-level quota detail for this API beyond general throttling behavior. It also does not provide a diagnostic method that definitively separates throttling from backend capacity exhaustion.

The recommended resolution that does not require changing region or increasing quotas is:

1. Implement retry logic for 429 and transient failures
   • Retry up to five times.
   • Use exponential backoff of 2, 4, 8, 16, and 32 seconds.
   • Total backoff time: 62 seconds.
2. Retry the other documented transient conditions as well Retry on:
   • HTTP 429
   • HTTP 500, 502, 503, 504
   • status_code=None
   • SDK network errors such as ServiceRequestError and ServiceResponseError
   • Network exceptions such as ConnectionError, TimeoutError, and OSError
3. Do not retry client-side errors Do not retry:
   • HTTP 400
   • HTTP 401
   • HTTP 422
   • Other 4xx client errors
4. If uploading from a file stream in Python, reset the stream before each retry Call seek(0) before each retry attempt.
5. Consider periodic warm-up requests Microsoft Q&A guidance specifically suggests lightweight periodic warm-up requests to reduce first-call-after-idle 429 behavior.

For diagnostics, the supported checks are limited to confirming whether the failure pattern matches transient throttling behavior:

• Check whether the failure is HTTP 429 versus a client error such as 400/401/422.
• Check whether an immediate or short delayed retry succeeds.
• Check whether the 429 occurs mainly on the first request after a long idle period.
• If concurrent workers are used, check whether long waits or timeout-like failures also appear, because the default HTTP read timeout of 300 seconds can be exceeded under heavy rate limiting.

Based on the available guidance, the most evidence-based conclusion is that occasional 429 responses can occur even with very low request volume, especially after idle periods, and the primary mitigation is robust retry with exponential backoff plus optional warm-up traffic.

• Use the fast transcription API with Azure Speech in Foundry Tools (programming-language-python)
• Use the fast transcription API with Azure Speech in Foundry Tools (programming-language-rest)
• Fast Transcription API for Azure AI Foundry randomly returns 429 server too busy :-( - Microsoft Q&A
• Azure LLM Speech for transcription and translation (ai-foundry)