Container Apps: Deployment Stuck in Progress — Control Plane Hang

Trevor Germain 20 Reputation points
2026-10-01T22:32:23.3266667+00:00

Problem description

I am experiencing an issue where my Azure Container Apps environment is not returning from deployments. The control plane seems to be hung, and recent deployment operations are stuck in the 'InProgress' provisioning state without completing.

Environment

Azure Container Apps, Revisions (view, activate, deactivate, use), Microsoft.App/managedEnvironments

What I've already tried

I reviewed the available case details and diagnostic information; however, I have not performed any troubleshooting steps myself beyond reviewing the case data.

Current status

I am seeking assistance from a Container Apps engineer to resolve the stuck deployment operations, understand the root cause of the control plane hang, and confirm whether the production environment is at risk.

Azure Container Apps
Azure Container Apps

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

0 comments No comments

Answer accepted by question author
Rakesh Mishra 11,510 Reputation points Microsoft External Staff Moderator
2026-10-02T00:57:02.5833333+00:00

Hi @Trevor Germain ,

The Microsoft Azure Team has investigated the issue you reported related to container app updates in the Container Apps environment (Canada Central). Between 18:08 UTC and 22:09 UTC on 1 October 2026, update operations on 20 container apps stayed in the InProgress provisioning state. New revisions were created and running, but the operations did not complete, and further updates to those apps were rejected with 409 ContainerAppOperationInProgress.

This issue was caused by a transient authorization error (HTTP 403) returned by Azure Resource Manager (ARM). It occurred at 18:10 UTC, when the Container Apps platform made a routine networking configuration request for the environment, against a resource that Azure manages for you. This was not related to permissions in your subscription. Because of the error, one environment-level operation stayed pending, and all container app updates in the environment queued behind it. Our investigation also found a platform defect: updates that did not change the app's ingress ports still waited on this operation when they should not have. The issue was not caused by your applications, container images or configuration.

At 22:09 UTC the pending operation was released. Nineteen of the 20 update operations then completed successfully. The update to stg-np-preprocessor completed with a Failed status; it was redeployed successfully on 2 October 2026 at 19:43 UTC. All 20 container apps are now in the Succeeded state, and later updates in the environment have completed normally. No action is required from you.

This transient ARM error has not recurred since 1 October in Canada Central or any other region. Thousands of identical requests have since completed normally, including on this environment. We therefore do not expect it to affect your production environment. The platform improvements below will also prevent a transient error of this kind from blocking container app updates in the future.

We are continuously taking steps to improve the service and our processes to ensure such incidents do not occur in the future, and in this case it includes (but is not limited to):

Ensuring container app updates that do not change ingress ports no longer wait on environment-level networking operations.

Improving how this operation recovers automatically from transient errors, so it can no longer stay pending for an extended period.

We apologize for any inconvenience. Please let us know if issue still persists or any further questions.

Was this answer helpful?

1 person found this answer helpful.
0 comments No comments

0 additional answers

Sort by: Most 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.