Inspect the provider error before treating every Azure HTTP 429 as quota exhaustion

Source facts

Some Azure resource providers return HTTP 429 for temporary conditions that are not caller-caused throttling. Microsoft’s example is the network provider’s RetryableErrorDueToAnotherOperation, returned when another operation locks the target resource. The response details distinguish these cases.

For a request-limit response, Retry-After gives the waiting period in seconds. A request sent before that period elapses is not processed and receives a new retry value. Resource providers also impose their own limits, separate from Resource Manager’s limits. Microsoft Learn.

Applicability

Identify the failing operation, resource provider, target and response body. Keep a transport status code separate from the more specific cause returned with it.

DSE recommendation

DSE recommends classifying the error before changing polling frequency, adding parallel workers or requesting capacity. For a conflicting operation, inspect its actual progress and ownership. For confirmed throttling, respect the returned delay and review the relevant request population. Retain sanitized response details so repeated failures can be compared without exposing credentials.

Verification

Test the client with representative recorded or explicitly synthetic throttling and operation-conflict responses. Confirm it preserves the specific error and follows the intended retry policy without issuing an immediate retry storm. Review the subsequent operation outcome independently; a delayed retry alone is not proof that either a quota issue or a resource lock has cleared.

Official references

Microsoft Learn: Understand how Azure Resource Manager throttles requests. Source retrieved September 9, 2026.