BlobNotFound
Azure BlobNotFound means the container resolved, but the exact blob name, version, or snapshot requested does not exist at that address.
Last reviewed: April 24, 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 Blob Not Found Mean?
The storage account and container path are far enough to reach blob lookup, but Azure cannot resolve the requested blob identity. The useful boundary is exact blob address: account, container, virtual-directory segments, casing, encoded characters, version/snapshot query, and whether the producer actually wrote that blob.
Common Causes
- -Producer and consumer build different blob names because date partitions, tenant prefixes, extensions, or virtual-directory segments drifted.
- -Blob casing or URL encoding differs between the stored name and the read request.
- -The request targets the wrong storage account, endpoint suffix, container, or environment for the intended blob.
- -A requested version ID or snapshot no longer exists or was never created for that blob.
- -Lifecycle management, delete jobs, overwrite workflows, or rename-by-copy/delete logic removed the current blob before consumers read it.
How to Fix Blob Not Found
- 1Confirm the storage account and container first, then list the nearest stable prefix and compare exact blob names.
- 2Trace the blob name emitted by the producer at write time and the blob name requested by the consumer at read time.
- 3Verify casing, URL encoding, version ID, snapshot timestamp, and endpoint/account selection before regenerating data.
- 4If the requested blob was never produced, fix the producer contract or update the stored canonical blob URI.
- 5If the blob existed and disappeared, inspect lifecycle, copy/delete, overwrite, and retention events around the incident window.
Step-by-Step Diagnosis for Blob Not Found
- 1Capture account endpoint, container, full blob name, version/snapshot query, caller, and
x-ms-request-idfrom the failing operation. - 2Confirm the container exists, then run a prefix listing near the expected blob path and look for casing, delimiter, extension, or encoding near-matches.
- 3Compare the canonical blob URI in producer metadata, queue messages, manifests, or database rows with the runtime read URI.
- 4Inspect lifecycle management, versioning, soft delete, copy/delete, and overwrite events around the failure window.
- 5Replay the read once with the exact listed blob name and once with the application-generated name to separate key construction from storage state.
Seen in Production
- -An export job writes
exports/2026/04/report.csv, but a notification worker still requestsexports/2026-04-report.csv. - -A thumbnail pipeline uploads
images/original/..., while the frontend requestsimages/resized/...before the resize job finishes. - -A file named
quarterly report.pdfis stored with a literal space, but a downstream URL builder requests a differently encoded path. - -A rollback job requests an old snapshot timestamp after snapshot retention has already removed it.
Blob Address and Key Integrity
- -Trace blob name generation end to end, including account, container, tenant prefix, virtual-directory segments, extension, casing, and date partition format.
- -Verify URL encoding and casing behavior in client libraries before blaming Azure availability.
Versioning, Snapshot, and Lifecycle Validation
- -Inspect version and snapshot parameters on read requests and confirm the target still exists.
- -Correlate not-found events with lifecycle rules, soft-delete windows, retention policies, copy/delete workflows, and overwrite jobs.
Decision Shortcut: Blob Missing vs Scope Wrong
- -If the storage account or container does not resolve, move to account/container diagnostics first.
- -If prefix listing shows a near-match, stay on blob-name construction, casing, or encoding.
- -If the blob existed and then disappeared, inspect lifecycle, deletion, overwrite, and snapshot retention before changing readers.
Wrong Fix to Avoid
- -Do not widen RBAC or regenerate SAS tokens when the request is reaching blob lookup and the blob name is absent.
- -Do not retry the same read forever if the producer never emitted that exact blob URI.
- -Do not patch one consumer path while other services still rebuild blob names differently.
Implementation Examples
2026-04-24T09:19:44Z account=mediaeast container=exports
requestedBlob=exports/2026-04/report.csv producerBlob=exports/2026/04/report.csv
status=404 error=BlobNotFound xMsRequestId=7f2b4c1a-801e-0042-6c10-9e12b0000000az storage blob list \
--account-name mediaeast \
--container-name exports \
--prefix 'exports/2026' \
--query '[].name'const blobName = uploadEvent.blobName;
const client = containerClient.getBlobClient(blobName);
const download = await client.download();Incident Timeline
09:18 UTC
A consumer requests a blob URI derived from stale or divergent metadata
Signal: The read path emits a blob name that differs from producer output by prefix, casing, encoding, extension, version, or snapshot.
Why it matters: The first useful question is whether this exact blob identity was ever written.
09:19 UTC
Azure resolves the container but returns BlobNotFound
Signal: Container-level lookup succeeds, blob lookup fails, and downstream download, render, or batch processing breaks.
Why it matters: The incident is now blob identity, not broad storage availability.
09:23 UTC
Retries repeat the same missing blob address
Signal: Workers replay the same generated URI and receive deterministic 404 responses.
Why it matters: Retries only help if the producer is about to create the blob; otherwise the address must change.
09:31 UTC
The canonical blob URI is restored or produced
Signal: Consumers switch to the stored producer-emitted URI, the blob is regenerated, or retention/snapshot targeting is corrected.
Why it matters: That confirms the failure lived in blob identity or lifecycle state.
Seen in Production
Reader service uses legacy key format after uploader changed naming convention
Frequency: common
Example: Uploader writes invoices/2026/02/file.json, reader still requests invoices-2026-02-file.json.
Fix: Version key-format contracts and migrate readers before switching producer output.
Rollback workflow requests old snapshot removed by retention policy
Frequency: rare
Example: Recovery job fails with BlobNotFound on deprecated snapshot ID.
Fix: Align rollback logic with snapshot retention and validate snapshot existence preflight.
Transformed asset is requested before background job writes it
Frequency: medium
Example: API returns the resized image URL immediately, but the resize worker has not committed that blob yet.
Fix: Publish transformed URLs only after commit, or expose pending state until the blob exists.
Wrong Fix vs Better Fix
Retry same URI vs prove producer output
Wrong fix: Replay the same Get Blob request and wait for it to eventually work.
Better fix: Find the producer event, queue message, or metadata row that should contain the canonical blob URI and compare it to the read URI.
Why this is better: BlobNotFound is deterministic unless the requested blob is later created or the request address changes.
Patch one reader vs centralize blob naming
Wrong fix: Fix casing or date formatting in a single consumer path only.
Better fix: Store the canonical blob URI from the write event or move blob-name construction into one shared helper.
Why this is better: Blob path drift recurs when each service independently reconstructs virtual-directory names.
Ignore versions vs inspect snapshots and retention
Wrong fix: Assume the blob never existed because the current read fails.
Better fix: Check versions, snapshots, soft-delete state, retention policy, lifecycle rules, and copy/delete events.
Why this is better: A missing current blob can hide retention cleanup or rename-by-copy/delete behavior.
Debugging Tools
- -az storage blob exists
- -Storage request logs with x-ms-request-id
- -Blob inventory/list queries
- -Application path-construction trace logs
How to Verify the Fix
- -Replay the failing operation and confirm the exact requested blob now resolves successfully.
- -Validate consuming services can read the canonical blob URI consistently across environments.
- -Confirm BlobNotFound rates drop in Azure Storage diagnostics, CDN logs, and application logs.
- -Test representative edge-case names with spaces, plus signs, unicode, casing, and tenant/date prefixes.
How to Prevent Recurrence
- -Centralize blob-name construction logic or persist the producer-emitted canonical blob URI.
- -Persist version IDs and snapshot timestamps where rollback or point-in-time reads require them.
- -Add integrity checks that verify referenced blobs exist before enqueueing downstream tasks.
- -Alert on unexpected lifecycle deletion, soft-delete, or retention events for critical prefixes.
Pro Tip
- -store a hash of the canonical blob URI alongside metadata so naming drift is detectable before runtime reads fail.
Official References
Provider Context
This guidance is specific to Azure services. Always validate implementation details against official provider documentation before deploying to production.