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

> A provider can return 429 for a temporary resource condition, including a conflicting operation, rather than a request limit caused by your client.

- Canonical URL: https://update.dsesecurity.com/updates/dse-20260909-471-inspect-the-provider-error-before-treating-every-azure-http-429-as-quota-exhaustion/
- Publisher: Detection Systems & Engineering (DSE Security)
- Author: DSE Security Editorial Team
- Published: 2026-09-10T00:24:05+00:00
- Modified: 2026-09-10T02:08:05+00:00
- Last reviewed by DSE: 2026-09-09
- Resource type: Guide
- DSE priority: Information
- Topics: Cybersecurity, Networks & Infrastructure
- Reading time: 2 minutes

## What you need to know

A provider can return 429 for a temporary resource condition, including a conflicting operation, rather than a request limit caused by your client.

## Potentially affected

Automation handling Azure Resource Manager and resource-provider API responses.

## DSE recommendation

Preserve the provider error details and retry guidance before choosing a throttling remedy.

## Article

## 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](https://learn.microsoft.com/en-us/azure/azure-resource-manager/management/request-limits-and-throttling).

## 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](https://learn.microsoft.com/en-us/azure/azure-resource-manager/management/request-limits-and-throttling). Source retrieved September 9, 2026.

## Primary reference

- Name: Understand how Azure Resource Manager throttles requests - Azure Resource Manager | Microsoft Learn
- Authority: Microsoft Learn
- URL: https://learn.microsoft.com/en-us/azure/azure-resource-manager/management/request-limits-and-throttling
- Source publication date: Not stated by the source

## Citation and use

Preferred citation: “Inspect the provider error before treating every Azure HTTP 429 as quota exhaustion,” DSE Security, https://update.dsesecurity.com/updates/dse-20260909-471-inspect-the-provider-error-before-treating-every-azure-http-429-as-quota-exhaustion/
Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/
Usage and citation policy: https://update.dsesecurity.com/usage/
Copyright © 2026 Detection Systems & Engineering. All rights reserved.