Container Apps Environment Creation: Heavy Usage Error in Central US — Capacity Issue

Question

Container Apps Environment Creation: Heavy Usage Error in Central US — Capacity Issue

Jeff Johnson 25

Problem description

I am unable to create a new Azure Container Apps managed environment in the Central US region. The process fails with the error 'ManagedEnvironmentCapacityHeavyUsageError,' indicating a capacity or regional placement issue.

Environment

Azure Container Apps, resource group in Central US region

What I've already tried

I reviewed the case details, checked the Azure CLI version (2.74.0), the Container Apps extension (1.2.0b4), confirmed that the Microsoft.App resource provider is registered, and verified that the resource group and subnet are properly configured. I also examined the Activity Log for related errors and checked the Azure Service Health advisories, but the issue persists.

Current status

I seek assistance to understand whether this is a regional capacity constraint, a placement-pool limitation, or a subscription-specific admission issue. I would like guidance on possible resolutions or workarounds to successfully create the environment in Central US.

The issue is not resolved. Please continue the support request and escalate it as necessary to the Azure Container Apps/platform capacity team.

We have completed the requested customer-side checks. Microsoft.App is registered, no partial managed environment remains, and the Azure Activity Log shows the accepted Microsoft.App/managedEnvironments/write operation reaching a terminal Failed state with the backend error ManagedEnvironmentCapacityHeavyUsageError / AKSCapacityHeavyUsage.

The provider response explicitly states: “Creating a new cluster is unavailable at this time in region centralus.”

Correlation ID: 78022f03-de0d-4e54-8399-d8b6f2e47cc2

Operation ID: c13e5c01-14d2-4c95-a9e8-9d299ebf4f97

x-ms-request-id: 4920a71b-2439-4a62-8b6a-0c9070e1a5ef

This has been reproduced repeatedly since September 30 across clean provisioning attempts. An existing Container Apps environment in Central US continues to operate normally.

Please investigate the backend placement/capacity condition and advise whether capacity can be made available in Central US, whether this is specific to the internal/VNet-integrated placement pool, or whether there is another supported Central US configuration that avoids the constrained pool.

I do not want to close the case while new managed-environment creation in Central US continues to fail.

Jeff Johnson 25 Reputation points

2026-10-03T20:59:34.6766667+00:00

Hi,

We performed another controlled set of provisioning attempts on October 3, 2026 for the Azure Container Apps managed environment in Central US. This is for support case 2610010040007267. We made four bounded attempts with 10-, 20-, and 30-minute minimum backoffs. All four reached terminal failure with the same previously reported error:

ManagedEnvironmentCapacityHeavyUsageError

Fresh Activity Log details for each attempt also report the underlying provider condition as:

AKSCapacityHeavyUsage

The attempts were against the same Central US internal Consumption managed-environment configuration. No alternate region or shared-environment workaround was used.

ATTEMPT 1

Submitted UTC:

2026-10-03T16:24:39.522Z

Terminal failure observed UTC:

2026-10-03T16:26:01.232Z

Creation correlation/request ID:

105be558-2c3b-469d-8402-59d0e3d1124c

Provider operation ID:

2926f160-248c-43fd-b79d-5d5a702be3c8

Activity Log failure UTC:

2026-10-03T16:26:05.2293372Z

Activity Log operation ID:

f82ebf3c-c3e2-4b32-9465-f79ab92b9141

Upstream AKS request ID:

50e99dda-3310-4161-88f3-f2f536660c5b

Result:

ManagedEnvironmentCapacityHeavyUsageError / AKSCapacityHeavyUsage

ATTEMPT 2

Submitted UTC:

2026-10-03T16:41:34.022Z

Terminal failure observed UTC:

2026-10-03T16:42:37.088Z

Creation correlation/request ID:

48425d9b-da80-4563-9208-66fd66156ea7

Provider operation ID:

f5252db6-fa6f-45b9-b351-0fb070b2be95

Activity Log failure UTC:

2026-10-03T16:42:40.5870344Z

Activity Log operation ID:

6bcc2f7e-3cc0-4456-8983-6f5f4059aed5

Upstream AKS request ID:

cb8cc77e-ab0f-454c-b1d0-9fbcbaea9d6c

Result:

ManagedEnvironmentCapacityHeavyUsageError / AKSCapacityHeavyUsage

ATTEMPT 3

Submitted UTC:

2026-10-03T17:02:40.080Z

Terminal failure observed UTC:

2026-10-03T17:03:13.064Z

Creation correlation/request ID:

97750eeb-b05a-4823-8951-56271f6f888b

Provider operation ID:

05196e96-32c2-4a64-b449-b85bd423ec01

Activity Log failure UTC:

2026-10-03T17:03:16.0398345Z

Activity Log operation ID:

12c127ed-2511-4c70-9191-b5fdddbf89cb

Upstream AKS request ID:

eb190632-b770-4dac-8186-66d3d6c7183e

Result:

ManagedEnvironmentCapacityHeavyUsageError / AKSCapacityHeavyUsage

ATTEMPT 4

Submitted UTC:

2026-10-03T17:33:21.906Z

Terminal failure observed UTC:

2026-10-03T17:35:41.159Z

Creation correlation/request ID:

ec8c3970-4368-426d-a970-d0a97b182072

Provider operation ID:

0901203a-0241-4383-8d24-d1f2cb345f11

Activity Log failure UTC:

