Fix: 429 TooManyRequests (Azure)

A 429 TooManyRequests from Azure means some throttling layer judged your call rate too high and rejected the request before doing the work. Azure throttles at several independent levels: Azure Resource Manager for management operations, per service data plane limits, and provisioned throughput systems like Cosmos DB request units. The response usually includes a Retry-After header stating exactly how long to wait, which makes the immediate handling mechanical. The durable fix depends on which layer throttled you.

429 TooManyRequests (Azure)

What this error means

Azure enforces rate limits to protect shared infrastructure and to meter provisioned capacity. Management plane calls (anything through management.azure.com, including Terraform, the CLI, and the portal) are throttled per principal and per subscription by Azure Resource Manager. Data plane services each carry their own limits: Storage accounts have IOPS and bandwidth targets, Key Vault has per vault transaction limits, Azure OpenAI has tokens per minute, and Cosmos DB rejects operations that exceed provisioned RU/s with this status. In every case the request was valid; the platform is telling you to slow down, wait the advertised interval, and reconsider the demand pattern.

Common causes

• Infrastructure automation (Terraform, scripts, operators) making bursts of ARM reads and writes, especially list calls in loops.
• A Cosmos DB workload exceeding provisioned RU/s, or a hot partition key exhausting one partition’s share while the container looks fine.
• Bursty application traffic against per service limits: Key Vault secrets fetched on every request instead of cached, Storage hot spots on one blob or partition.
• Retry loops without backoff multiplying a small overrun into sustained throttling.
• Many workloads sharing one subscription or one service instance, so combined traffic hits limits nobody sees individually.
• Under provisioned capacity after growth: autoscale ceilings or fixed RU/s set months ago for smaller traffic.

How to fix it

STABILIZE first. Reduce the offered load: pause the automation or batch job that spiked, and confirm clients honor Retry-After so the remaining traffic gets through.

1. DIAGNOSE the throttled layer. For management plane throttling, check the rate limit headers on any ARM response:

az rest --method get \
  --url "https://management.azure.com/subscriptions/<sub-id>/resourcegroups?api-version=2021-04-01" \
  --verbose

Look for x-ms-ratelimit-remaining-subscription-reads and its relatives approaching zero, and a Retry-After header on the 429 itself.

2. For a specific service, pull its throttling metrics. Cosmos DB shows throttled requests and per partition consumption:

az monitor metrics list \
  --resource /subscriptions/<sub-id>/resourceGroups/rg/providers/Microsoft.DocumentDB/databaseAccounts/mydb \
  --metric TotalRequestUnits,NormalizedRUConsumption \
  --interval PT5M

A NormalizedRUConsumption pinned at 100 percent while total RU usage looks moderate is the signature of a hot partition.

3. FIX the client side. Keep the Azure SDK retry policies on (they honor Retry-After), add exponential backoff with jitter to any raw REST calls, and cap concurrency in batch workers so steady state demand fits under the limit.

4. FIX the capacity if demand is legitimate. For Cosmos DB, raise throughput or switch to autoscale:

az cosmosdb sql container throughput update \
  --account-name mydb --database-name appdb --name orders \
  --resource-group rg \
  --max-throughput 10000

For other services, scale the unit that carries the limit: split traffic across Key Vaults or Storage accounts, request higher Azure OpenAI quota, or distribute automation across principals and subscriptions where the design allows it.

5. FIX the access pattern where capacity is not the real issue: cache Key Vault secrets and configuration at startup with periodic refresh, batch small operations, and redesign hot Cosmos DB partition keys so load spreads across ranges.

How to prevent it

• Alert on throttling metrics per service (429 counts, RU consumption, rate limit headers trending toward zero) before users notice.
• Keep SDK default retry policies in place and treat any custom retry code as a review item.
• Cache aggressively in front of per transaction limited services like Key Vault.
• Choose Cosmos DB partition keys with high cardinality and even access, and validate with the partition metrics before launch.
• Give heavy automation its own service principals and schedule it off peak, so management plane bursts cannot starve deploys.

When to call a senior engineer

Call for help when throttling persists after retries and capacity increases, when a hot partition key needs a redesign on a container with production data, or when nobody can say which of five workloads sharing a subscription is eating the limits. Erzon engineers can trace the throttled scope from metrics and headers, restructure the data model or traffic pattern to fit real Azure limits, and set up the alerting that turns the next 429 wave into a non event.