Azure Container Apps - Microsoft.App resource provider failure

Question

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:

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

with no deployments or configuration changes on our side.

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

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

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

errors, even though the subscription was active.

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

triggered by the null configuration state I presume.

5. 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:

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

subscription with no changes on our end?

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

functional?

3. Why were no Azure Service Health alerts generated for this issue?
4. 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.

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

Answer 1

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

Answer 2

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:

1. 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.
2. 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.
3. 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.
4. 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.
5. 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:

• Reliability in Azure Container Apps
• FAQ for Azure Container Apps on Azure Arc