2026-10-03T17:35:45.3484043Z

Activity Log operation ID:

f76a6718-ffed-4242-9b53-be51540e9d97

Upstream AKS request ID:

09c10160-d103-47e5-a3ab-967c3d2e4936

Result:

ManagedEnvironmentCapacityHeavyUsageError / AKSCapacityHeavyUsage

For all four attempts, the creation response request ID was the same as its correlation ID. This provisioning uses a direct resource PUT, so there is no ARM template deployment name. Before each retry, we verified that the failed managed environment and its provider-created resource group were absent. There were no simultaneous managed-environment provisioning operations. After the final attempt, we performed a full cleanup and cross-run verification. At 2026-10-03T17:55:11.999Z, all disposable proof resources were verified absent, with no orphaned proof resources or RBAC assignments remaining. Our existing TEST and production environments remain healthy. Production configuration, traffic, databases, content, Devices, and our currently running diagnostics were unchanged by these attempts.

At this point, the remaining deployment work is still blocked specifically by the inability to provision the required new Central US Azure Container Apps managed environment. We have paused further retries rather than continuing to submit requests while the regional capacity condition persists.

Please attach these new timestamps and IDs to the Azure Container Apps product-team escalation. We would appreciate an update on Central US capacity availability and guidance on when the product team recommends that we retry provisioning.

Thanks,

Jeff
Jeff Johnson 25 Reputation points

2026-10-05T13:52:01.1433333+00:00

I performed an additional independent test this morning using Microsoft's new Azure Container Apps portal. I selected the Express option in Central US and attempted to deploy the Microsoft-provided "Hello world container" (mcr.microsoft.com/k8se/quickstart:express) using the default 0.5 CPU / 1 GiB configuration.

Portal validation succeeded, but provisioning failed with:

"Provisioning failed: There is not enough space on the disk."

I've attached a screenshot showing the complete configuration and failure.

This test does not use our application image, IaC, existing Container Apps environment, or application configuration. It appears to provide an independent reproduction of the Central US provisioning/capacity issue using Microsoft's own sample workload and provisioning UI.

Can you please add this reproduction to the case and confirm whether the "not enough space on the disk" failure is another symptom of the Central US capacity issue already identified on this support request?

Answer accepted by question author

0 additional answers

Your answer

Jeff Johnson 25 Reputation points

2026-10-05T13:52:01.1433333+00:00

I performed an additional independent test this morning using Microsoft's new Azure Container Apps portal. I selected the Express option in Central US and attempted to deploy the Microsoft-provided "Hello world container" (mcr.microsoft.com/k8se/quickstart:express) using the default 0.5 CPU / 1 GiB configuration.

Portal validation succeeded, but provisioning failed with:

"Provisioning failed: There is not enough space on the disk."

I've attached a screenshot showing the complete configuration and failure.

This test does not use our application image, IaC, existing Container Apps environment, or application configuration. It appears to provide an independent reproduction of the Central US provisioning/capacity issue using Microsoft's own sample workload and provisioning UI.

Can you please add this reproduction to the case and confirm whether the "not enough space on the disk" failure is another symptom of the Central US capacity issue already identified on this support request?

Answer 1

Hi @Jeff Johnson ,

We have received below response from Product team. Could you please check and let me know if you have any further questions.

The Microsoft Azure Team has investigated the issue you reported where creating a new internal, VNet-integrated Azure Container Apps environment (Consumption workload profile) in Central US repeatedly failed with ManagedEnvironmentCapacityHeavyUsageError starting September 30, 2026.

This issue was related to a regional capacity constraint on the underlying managed Kubernetes infrastructure in Central US. Every new Container Apps environment needs new backing compute infrastructure to be provisioned. During this period, creation of that infrastructure in Central US was temporarily unavailable, so each of your environment creation requests was rejected at that step. Our investigation confirmed:

The constraint applied to the Central US region as a whole. It was not specific to your subscription and was not caused by your environment configuration, networking, RBAC, or policy settings.
Your existing Container Apps environments in Central US were not affected and continue to run normally. Only creation of new environments was impacted.
Capacity cannot be allocated for an individual subscription to bypass this constraint.
No supported configuration change avoids the constraint. Internal vs. external ingress, workload profile type, and zone redundancy all still need new infrastructure in the region.
At the time of this update, capacity in Central US has not yet been fully restored, and no specific ETA is available. Capacity is being expanded by the platform team.

Recommended next steps: Keep using your existing Central US environments. You can also deploy additional apps and jobs into an existing environment, as you already did successfully. Retry new environment creation in Central US periodically, deleting any failed environment before each retry. If the new environment is needed urgently, create it in another region.

No action was required on your side to cause or correct this issue.

Alternate Regions: australiaeast, australiasoutheast, austriaeast, belgiumcentral, brazilsouth, canadacentral, canadaeast, centralindia, centraluseuap, chilecentral, eastasia, eastus2, eastus2euap, francecentral, francesouth, germanynorth, indonesiacentral, italynorth, japaneast, japanwest, jioindiacentral, jioindiawest, koreacentral, koreasouth, malaysiawest, mexicocentral, newzealandnorth, northeurope, norwayeast, polandcentral, southafricanorth, southcentralus, southeastasia, southindia, spaincentral, switzerlandnorth, switzerlandwest, uaecentral, uaenorth, uksouth, ukwest, westcentralus, westeurope, westus, westus2, westus3.

We apologize for any inconvenience.