Azure Support Case — Container Apps Environment stuck in "Failed" provisioning state

Hi @Iryna Pytlovana ,

Based on the symptoms, the issue appears to be at the Azure Container Apps Managed Environment level, not with the individual Container Apps.

The existing applications are still running, but the environment is stuck in provisioningState = Failed, which is preventing new deployments and environment updates.

The most likely cause is a failed environment reconciliation or stale subnet/backend metadata, possibly related to the earlier subnet delegation change. An orphaned Service Association Link (SAL) is also a possibility.

Recommended next steps

1. Check the subnet for any unexpected Service Association Links (SALs).
2. Review the Activity Log for Microsoft.App/managedEnvironments failures and correlation IDs.
3. Run Diagnose and Solve Problems on the Container Apps Managed Environment.
4. If no customer-side configuration issue is found, this will likely require Azure Container Apps engineering intervention to check and clean up backend state.

Please do not delete or recreate the existing environment yet, especially since it is still serving production traffic.

If business continuity requires an immediate solution, a new Managed Environment with a fresh subnet can be considered as a workaround.

Hi @Likhitha Sulake ,

Thank you for the detailed analysis — completed all four recommended steps. Sharing findings below, which support the "requires Azure engineering intervention" conclusion.

1. Service Association Links check

az network vnet subnet show \
  --resource-group rg-sayhub-dev \
  --vnet-name vnet-sayhub-dev \
  --name snet-aca \
  --query "serviceAssociationLinks" \
  -o json

Result: empty (no visible SALs returned). This is consistent with the "orphaned SAL" theory — if the stale link exists, it's not exposed through this client-facing query.

2. Activity Log review

az monitor activity-log list \
  --resource-group rg-sayhub-dev \
  --start-time <30 days ago> \
  --query "[?contains(resourceId, 'managedEnvironments') || contains(resourceId, 'snet-aca')]..." \
  -o json

Result: empty array [], even over a 30-day window. No activity log entries exist for the Managed Environment or the subnet resource at all — so no correlation ID is available from this surface.

3. Diagnose and Solve Problems (Container App Environment Health tool)

Confirms the split clearly:

• Environment Provisioning state: Failed for the entire last 24-hour window (no transitions, consistently red/Failed)
• Container Apps and Jobs inside the environment: all six resources (app-chat-sayhub-dev, app-fastapi-sayhub-dev, app-private-sayhub-dev, app-web-sayhub-dev, job-db-console-dev, job-migrate-dev) individually show Provisioning State: Succeeded

So the environment-level state is stuck at Failed while every workload running inside it is healthy — this matches your assessment that the issue is isolated to the Managed Environment resource itself, not the applications.

Confirming for the record: we have not attempted to delete or recreate this environment, and won't until you advise otherwise. It continues to serve traffic normally — only new deployments/environment-level updates are blocked.

Let us know if you need any additional diagnostics from our side, or if this is ready to hand off to the Container Apps engineering team.

Thanks, Iryna

Hi @Likhitha Sulake ,

Following up on the diagnostics I posted [X hours/days ago] — SAL check (empty), Activity Log (empty over 30 days), and the Diagnose and Solve Problems output showing the environment stuck at "Failed" while all container apps/jobs inside it report "Succeeded".

I've been trying to open a formal support case through the Azure Portal (Help + Support → Create a support request) so this can get proper SLA tracking, but the portal's guided troubleshooting flow keeps redirecting me back to documentation/self-help resources instead of letting me submit a request — even after selecting "Deploying Container App Environment with VNET fails" as the specific issue type.

Given the impact — our development team is fully blocked from deploying any code changes to this environment, and it continues to accrue cost while stuck — could you please escalate this thread directly to a formal support case on your end? You mentioned this would likely need Container Apps engineering intervention to clean up backend state, so I want to make sure this doesn't stall in the community queue.

Happy to provide any additional resource IDs, screenshots, or diagnostics needed to speed up the escalation.

Thanks, Iryna

Hi @Iryna Pytlovana ,

Thank you for running all four checks and sharing the results.

One important point from your latest update is that the subnet delegation has been re-added. Since this is a Consumption-only Container Apps environment, the subnet should not have any delegation. Please remove it again before we continue the investigation.

Please follow these steps:

Confirm the environment type

az containerapp env show 

If the result is empty or null, it is a Consumption-only environment.

Remove the subnet delegation

az network vnet subnet update 

Also ensure Terraform is not adding the delegation back.

Verify the delegation is removed

az network vnet subnet show 

The expected result is [].

1. After this, please do not delete or recreate the environment. If the environment remains in Failed state even after the subnet is compliant, this would indicate that further backend investigation is required.

Please share the results of the above checks, especially the environment type, subnet delegation status, and current provisioning state.

Hi @Likhitha Sulake ,

Completed all four steps as requested. Results below:

1. Environment type confirmation

az containerapp env show --name environment-sayhub-dev --resource-group rg-sayhub-dev \
  --query "properties.workloadProfiles" -o json

Result: null — confirmed Consumption-only environment.

2. Subnet delegation removed

az network vnet subnet update --resource-group rg-sayhub-dev --vnet-name vnet-sayhub-dev \
  --name snet-aca --remove delegations

Completed successfully.

3. Delegation verification

az network vnet subnet show --resource-group rg-sayhub-dev --vnet-name vnet-sayhub-dev \
  --name snet-aca --query "delegations" -o json

Result: [] — confirmed empty, no delegation present.

4. Terraform check

Confirmed our Terraform configuration no longer defines any delegation block for this subnet (we removed it from the code as well, not just live), so terraform plan reports no drift — it will not re-add the delegation on any future apply.

Current provisioning state

az containerapp env show --name environment-sayhub-dev --resource-group rg-sayhub-dev \
  --query "properties.provisioningState" -o tsv

Result: Failed — unchanged, even with the subnet now fully compliant (no delegation, Consumption-only environment type confirmed).

As you noted, this confirms the environment remains in Failed state despite the subnet configuration now being fully correct — pointing to backend state that requires further investigation on your end.

We have not deleted or recreated the environment, and won't unless you advise otherwise.

Let me know what additional information would help move this forward.

Thanks, Iryna