Forum Discussion
Azure Container Apps in Austria East fail after AssigningReplica and before PullingImage
We have a production Azure Container Apps outage in Austria East affecting ca-wise-r-ask-my-books-prod.
The same exact image digest worked successfully on 2026-10-06 and logged:
AssigningReplica -> PullingImage -> PulledImage -> ContainerCreated -> ContainerStarted.
On 2026-10-07, revisions repeatedly reach AssigningReplica but never emit PullingImage, PulledImage, ContainerCreated, or ContainerStarted. Revisions end in ActivationFailed; replicas remain containers=[] / NotRunning; / and /health complete DNS/TCP/TLS but return zero HTTP bytes and time out.
We created a completely new ACA environment in Austria East and deployed the same runtime using a verified single-platform linux/amd64 manifest. The new environment reaches Succeeded but reproduces exactly the same failure.
We also tested minReplicas=1; it still failed after AssigningReplica and before image pull, so scale-from-zero/KEDA is not the cause.
Network checks are clean: both ACA subnets have no NSG, no UDR/route table, no NAT gateway, no custom VNet DNS, and no private endpoints. ACR public access is enabled and managed-identity AcrPull is valid.
Azure Portal diagnostics for Container Create, Image Pull, Container Exit, and Storage Mount fail with:
“Unable to resolve the Kusto cluster for this resource/app’s location.”
Azure Copilot also states that scheduler/node/container-runtime/image-pull handoff telemetry is not accessible through self-service diagnostics.
Can the Azure Container Apps team investigate whether there is a platform, scheduler, node, capacity, or container-runtime issue in Austria East causing replicas to be assigned but never reach image pull?
You have isolated the failure to Austria East: the same digest worked previously, a new environment reproduces it, and revisions stop after AssigningReplica before image-pull or container events. That makes the image and ordinary VNet configuration less likely, but public evidence cannot prove a platform cause.
Preserve the failed environments. Collect each revision’s health state, running-state details, provisioning error, and system logs with UTC timestamps. Check Azure Service Health and Resource Health for Container Apps in Austria East, then run Diagnose and solve problems at the app and environment scopes. Include the Kusto-resolution error, subscription and resource IDs, revision names, digest, and successful October 6 timeline.
Open an Azure support request at the highest production-impact severity available and request scheduler/node placement review. For continuity, deploy the identical revision to another region and shift traffic there. Do not delete the failed resources before support captures telemetry.
4 Replies
Yes, you may consider to preserve failed environments, collect system logs, and open a high-severity Azure support request, as public diagnostics cannot expose scheduler/node/container-runtime failures.
Troubleshoot common deployment failures in Azure Container Apps | Microsoft Learn
Azure Container Apps - avoid downtime caused by Microsoft Maintenance - Microsoft Q&A
Thanks. We have now completed the regional continuity test you suggested.
The identical runtime works correctly in Germany West Central with the same image, runtime configuration, managed identity and registry setup:
PulledImage -> ContainerCreated -> ContainerStarted
The container becomes Running/ready, /health returns HTTP 200, / returns HTTP 200, and the application renders successfully.
In contrast, two separate Azure Container Apps environments in Austria East reproduce the same failure: replicas reach AssigningReplica but never reach PullingImage, ContainerCreated or ContainerStarted.
We are preserving the Austria East environments and failed revisions for evidence, and Azure Diagnose still fails for Container Create / Image Pull diagnostics with:
“Unable to resolve the Kusto cluster for this resource/app’s location.”
We understand that the public evidence does not prove the exact Microsoft platform root cause and that scheduler/node/container-runtime telemetry requires Microsoft-side access.
Our subscription currently has Basic support, so the Azure portal does not allow us to create a technical support case.
Is there an official Microsoft escalation path for a suspected regional Azure Container Apps platform issue when a subscription does not currently have a technical support entitlement?
For example, can this community thread be escalated to the Azure Container Apps product team, or is there a Service Health / platform incident reporting channel intended for this type of reproducible regional failure?
We are not asking for application troubleshooting at this point; the same workload has already been verified healthy in another Azure region.
Thanks — we followed the regional continuity suggestion and now have a much stronger discriminator.
We deployed the same runtime to Germany West Central, preserving the same image, 14/14 runtime values, managed identity and registry configuration. That deployment was healthy:
PulledImage at 19:31:10 CEST
ContainerCreated / ContainerStarted at 19:31:15 CEST
container Running/ready
/health → HTTP 200, 447 B
/ → HTTP 200, ~29.9 KB
and the WISE-R landing page rendered successfully in a browser.At the same time, the Austria East production app still completes DNS/TCP/TLS but /health and / time out with zero HTTP bytes, and replicas remain stuck after AssigningReplica without reaching image pull/container creation.
For the Germany test we also created the required VNet/subnet connectivity, peerings and private DNS linkage. We have not shifted public traffic and have preserved both Austria East environments and failed revisions for evidence. The Germany test revision is currently deactivated.
This appears to strengthen the hypothesis that the failure is associated with the Austria East managed execution path, although we still do not consider the precise platform root cause proven without Microsoft-internal scheduler/node/container-runtime telemetry.
Azure Diagnose continues to fail for the relevant Container Create / Image Pull diagnostics with:
“Unable to resolve the Kusto cluster for this resource/app’s location.”
Our next step is a bounded authentication-parity test in Germany West Central before considering any recovery cutover.
One constraint: this subscription currently has the Basic support plan, so the portal blocks creation of a technical support case unless we upgrade to a paid support plan.
Given the successful identical deployment in Germany West Central and the reproducible pre-image-pull failure in two separate Austria East ACA environments, is there any additional evidence you would recommend collecting before a regional cutover, or any Microsoft escalation path for this type of suspected ACA regional/platform issue that does not require purchasing a support plan?
You have isolated the failure to Austria East: the same digest worked previously, a new environment reproduces it, and revisions stop after AssigningReplica before image-pull or container events. That makes the image and ordinary VNet configuration less likely, but public evidence cannot prove a platform cause.
Preserve the failed environments. Collect each revision’s health state, running-state details, provisioning error, and system logs with UTC timestamps. Check Azure Service Health and Resource Health for Container Apps in Austria East, then run Diagnose and solve problems at the app and environment scopes. Include the Kusto-resolution error, subscription and resource IDs, revision names, digest, and successful October 6 timeline.
Open an Azure support request at the highest production-impact severity available and request scheduler/node placement review. For continuity, deploy the identical revision to another region and shift traffic there. Do not delete the failed resources before support captures telemetry.
