Azure Container Apps - Microsoft.App resource provider failure

Question

Azure Container Apps - Microsoft.App resource provider failure

Arvind Sharma 0

Subject: Azure Container Apps - Microsoft.App resource provider failure caused ~16-hour

production outage (Feb 12-13, 2026)

Severity: Sev B - Production system down

Subscription: Omniware Azure 2448515

Region: East US 2

Affected Resources:

Container App: pm-portal (production), Resource Group: client-apps
Container App: pm-portal-qa (QA), Resource Group: client-apps
Container App Environment: pm-portal-env, Resource Group: client-apps

Issue Description:

On the evening of Thursday, February 12, 2026, both our production and QA Azure Container

Apps became completely unreachable. Per Application Insights telemetry (Log Analytics

workspace pm-portal-logs, workspace ID 626c2c7b-acd9-4084-904e-04ed73d30a44), the last

successful requests were recorded at approximately 22:35 UTC on Thursday, Feb 12 (last

verified activity might not be the time of the outage). Service was restored at approximately

14:30 UTC on Friday, Feb 13 after manual intervention, resulting in a total outage of

approximately 16 hours. No changes were made on our side prior to the outage.

Symptoms:

Both pm-portal (production) and pm-portal-qa (QA) container apps went down simultaneously

with no deployments or configuration changes on our side.

"az containerapp show" returned provisioningState: Failed with null values for all configuration

properties. Ingress, secrets, and environment variables were all empty.

Any ACA write operation (e.g., "az containerapp update") failed with SubscriptionIsNotActive

errors, even though the subscription was active.

The Azure CLI crashed with "NoneType has no len()" when attempting updates, a CLI bug

triggered by the null configuration state I presume.

No Azure Service Health alerts or advisories were posted for this issue during the outage

window.

Impact:

Our production PM Portal application was completely unavailable for ~16 hours overnight into

the following business day, affecting all end users. No workaround was available through the

Azure CLI or Portal. The apps could not be updated, restarted, or redeployed.

Root Cause and Resolution:

After extensive troubleshooting, we discovered that the Microsoft.App resource provider had

entered a broken state on our subscription. The fix was to manually re-register the Microsoft.App

resource provider from the Azure Portal (Subscription > Settings > Resource providers >

search "Microsoft.App" > Re-register). Apps recovered immediately after re-registration

completed.

Questions for Microsoft:

What caused the Microsoft.App resource provider to enter a broken state on an active

subscription with no changes on our end?

Why did the subscription show as Enabled while the resource provider was effectively non-

functional?

Why were no Azure Service Health alerts generated for this issue?
What safeguards exist to prevent this from recurring? Is there a way to monitor or alert on

resource provider state changes? Although it was showing as Registered before Re-

Registration.

Can Microsoft provide a Root Cause Analysis (RCA) for this incident?

Siddhesh Desai 8,210 Reputation points Microsoft External Staff Moderator

2026-02-13T21:27:15.36+00:00

Hi @Arvind Sharma

Thank you for reaching out to Microsoft Q&A.

As per your recent comment, the issue is now resolved after you re-registered the Microsoft

The resource provider was broken due to a known outage at platform level and the services are now restored and the outage is resolved.

Regarding other issues:

I see multiple errors with your container app:

As of today, I don't see these errors and the cluster seems to be healthy are you still facing this issue?

What I'd recommend in this case is to roll back to the working version of the container app.

Or to have a pipeline or automation in place to re-deploy the container app images in case of outage or consistent issues
Siddhesh Desai 8,210 Reputation points Microsoft External Staff Moderator

2026-02-24T19:45:28.7466667+00:00

Hi @Arvind Sharma

I see multiple errors with your container app:
Arvind Sharma 0 Reputation points

2026-02-24T20:14:32.5933333+00:00

Thanks Siddhesh for the update.

So what's the recommendation from your side for us so that this error doesn't happen again in future in our Azure setup.

Thanks!

Arvind
Siddhesh Desai 8,210 Reputation points Microsoft External Staff Moderator

2026-02-24T20:31:21.97+00:00

Hi @Arvind Sharma

As of today, I don't see these errors and the cluster seems to be healthy are you still facing this issue?

What I'd recommend in this case is to roll back to the working version of the container app.

Or to have a pipeline or automation in place to re-deploy the container app images incase of outage or consistent issues
Gilmar Purin 0 Reputation points

2026-02-26T16:27:47.89+00:00

Hi Siddhesh,

When we found out the App was offline on Feb 13th, the ACA settings were all blank. For example, when I went to pm-portal/ingress it was not showing the configured settings, Ingress was checked off.

When we tried to re-configure the settings we got error "Subscripton 'bcb9875f-4d82-4e27-956d-7a1a532051da' is not active and cannot perform this action now". You can check this log in the pm-portal ACA Activity logs.

