Azure Container Apps are Unresponsive

Phil Andreoli 1 Reputation point Microsoft Employee
2026-06-05T13:04:44.9966667+00:00

We have four azure container apps in our subscription that are associated to the same environment. They have become unresponsive and when we try to interact with them through the Azure CLI or the Azure Portal we are getting Gateway Timeouts. There have been no deployments in the past 12 days. We were able to mitigate the downtime by deploying to a different region and we would like to delete the old resources and redeploy back to our primary region but the deleting of the resources is also not working.

We have tried to create a ticket for the resources and the process hangs.

Any help would be appreciated.

Azure Container Apps
Azure Container Apps

An Azure service that provides a general-purpose, serverless container platform.

0 comments

2 answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. Rakesh Mishra 10,280 Reputation points Microsoft External Staff Moderator
    2026-06-05T14:23:57.4966667+00:00

    Hello Phil,

    Thank you for posting your question on Microsoft Q&A portal.

    [UPDATE]: I checked with backend team, and they confirmed that issue was temporary due to a rollout they did which may have caused the issue and should be resolved now.

    Please check and let me know if any issues.

    Below are general troubleshooting steps that helps in checking the issue.

    When Azure Container Apps and their associated environments become completely unresponsive to both the Azure Portal and Azure CLI (throwing Gateway Timeouts), it typically indicates that the underlying Container Apps Environment control plane is either in a locked/failed state, or network dependencies are blocking management traffic.

    Since you mentioned there haven't been deployments recently, here are the steps to diagnose and potentially resolve this:

    1. Check Environment Provisioning State: The environment might be stuck in a failed background state. Try checking the state via Azure CLI (if it responds) or the Azure Resource Explorer.

    az containerapp env show -n <environment-name> -g <resource-group> --query properties.provisioningState

    If the state is "Failed", "Canceled", or stuck in "Updating", the environment itself is degraded.

    2. Verify VNet Dependencies (If using a Custom VNet): If your environment is deployed in a custom Virtual Network, Gateway Timeouts on management operations are frequently caused by modified Network Security Group (NSG) rules or Firewall routing blocking necessary outbound management traffic. According to the official documentation on Azure Container Apps networking:

    "If you're using a custom VNet, you must ensure that your network configuration allows for the necessary outbound traffic. If the required traffic is blocked, your container apps might become unresponsive or fail to provision."

    3. Workarounds for Stuck Deletion: Since you are trying to delete the resources and it is hanging, the Azure Resource Manager (ARM) provider is likely waiting for a response from the unhealthy environment. You can attempt to force the deletion by:

    • Using the CLI with the --no-wait flag so your terminal doesn't hang: az containerapp delete -n <app-name> -g <resource-group> --no-wait

    4. Platform Lock: If your apps are not in a custom VNet (or if your network rules are correct) and deletion still hangs indefinitely, the underlying node agents may be unresponsive. In this scenario, the platform lock requires backend mitigation. Please share the requested details in Private message.

    Note: This response is drafted with the help of AI systems.

    Was this answer helpful?

    0 comments

  2. AI answer

    2026-06-05T13:05:12.3866667+00:00

    The symptoms indicate a stuck or unhealthy Azure Container Apps environment in the primary region, which is also blocking deletion. Use the following steps to recover or safely remove it.

    1. Check environment health and policies
    • Azure Container Apps environments can be automatically deleted if they remain idle or in a failed state for more than 90 days, or if they block infrastructure updates due to virtual network or Azure Policy configuration.
    • Verify whether:
      • The environment is in a failed state.
      • There are misconfigured VNets or Azure Policies preventing updates.
    • If the environment is blocking infrastructure updates (for example, due to VNet issues), fix the VNet/Policy configuration first so that operations (including delete) can succeed.
    1. Use troubleshooting tools for the apps
    • For unresponsive apps, use the standard troubleshooting flow:
      • View logs (Log Stream / Azure Monitor) and use “Diagnose and solve problems” for the container apps.
      • Check for issues such as:
        • Image pull failures.
        • Health probe misconfiguration.
        • Ingress or networking misconfiguration.
    • If new revisions are stuck in provisioning or degraded states, verify health probes and ingress configuration as described in the troubleshooting guidance.
    1. Handle stuck deletions (environment and apps)
    • If deleting the apps or the environment shows provisioningState: ScheduledForDelete and never completes, the environment may be blocked by its associated VNet.
    • In that case:
      1. Identify the VNet used by the environment:
        • Run: 
                 az containerapp env show --resource-group <RESOURCE_GROUP> --name <ENVIRONMENT>
        • Note the infrastructureSubnetId and VNet ID.
      2. Manually delete the VNet: 
             az network vnet delete --resource-group <RESOURCE_GROUP> --name <VNET_ID>
      3. Retry deleting the Container Apps environment: 
             az containerapp env delete --resource-group <RESOURCE_GROUP> --name <ENVIRONMENT> --yes
    • After the environment is deleted, delete any remaining container apps or the entire resource group if appropriate.
    1. Redeploy to the primary region
    • Since Container Apps environments are region-bound, create a new managed environment in the primary region before redeploying:
      • Using Azure CLI: 
            az containerapp env create \
      --name <ENVIRONMENT_NAME> \
      --resource-group <TARGET_RESOURCE_GROUP> \
      --location <PRIMARY_REGION> \
      --logs-workspace-id <LOG_ANALYTICS_WORKSPACE_ID> \
      --logs-workspace-key <LOG_ANALYTICS_WORKSPACE_KEY>
      • If using a custom VNet, include --infrastructure-subnet-resource-id and --internal-only true as needed.
    • Ensure the managed identity used by the apps has AcrPull on the container registry to avoid image pull failures during redeployment.
    • Redeploy the container apps (via ARM/Bicep, templates, or CLI) into the new environment.
    1. Consider multi-region resiliency going forward
    • To avoid future regional outages causing total downtime:
      • Deploy Container Apps environments in multiple regions.
      • Use Azure Front Door or Azure Traffic Manager for load balancing and failover.
      • Ensure container images and data are replicated across regions (for example, ACR geo-replication and cross-region data replication).

    References:

    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.