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

Question

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

Iryna Pytlovana 0

Summary

Our Azure Container Apps Managed Environment is stuck in provisioningState: "Failed", blocking all new deployments (container image updates) to every Container App running in it. The application itself continues serving traffic normally — this only blocks control-plane operations (deployments), not the data plane.

Resource details

Resource: Container Apps Managed Environment
Environment type: Consumption-only (no workload profiles)
Created: 2026-01-15

What happened

The environment's infrastructure subnet (snet-aca) had a delegation to Microsoft.App/environments configured since the environment's original creation in January 2026 (via Terraform).
Today, running az containerapp env update (a routine reconcile operation) surfaced an error that had apparently never been triggered before:

   (ManagedEnvironmentV1SubnetDelegationNotAllowed) The subnet for consumption-only 
   environment must not have delegations. Please remove the delegation 
   'Microsoft.App/environments' from the subnet and retry the environment creation.

We removed the delegation from the subnet (az network vnet subnet update --remove delegations). The az containerapp env update reconcile then completed without that specific error — but provisioningState remained "Failed" across three subsequent reconcile attempts, with no further error detail exposed in the resource body or via CLI.
We subsequently re-added the delegation, but this did not change the Failed state either way — it was already stuck before and after.

Current state

provisioningState: "Failed" (confirmed via az containerapp env show)
Subnet currently has the delegation re-added (back to original January 2026 configuration)
No delegation-related error is currently returned by reconcile attempts
No NAT Gateway is currently attached to this VNet/subnet (confirmed via az network nat gateway list — empty)
Data plane confirmed healthy throughout: frontend and backend_api both serving HTTP 200 on health checks
All az containerapp update (image deployment) calls fail with:

  (ManagedEnvironmentNotProvisioned) The environment '.../managedEnvironments/environment-sayhub-dev' 
  has not been provisioned successfully.

What we suspect

Based on documented patterns for this error class (Azure/AKS GitHub issues referencing "orphaned service association link"), we suspect the subnet delegation removal did not fully clear an internal service association link tracked separately from the visible delegation object, leaving the environment's provisioning state unable to reconcile to Succeeded even after the configuration was corrected.

What we're asking for

Please investigate and clear whatever internal state is preventing environment-*****-dev from reconciling to provisioningState: "Succeeded". We are not able to diagnose or fix this further from the client side — CLI/ARM calls return no additional error detail beyond "Failed".

Impact

Severity: Moderate (not production-down) — this is our dev environment, application traffic is unaffected, but all new code deployments to dev are currently blocked, halting the development team's ability to ship and test changes.

Likhitha Sulake 100 Reputation points Microsoft External Staff Moderator

2026-08-16T15:40:51.32+00:00
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

Check the subnet for any unexpected Service Association Links (SALs).

Review the Activity Log for Microsoft.App/managedEnvironments failures and correlation IDs.

Run Diagnose and Solve Problems on the Container Apps Managed Environment.

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.
Iryna Pytlovana 0 Reputation points

2026-08-16T16:41:05.4533333+00:00
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
Iryna Pytlovana 0 Reputation points

2026-08-17T08:29:42.9133333+00:00

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
Likhitha Sulake 100 Reputation points Microsoft External Staff Moderator

2026-08-18T09:42:58.4833333+00:00
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 [].

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.
Iryna Pytlovana 0 Reputation points

2026-08-18T14:39:34.96+00:00
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
Iryna Pytlovana 0 Reputation points

2026-08-21T10:45:30.8166667+00:00

Hi @Likhitha Sulake ,

Just checking in — it's been a few days since I posted the confirmation you requested (environment type, delegation removal, verification, and Terraform check — all clean, with provisioningState still Failed).

Wanted to make sure the update didn't get missed. Is there any progress on the backend investigation, or anything else you need from our side to keep this moving?

This is still actively blocking our development team from deploying, so any update — even just an estimated timeline — would be really helpful.

Thanks for your continued help with this.

Iryna
Iryna Pytlovana 0 Reputation points

2026-08-21T10:47:26.0933333+00:00

Deleted comment
Rajesh Venkatraman 0 Reputation points

