AZURE
TooManyRequests - Too Many Requests: ARM API Rate Limit Exceeded
You're hitting ARM's rate limits—sending requests faster than the per-subscription limits allow for your authenticated principal. This 429 client-side error means ARM throttled your requests after exceeding the limit for this operation type (limits vary by operation and resource type, and aren't publicly documented). ARM tracks rate limits per subscription and principal, so concurrent requests from multiple processes can compound. The response includes a Retry-After header specifying the minimum wait time before retrying. Common during bulk VM operations, AKS cluster management, Azure SQL batch operations, and App Service deployments.
#Common Causes
- →ARM API Rate Limit Exceeded: Your request count exceeds the subscription-level limit for this operation type. Rate limits vary by operation type (read operations typically have higher limits than write operations) and aren't documented. The Retry-After header tells you how long to wait before retrying.
- →Service-Specific Rate Limits: Different Azure services (Storage, Compute, etc.) have their own throttling limits that may be more restrictive than ARM's general limits. You may be hitting service-specific limits in addition to ARM limits.
- →Concurrent Request Bursts: Multiple simultaneous requests exceed service capacity. ARM doesn't queue requests—excess requests immediately receive 429 responses. Rate limit counters reset over time, but the reset interval isn't documented and may vary.
✓Solutions
- 1Step 1: Diagnose - Check the Retry-After header value in the response headers (in seconds). This tells you the minimum wait time before retrying.
- 2Step 2: Fix - Wait at least the duration specified in the Retry-After header before retrying.
- 3Step 3: Fix - Implement client-side throttling to limit concurrent requests and prevent bursts. Use a rate limiter or queue to space out requests.
- 4Step 4: Fix - Use exponential backoff with Retry-After support when retrying. Wait at least the duration specified in the Retry-After header, then retry. If you still get 429, wait longer (exponential backoff).
- 5Step 5: Verify - After implementing throttling and retry logic, retry your operation. It should succeed with HTTP 200/201 instead of 429 TooManyRequests.
</>Code Examples
Rate Limiting and Retry Logic
1# This script demonstrates rate limiting and retry logic for TooManyRequests errors
2
3# Step 1: Retry function with exponential backoff
4retry_with_backoff() {
5 local max_attempts=$1
6 local base_delay=$2
7 local max_delay=$3
8 local attempt=1
9 shift 3
10 local command="$@"
11
12 while [ $attempt -le $max_attempts ]; do
13 echo "Attempt $attempt of $max_attempts..."
14
15 if eval "$command" 2>&1; then
16 echo "Success! Operation completed on attempt $attempt"
17 return 0
18 else
19 ERROR_CODE=$?
20
21 # Check if error is 429 TooManyRequests
22 if [ $ERROR_CODE -eq 0 ]; then
23 # Check for Retry-After header in response (if available)
24 # Note: Azure CLI doesn't expose Retry-After header directly
25 # You may need to parse the error message or use REST API directly
26 echo "Operation failed. Checking for rate limiting..."
27 fi
28
29 if [ $attempt -lt $max_attempts ]; then
30 # Calculate delay with exponential backoff
31 DELAY=$((base_delay * (2 ** (attempt - 1))))
32 if [ $DELAY -gt $max_delay ]; then
33 DELAY=$max_delay
34 fi
35
36 echo "Rate limit exceeded. Waiting $DELAY seconds before retry..."
37 sleep $DELAY
38 attempt=$((attempt + 1))
39 else
40 echo "Failed after $max_attempts attempts"
41 return 1
42 fi
43 fi
44 done
45}
46
47# Step 2: Example usage - List resource groups with retry logic
48echo "Listing resource groups with retry logic..."
49retry_with_backoff 5 2 60 "az group list --output table"
50
51# Step 3: Example usage - Create resource with retry logic
52# RG_NAME="my-resource-group"
53# LOCATION="eastus"
54# echo "Creating resource group with retry logic..."
55# retry_with_backoff 5 2 60 "az group create --name $RG_NAME --location $LOCATION --output table"
56
57# Step 4: Rate limiting best practices
58echo ""
59echo "Rate limiting best practices:"
60echo " 1. Implement exponential backoff (start with 2 seconds, double each retry)"
61echo " 2. Respect Retry-After header when available"
62echo " 3. Limit concurrent requests (use queues or semaphores)"
63echo " 4. Batch operations when possible"
64echo " 5. Cache results to reduce API calls"
65echo " 6. Monitor rate limit usage in Azure Monitor"↗Related Errors
Provider Information
This error code is specific to AZURE services. For more information, refer to the official AZURE documentation.