ServerBusy
Azure Storage returns `ServerBusy` (503) when request load exceeds what the target partition/account can handle at that moment.
Last reviewed: March 1, 2026|Editorial standard: source-backed technical guidance
What Does Server Busy Mean?
Requests are temporarily throttled for service protection, so clients must slow down and retry using resilient pacing.
Common Causes
- -Traffic bursts exceed per-partition request handling capacity.
- -Client retry storms amplify transient throttling into sustained overload.
- -Access pattern concentrates requests on a small key range (hot partition).
- -Concurrent batch jobs spike load above account-level scalable targets.
How to Fix Server Busy
- 1Implement exponential backoff with jitter and respect retry guidance from responses.
- 2Reduce request concurrency and spread traffic across broader partition key space.
- 3Batch or queue non-urgent operations to flatten peak demand windows.
- 4Retry only idempotent operations and cap retry budgets to avoid feedback loops.
Step-by-Step Diagnosis for Server Busy
- 1Capture 503 frequency, request IDs, latency, and throughput metrics during the incident window.
- 2Identify whether failures correlate with specific partitions, operations, or workload spikes.
- 3Inspect retry behavior for synchronized retry waves that create recurring load spikes.
- 4Retest with reduced concurrency and improved key distribution strategy.
Throttle Pattern Attribution
- -Correlate ServerBusy events with specific workload phases (example: hourly batch fan-out causes repeat 503 bursts at minute 00).
- -Differentiate partition hotspot from account-wide pressure (example: one blob prefix dominates failed requests).
Client Retry Control Validation
- -Inspect retry interval randomization (example: all workers retry at fixed 1s interval, sustaining throttling).
- -Audit idempotency guarantees before retries (example: non-idempotent write retries cause duplicate-side effects under pressure).
How to Verify the Fix
- -Run workload replay and confirm ServerBusy rate falls to acceptable baseline.
- -Validate latency and success-rate improvements under peak traffic simulation.
- -Ensure retry/backoff policy behaves as designed during controlled load spikes.
How to Prevent Recurrence
- -Adopt adaptive client throttling and queue-based smoothing for bursty producers.
- -Design partition keys to distribute access evenly across storage partitions.
- -Enforce centralized retry policy defaults across all services that touch storage.
Pro Tip
- -add canary load probes per key prefix to detect emerging partition hotspots before customer traffic trips 503 thresholds.
Decision Support
Compare Guide
429 Too Many Requests vs 503 Service Unavailable
Use 429 for caller-specific throttling and 503 for service-wide outages, so retry behavior, escalation paths, and incident ownership stay correct.
Compare Guide
AWS ThrottlingException vs GCP RESOURCE_EXHAUSTED
Compare AWS ThrottlingException and GCP RESOURCE_EXHAUSTED to separate rate limiting from quota/resource exhaustion and choose the remediation path.
Playbook
Availability and Dependency Playbook (500 / 503 / ServiceUnavailable)
Use this playbook to separate origin-side 500 failures from temporary 503 dependency or capacity outages, then apply safe retry and escalation paths.
Playbook
Rate Limit Recovery Playbook (429 / ThrottlingException / RESOURCE_EXHAUSTED)
Use this playbook to separate transient throttling from hard quota exhaustion and apply retry, traffic-shaping, and quota-capacity fixes safely.
Official References
Provider Context
This guidance is specific to Azure services. Always validate implementation details against official provider documentation before deploying to production.