Azure Container App returns 500 InternalServerError on all management operations (GET, list, update) in North Europe – app still running

One of our container apps in North Europe has returned 500 InternalServerError for every management operation since at least 11 October 2026, including plain reads. The existing revision is still running and serving traffic, but we can't read, update or deploy to the app, and the portal can't display it.

Also raised on GitHub: https://github.com/microsoft/azure-container-apps/issues/1852

What fails

All of these return the same error:

• PUT on the container app (new revision via Pulumi azure-native; fails after ~270s each time)
• az containerapp show
• az containerapp revision list
• az containerapp replica list
• Raw ARM GET on the container app with api-version 2023-05-01, 2024-03-01 and 2025-01-01
• Listing container apps in the resource group, and in the whole subscription. The one broken app fails the entire list, so the portal's Container Apps blade won't load and the environment's Apps blade shows "No results".

(InternalServerError) Internal server error occurred. correlation ID: <id>

Correlation IDs

What still works

• The managed environment reads fine (provisioningState: Succeeded), as do its certificates and storage.
• A second container app in a different environment, same region and subscription, deploys and reads normally. The same image deployed there successfully.
• The generic ARM resource list for the resource group still shows the broken app as Succeeded.
• The app is still serving requests on its custom domains and its default FQDN.

Other observations

• ContainerAppSystemLogs_CL has had no entries for this app since 2026-10-08 03:32 UTC. Before that it logged scale and replica events most days. Neither failed update produced any system log event (no revision creation, no image pull), so the updates don't appear to have reached the cluster.
• The resource's last recorded change in ARM is 2026-09-25, the last successful deploy.
• ContainerAppConsoleLogs_CL is still flowing from the existing revision's single replica.
• We can't tell whether autoscaling still works.
• No Azure Service Health event is shown for the subscription.
• The attempted update only changes the template (new image tag and revision suffix).

Configuration

• Region: North Europe
• Environment: Consumption, no workload profiles
• Revision mode: Single
• Ingress: external, target port 8080, two custom domains with SNI bindings
• Scale: min 1, max 3, HTTP scale rule
• One Azure Files volume mount

Question

Can someone on the Container Apps team look at the correlation IDs and repair the app's control-plane state? We want to avoid deleting and recreating it: it is serving production traffic, and a delete would probably fail the same way. Is there anything we can do from our side in the meantime?

I can share the subscription ID and resource ID privately.