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|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 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).
Seen in Production
Nightly ETL fan-out floods a narrow blob prefix
Frequency: common
Example: Storage returns repeated 503 ServerBusy during the first ingestion burst.
Fix: Distribute prefixes and throttle producer concurrency with jittered retries.
Incident retry storm from multiple microservices
Frequency: rare
Example: Simultaneous retries prevent partition recovery and prolong throttling.
Fix: Centralize retry policy with capped budgets and circuit-breaker fallbacks.
Debugging Tools
- -Storage request metrics and 503 tracking
- -Retry telemetry by client/service
- -Partition key heatmap analysis
- -Load-test replay with controlled concurrency
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
Official References
Provider Context
This guidance is specific to Azure services. Always validate implementation details against official provider documentation before deploying to production.