ContainerNotFound
Azure Blob service returns `ContainerNotFound` (404) when the specified blob container does not exist.
Last reviewed: February 12, 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 Container Not Found Mean?
Blob operations fail at path resolution, so uploads, reads, and metadata calls stop until the target container exists in the addressed account.
Common Causes
- -Container name in the request URI is wrong or no longer exists.
- -Request targets the wrong storage account endpoint for the intended container.
- -Container was deleted, never created, or created in a different environment account.
- -Automation uses mixed-case or invalid naming patterns while container names must be lowercase.
How to Fix Container Not Found
- 1Verify the storage account endpoint and container segment used in the request URI.
- 2List containers in the target account and confirm exact container name presence.
- 3Create the missing container when workflow expects auto-provisioned storage paths.
- 4Normalize container names to lowercase and align client configuration with deployed naming.
Step-by-Step Diagnosis for Container Not Found
- 1Capture the failing Blob request URI, status code, and
x-ms-request-id. - 2Validate account credentials and endpoint map to the same environment as the container.
- 3Check recent delete/create events for the container in Activity Logs and deployment history.
- 4Replay operation against a known-existing container to isolate path versus auth issues.
Container Address and Naming Validation
- -Inspect request URI path composition (example: client sends
/logs-prod-v2/while deployment created/logs-prod/). - -Validate naming rules at source (example: generated container name includes uppercase letters although Blob containers require lowercase and 3-63 length constraints).
Lifecycle and Provisioning Race Checks
- -Audit provisioning order for storage bootstrap steps (example: app starts blob writes before container-creation job runs).
- -Trace cross-environment secret mapping (example: production app points to staging account key where container set differs).
Seen in Production
New service instance writes to container before bootstrap job creates it
Frequency: common
Example: First writes fail with 404 until provisioning job finishes.
Fix: Run idempotent container creation during deployment and app startup preflight.
Environment key rotation points app to different storage account
Frequency: rare
Example: App looks for expected container in wrong account and receives ContainerNotFound.
Fix: Reconcile secrets, endpoint, and container inventory per environment before rollout.
Debugging Tools
- -az storage container exists
- -Blob request logs with x-ms-request-id
- -Storage account endpoint and key inspection
- -Deployment timeline for container bootstrap steps
How to Verify the Fix
- -Re-run the same blob operation and confirm
ContainerNotFoundis resolved. - -Validate read/write operations succeed for the target container across app instances.
- -Confirm monitoring shows disappearance of repeated 404 container path failures.
How to Prevent Recurrence
- -Provision required containers as explicit IaC resources before application rollout.
- -Add startup checks that assert container existence in the configured account endpoint.
- -Centralize container naming constants to prevent drift between services and pipelines.
Pro Tip
- -include an idempotent
create-if-not-existsbootstrap step guarded by environment tags to eliminate first-request race conditions safely.
Official References
Provider Context
This guidance is specific to Azure services. Always validate implementation details against official provider documentation before deploying to production.