Traffic throttling and quota-capacity exhaustion under load.
Last reviewed: February 13, 2026|25 mapped errors|Page 2 of 2
Rate-limit errors occur when request volume, burst pattern, or allocated quota exceeds what the service will currently accept.
Provider-specific error pages mapped to this category (25 total). Showing 16-25.
ARM returns `ResourceQuotaExceeded` when a deployment exceeds quota limits at subscription, resource group, or region scope.
Azure Storage returns `ServerBusy` (503) when request load exceeds what the target partition/account can handle at that moment.
Azure returns `StorageAccountQuotaExceeded` when storage account capacity, ingress/egress, or request-rate limits are exceeded for the workload.
Azure surfaces `StorageContainerQuotaExceeded` when container/account growth or throughput constraints block additional storage operations.
ARM returns `SubscriptionRequestsThrottled` when subscription or tenant request limits are exceeded and the control plane responds with throttling.
Azure reports `VMProvisioningStateFailed` when virtual machine provisioning ends in a failed state during OS, extension, image, or dependency setup.
GCP QUOTA_EXCEEDED commonly appears as an `ErrorInfo.reason` when a quota dimension is exhausted for the current request context.
GCP RESOURCE_EXHAUSTED means a quota, rate limit, or finite backend capacity was exhausted for the request.
GCP SERVICE_DISABLED means the target Google Cloud API is disabled for the consumer project, so requests are rejected until that service is enabled.
HTTP 429 Too Many Requests means the client sent too many requests in a given amount of time.
Compare Guide
Use 429 for caller-specific throttling and 503 for service-wide outages, so retry behavior, escalation paths, and incident ownership stay correct.
Compare Guide
Compare AWS ThrottlingException and GCP RESOURCE_EXHAUSTED to separate rate limiting from quota/resource exhaustion and choose the remediation path.
Playbook
Use this playbook to separate transient throttling from hard quota exhaustion and apply retry, traffic-shaping, and quota-capacity fixes safely.
No. Retry only idempotent operations with bounded backoff and jitter. Non-idempotent writes require idempotency keys or deduplication.
They start when many clients retry at fixed intervals. Synchronized retries amplify traffic and extend outage duration.
Errors persist across retry windows and traffic smoothing, and provider telemetry shows sustained quota saturation rather than short burst rejection.