SubscriptionRequestsThrottled
ARM returns `SubscriptionRequestsThrottled` when subscription or tenant request limits are exceeded and the control plane responds with throttling.
Last reviewed: February 11, 2026|Source-backed guidance under our editorial policy
Start Here
Use the closest compare guide, playbook, or adjacent error page to narrow the decision faster before you start changing production systems.
This page is part of the Error Reference library. Learn more about the project or report a correction.
What Does Subscription Requests Throttled Mean?
Control-plane calls are rate-limited, so deployments and automation slow down or fail until request volume returns below throttling thresholds.
Common Causes
- -High parallel deployment activity saturates subscription-level ARM request buckets.
- -Retry storms ignore server pacing and amplify control-plane pressure.
- -Multiple service principals hit the same throttled operation family simultaneously.
- -Metrics-heavy polling patterns consume disproportionate ARM request capacity.
How to Fix Subscription Requests Throttled
- 1Honor
Retry-Afterexactly and pause retries until the server-advised window expires. - 2Apply exponential backoff with jitter and strict retry budgets in all callers.
- 3Reduce concurrent deployment workers and batch high-volume management reads.
- 4Move high-frequency metrics collection to batch APIs where available.
Step-by-Step Diagnosis for Subscription Requests Throttled
- 1Capture failing responses, including 429 status,
Retry-After, and request correlation IDs. - 2Identify which operation type and scope are throttled (subscription, tenant, or provider-specific).
- 3Measure caller concurrency, retry fan-out, and burst windows during throttling events.
- 4Retest with lower concurrency and compliant backoff to confirm throttling recovery.
Throttle Scope Attribution
- -Distinguish subscription-wide throttling from provider-specific throttling (example:
Microsoft.Computeoperations throttled while unrelated provider calls still succeed). - -Correlate throttled requests with operation types and principal identities (example: read-heavy inventory job drains tokens before deployment window).
Client Retry and Concurrency Shaping
- -Audit retry logic for missing jitter or unbounded retries (example: synchronized workers retry at the same second and recreate bursts).
- -Trace rollout orchestration fan-out (example: one release launches parallel resource-group deploys beyond safe request budget).
Seen in Production
Large release fans out parallel ARM deployments across many resource groups
Frequency: common
Example: 429 spikes appear with Retry-After values and rollout stalls intermittently.
Fix: Throttle orchestrator concurrency and enforce centralized backoff policy.
Monitoring job polls ARM metrics endpoint too aggressively
Frequency: rare
Example: Background reads consume request budget and deployment writes start getting throttled.
Fix: Switch to batch metrics queries and lower polling cadence for control-plane APIs.
Debugging Tools
- -ARM request/response logs with Retry-After
- -Azure Monitor ARM throttling metrics
- -Pipeline concurrency telemetry
- -Distributed trace correlation IDs
How to Verify the Fix
- -Repeat throttled workflows and confirm 429 responses drop to expected baseline levels.
- -Verify end-to-end deployment latency stabilizes after backoff and concurrency adjustments.
- -Track ARM metrics to ensure sustained operation below throttling thresholds.
How to Prevent Recurrence
- -Define per-environment request budgets and enforce them in deployment orchestrators.
- -Use centralized retry middleware with jitter, cap, and circuit-breaker behavior.
- -Schedule bursty control-plane jobs outside critical deployment windows.
Pro Tip
- -stagger pipelines by operation class (read/list vs write/deploy) so token buckets refill predictably instead of competing in the same burst window.
Decision Support
Official References
Provider Context
This guidance is specific to Azure services. Always validate implementation details against official provider documentation before deploying to production.