What we did to fix things was to re-register "Microsoft.App resource provider" and then all started to work again, The ACA containers got their settings back automatically and booted up.

We are asking what happened that made the "Microsoft.App resource provider" broken in that time window?
Arvind Sharma 0 Reputation points

2026-03-11T19:06:58.78+00:00

Hi Siddesh,

Do you have any updates on Gilmar's response. Gilmar is the senior developer in the team who authored all the work which we are discussing here.

Was it something with the Subscription itself ? Was it some reconciliation problem with subscription and Microsoft.App registration?

How do we know that recreating the same setup again won't meet with the same outage ?

Please let us know the root cause of the issue.

Thanks!

Arvind
Praveen Kumar Gudipudi 2,295 Reputation points Microsoft External Staff Moderator

2026-03-12T15:28:04.6233333+00:00
Hello Arvind Sharma,

The behavior you observed is consistent with a temporary inconsistency in the Microsoft.App resource provider registration state, which manages operations for Azure Container Apps within a subscription.

Regarding your questions

Was the issue related to the subscription itself? From the symptoms shared, the subscription itself appears to have remained active and enabled. However, the resource provider responsible for managing Container Apps operations likely entered a transient inconsistent state with the subscription metadata. When this occurs, management operations may fail and return errors such as SubscriptionIsNotActive, even though the subscription is actually enabled.

Was this a reconciliation issue between the subscription and Microsoft.App registration? Yes, the behavior you described (null configuration values, failed provisioning state, and management operations failing) typically indicates that the provider registration metadata needed to be refreshed. Re-registering the Microsoft.App provider forces Azure Resource Manager to reinitialize the provider state for the subscription, which explains why the configuration reappeared and the Container Apps recovered immediately after the re-registration.

How can we ensure this will not happen again if the environment is recreated? This type of issue is not expected during normal operation and is typically rare and transient. Recreating the same environment should not inherently reproduce the issue. As a precaution, it is recommended to:

Maintain IaC-based deployments (ARM/Bicep/Terraform) so the environment can be redeployed quickly if needed.

Implement monitoring through Azure Monitor and Application Insights to detect availability issues early.

Include resource provider validation or re-registration as part of an operational runbook when encountering unexpected management-plane failures.
Praveen Kumar Gudipudi 2,295 Reputation points Microsoft External Staff Moderator

2026-03-17T09:58:09.1133333+00:00

Hello Arvind Sharma,

We haven’t heard from you on the last response and was just checking back to see if you have a resolution yet. In case if you have any resolution, please do share that same with the community as it can be helpful to others. Otherwise, will respond with more details and we will try to help.
Arvind Sharma 0 Reputation points

2026-03-17T17:51:49.67+00:00

Hi Praveen,

We haven't figure out the root cause of the issue still.

Barring re-creating the whole Container resources from scratch and re-deploy our Application, we are not sure what triggered to create the original issue.

Does the Azure side of system logs shed any light on what actually happened at the Infra level which created this problem for us ?

Arvind
Praveen Kumar Gudipudi 2,295 Reputation points Microsoft External Staff Moderator

2026-04-02T14:23:47.5166667+00:00

Hello Arvind Sharma,

including provisioningState: Failed, null configuration values returned by the control plane, and management operations returning SubscriptionIsNotActive — the behavior strongly suggests that the Microsoft.App resource provider registration metadata for the subscription became temporarily inconsistent with the Azure Resource Manager control plane.

When this happens, management-plane operations for services handled by that provider (such as Azure Container Apps) may fail even though the subscription itself remains in an Enabled state.

Re-registering the provider forces Azure Resource Manager to refresh the provider metadata and reinitialize the control plane mappings for the subscription, which explains why the Container Apps configuration immediately reappeared and the workloads recovered.

Regarding Azure-side logs / RCA visibility

Detailed infrastructure logs from the platform side are not exposed directly through the portal. However, you can check the following sources for additional signals:

Subscription Activity Logs

In Azure Portal → Subscription → Activity Log, filter for:

Event source: Microsoft.Resources

Operation name: Register Resource Provider

Resource provider: Microsoft.App

This can help confirm when the provider state changed or was refreshed.

Resource Provider State

Run the following to verify provider registration state:

az provider show --namespace Microsoft.App --query registrationState

Container App Environment Activity Logs

Check activity logs for the Azure Container Apps Environment around the outage window to see if there were control plane reconciliation events.

Service Health History

Although no advisory was posted at the time, you can review historical events under:

Azure Portal → Service Health → Health history

Occasionally platform reconciliation events affecting specific stamps or clusters may appear there.

1 answer

Your answer

Siddhesh Desai 8,210 Reputation points Microsoft External Staff Moderator

