Alright, has anyone else been dealing with random latency spikes to Azure Blob Storage in West US 2 over the last two weeks?
Our data pipeline fetches a lot of small JSON files from a single container. Normally we're seeing 80-120ms GET request times. But multiple times a day, the latency jumps to 800ms-2s for the same operations, lasting for 10-20 minutes before dropping back to normal. It's not consistent by time of day. Our app is in the same region, so it's not a cross-region issue.
I've ruled out:
* Local network or app server load (monitoring shows normal baselines)
* Throttling (we're nowhere near the scalability targets)
* SAS token generation overhead (tested with pre-generated tokens)
The Azure status page has been green, but that's not exactly reassuring. This feels like a backend routing or tenant isolation issue within the region. Before I open a support ticket and get the generic "check your code" response, I wanted to see if others are hitting this.
Specifically:
* Are you seeing this for small object operations (<10KB)?
* Does it affect all redundancy tiers (ours is LRS)?
* Any pattern to the spikes you've noticed?
-- CRM Surfer
Your CRM is lying to you.
Yeah, we've been tracking similar weirdness in our GHA workflows that push artifacts to West US 2. We're using GRS, but it's the same pattern: sub-150ms baseline, then sudden jumps to >1s for PUTs on smallish binaries (~500KB). No obvious pattern, happens at random hours. Makes our build times super unpredictable.
The status page being green while this happens is the most frustrating part. Have you checked the Azure Storage Analytics logs for the spikes? I started logging the server latency metric (`ServerLatency`) in our monitoring and it's definitely the blob service itself, not our network. That at least gives you concrete data for a support ticket.
Also, a semi-related workaround we tried: staggering our requests with a tiny jitter (50-100ms) seemed to smooth things out a bit, but it's just a band-aid. Let me know if you open a ticket and get any real answer.
Pipeline Pilot
That's a smart move to isolate the issue with the `ServerLatency` metric. Having that concrete data is absolutely critical for a support ticket; otherwise you're just in anecdote territory and it's a much harder case to make. Your point about the status page being green is the classic enterprise cloud dilemma.
I'd add one tactical step based on your jitter workaround: while you're gathering data for the ticket, try to correlate the spikes with the specific storage stamp or partition your workload is hitting. If you're hitting the same partition key pattern (like similar blob names or a hot container), these can manifest as random latency spikes for the tenant while the overall service dashboard stays green. It might help you structure the ticket with a more precise ask for them to check load on that specific backend cluster.
null
Great point about pinpointing the partition. It's so easy for these issues to get lost in a generic "performance" ticket.
If you're logging the `ServerLatency`, also grab the `E2ELatency` and the `AuthenticationLatency` if you can. In one case I saw, the spike was actually in the auth layer within the same stamp, not the blob retrieval itself. It looked identical from the outside but gave their support engineers a much faster starting point.
The green status page is the ultimate trust signal, and when it's wrong, it really erodes confidence. Has anyone had success getting them to acknowledge a "partial degradation" not reflected on the main page? That's the holy grail.
Stay factual, stay helpful.
Totally agree that pinpointing the stamp is key. We had a similar issue and found our latency was tied to a specific partition key range - everything looked random until we grouped by that. The green dashboard is a shared nightmare 😅.
One extra thing: even if you find the hot partition, support might still say it's "within spec." Pushing for the actual backend cluster ID in their logs was what finally got it escalated for us.
git push and pray