2026-09-07T09:43:30.38+00:00

We are facing the same issue. No change in subnet delegation but the container app environment status changed to failed on Aug 20th. All Container apps working but unable to deploy any containers.
Likhitha Sulake 100 Reputation points Microsoft External Staff Moderator

2026-09-08T18:48:46.28+00:00

Hi @Rajesh Venkatraman , If the assistance was helpful, kindly take a moment to click on Accept Answer and click on Yes. It will be helpful for other community members.

2 answers

Your answer

Likhitha Sulake 100 Reputation points Microsoft External Staff Moderator

2026-08-16T15:40:51.32+00:00

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

Check the subnet for any unexpected Service Association Links (SALs).

Review the Activity Log for Microsoft.App/managedEnvironments failures and correlation IDs.

Run Diagnose and Solve Problems on the Container Apps Managed Environment.

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.
Iryna Pytlovana 0 Reputation points

2026-08-17T08:29:42.9133333+00:00

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
Likhitha Sulake 100 Reputation points Microsoft External Staff Moderator

2026-08-18T09:42:58.4833333+00:00

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 [].

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.
Iryna Pytlovana 0 Reputation points

2026-08-18T14:39:34.96+00:00

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
Iryna Pytlovana 0 Reputation points

2026-08-21T10:45:30.8166667+00:00

Hi @Likhitha Sulake ,

Just checking in — it's been a few days since I posted the confirmation you requested (environment type, delegation removal, verification, and Terraform check — all clean, with provisioningState still Failed).

Wanted to make sure the update didn't get missed. Is there any progress on the backend investigation, or anything else you need from our side to keep this moving?

This is still actively blocking our development team from deploying, so any update — even just an estimated timeline — would be really helpful.

Thanks for your continued help with this.

Iryna
Iryna Pytlovana 0 Reputation points

2026-08-21T10:47:26.0933333+00:00

Deleted comment
Rajesh Venkatraman 0 Reputation points

2026-09-07T09:43:30.38+00:00

We are facing the same issue. No change in subnet delegation but the container app environment status changed to failed on Aug 20th. All Container apps working but unable to deploy any containers.
Likhitha Sulake 100 Reputation points Microsoft External Staff Moderator

2026-09-08T18:48:46.28+00:00

Hi @Rajesh Venkatraman , If the assistance was helpful, kindly take a moment to click on Accept Answer and click on Yes. It will be helpful for other community members.

Answer 1

Rajesh Venkatraman 0

Support team suggested to disable logging options to trigger the reconciliation process. This helped and the status changed to Succeeded. Then enabled the logging options again.

Likhitha Sulake 100 Reputation points Microsoft External Staff Moderator

2026-09-09T16:11:09.32+00:00

Hi @Rajesh Venkatraman ,
Could you confirm whether you still need support from our team and whether the issue has been resolved?

If the assistance was helpful, kindly take a moment to click on Accept Answer and click on Yes. It will be helpful for other community members.
Likhitha Sulake 100 Reputation points Microsoft External Staff Moderator

2026-09-10T16:58:38.8966667+00:00

Hi @Rajesh Venkatraman , Could you confirm whether you still need support from our team and whether the issue has been resolved?

If the assistance was helpful, kindly take a moment to click on Accept Answer and click on Yes. It will be helpful for other community members.

Answer 2

Hi @Rajesh Venkatraman ,

Thank you for the details.

Since your existing Container Apps are still running, but the Container Apps Managed Environment is in a Failed state and new deployments are blocked, the issue appears to be at the environment/control-plane level, rather than with the individual applications.

As you mentioned that there were no subnet delegation changes, we should not assume the same root cause as similar cases.

Could you please check the following:

Run az containerapp env show for the affected environment.

Check the Activity Log for failed Microsoft.App/managedEnvironments operations and note any error details or correlation IDs.

Run Diagnose and solve problems from the Container Apps environment in the Azure portal.

If the environment uses VNet integration, please also verify the current subnet and delegation settings.

If the environment remains in the Failed state, please share the environment output, Azure region, deployment error, and Activity Log error/correlation ID. This will help us determine the next steps and whether platform-level investigation is required.

Thank you.