2026-02-13T21:27:15.36+00:00

Hi @Arvind Sharma

Thank you for reaching out to Microsoft Q&A.

As per your recent comment, the issue is now resolved after you re-registered the Microsoft

The resource provider was broken due to a known outage at platform level and the services are now restored and the outage is resolved.

Regarding other issues:

I see multiple errors with your container app:

As of today, I don't see these errors and the cluster seems to be healthy are you still facing this issue?

What I'd recommend in this case is to roll back to the working version of the container app.

Or to have a pipeline or automation in place to re-deploy the container app images in case of outage or consistent issues
Siddhesh Desai 8,210 Reputation points Microsoft External Staff Moderator

2026-02-24T19:45:28.7466667+00:00

Hi @Arvind Sharma

I see multiple errors with your container app:
Arvind Sharma 0 Reputation points

2026-02-24T20:14:32.5933333+00:00

Thanks Siddhesh for the update.

So what's the recommendation from your side for us so that this error doesn't happen again in future in our Azure setup.

Thanks!

Arvind
Siddhesh Desai 8,210 Reputation points Microsoft External Staff Moderator

2026-02-24T20:31:21.97+00:00

Hi @Arvind Sharma

As of today, I don't see these errors and the cluster seems to be healthy are you still facing this issue?

What I'd recommend in this case is to roll back to the working version of the container app.

Or to have a pipeline or automation in place to re-deploy the container app images incase of outage or consistent issues
Gilmar Purin 0 Reputation points

2026-02-26T16:27:47.89+00:00

Hi Siddhesh,

When we found out the App was offline on Feb 13th, the ACA settings were all blank. For example, when I went to pm-portal/ingress it was not showing the configured settings, Ingress was checked off.

When we tried to re-configure the settings we got error "Subscripton 'bcb9875f-4d82-4e27-956d-7a1a532051da' is not active and cannot perform this action now". You can check this log in the pm-portal ACA Activity logs.

What we did to fix things was to re-register "Microsoft.App resource provider" and then all started to work again, The ACA containers got their settings back automatically and booted up.

We are asking what happened that made the "Microsoft.App resource provider" broken in that time window?
Arvind Sharma 0 Reputation points

2026-03-11T19:06:58.78+00:00

Hi Siddesh,

Do you have any updates on Gilmar's response. Gilmar is the senior developer in the team who authored all the work which we are discussing here.

Was it something with the Subscription itself ? Was it some reconciliation problem with subscription and Microsoft.App registration?

How do we know that recreating the same setup again won't meet with the same outage ?

Please let us know the root cause of the issue.

Thanks!

Arvind
Praveen Kumar Gudipudi 2,295 Reputation points Microsoft External Staff Moderator

2026-03-17T09:58:09.1133333+00:00

Hello Arvind Sharma,

We haven’t heard from you on the last response and was just checking back to see if you have a resolution yet. In case if you have any resolution, please do share that same with the community as it can be helpful to others. Otherwise, will respond with more details and we will try to help.
Arvind Sharma 0 Reputation points

2026-03-17T17:51:49.67+00:00

Hi Praveen,

We haven't figure out the root cause of the issue still.

Barring re-creating the whole Container resources from scratch and re-deploy our Application, we are not sure what triggered to create the original issue.

Does the Azure side of system logs shed any light on what actually happened at the Infra level which created this problem for us ?

Arvind

Answer 1

It appears that the issue you experienced with the Azure Container Apps and the Microsoft.App resource provider may be related to a failure in the resource provider itself, which can occur without any changes made on your end. Here are some insights based on the context:

Resource Provider State: The Microsoft.App resource provider can enter a broken state, which may lead to the symptoms you described, such as provisioning failures and null configuration properties. This can happen due to internal issues within Azure's management layer.
Subscription Status: Even if the subscription shows as enabled, it does not guarantee that all resource providers are functioning correctly. The status of the subscription may not reflect the operational state of individual resource providers.
Service Health Alerts: The absence of Azure Service Health alerts during the outage indicates that the issue may not have been detected by Azure's monitoring systems. This can happen if the failure is localized or if it does not meet the criteria for generating alerts.
Preventive Measures: To prevent such occurrences in the future, it is advisable to monitor the state of resource providers actively. While Azure does not currently provide direct alerts for resource provider state changes, you can set up monitoring for your applications and use Azure Monitor to track performance and availability.
Root Cause Analysis (RCA): For a detailed RCA, you would need to reach out to Microsoft support directly, as they can provide insights specific to your subscription and the incident.

In summary, the outage you experienced seems to stem from an internal issue with the Microsoft.App resource provider, which can occur independently of user actions. Monitoring and alerting on resource provider states, along with direct support from Microsoft, would be beneficial for future incidents.

References: