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

Michael 0 Reputation points
2026-10-12T12:39:48.04+00:00

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

Time (UTC) Operation Correlation ID
2026-10-11 07:29 PUT (update) fed5238c-56d5-4e12-bb21-d28734f71fc8
2026-10-12 11:52 PUT (update, retry) 602ca771-e8e1-4104-9619-26ff5339f087
2026-10-12 11:57 Revision list 4611d1e2-31d1-4446-8953-d582701fc524
2026-10-12 11:58 GET container app 7a5bde01-a734-4f35-8afb-f979117bbf86
2026-10-12 11:59 GET (2025-01-01) 1daaddf2-7ea2-4ded-9d60-a90ab2ab8f63
2026-10-12 12:27 List apps in resource group 9200f402-bd18-4319-b22f-bf73e209a92f
2026-10-12 12:27 List apps in subscription 7411d205-1b55-4cdc-a016-16da9cb6129b

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.

Azure Container Apps
Azure Container Apps

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

0 comments

1 answer

Sort by: Most helpful
Most helpful Newest Oldest
  1. Jerald Felix 19,080 Reputation points Volunteer Moderator
    2026-10-29T17:38:38.4433333+00:00

    Hello Michael,

    Greetings! Thanks for raising this question in the Q&A forum

    The evidence correctly isolated this as a resource-specific Azure Container Apps control-plane failure. It was not an application, image, ingress, health-probe, Azure Files, Pulumi, or API-version problem.

    The existing revision continued serving traffic and emitting console logs, while multiple ARM GET, list, and update operations failed before revision creation or any corresponding system-log event. This distinction shows that the data plane remained operational while the management-plane state for that Container App was unhealthy.

    1. Confirmed resolution

    As recorded in the linked Azure Container Apps GitHub issue #1852, Azure Support escalated the case and engineering applied a backend mitigation on October 21, 2026.

    After that mitigation, the following operations succeeded again:

    az containerapp show \
  --resource-group <resource-group> \
  --name <container-app>

az containerapp revision list \
  --resource-group <resource-group> \
  --name <container-app>

az containerapp replica list \
  --resource-group <resource-group> \
  --name <container-app>

    Deployments also resumed successfully.

    No customer-side repair was available

    Changing the image, ingress, target port, probe configuration, revision suffix, or deployment client would not have repaired this condition. Raw ARM reads failed across API versions 2023-05-01, 2024-03-01, and 2025-01-01, while the same image worked in another environment.

    Microsoft has not provided the underlying root cause, so it would be incorrect to attribute this conclusively to regional capacity, custom-domain bindings, Azure Files, or a specific configuration field.

    Use support escalation if this pattern returns

    Open an Azure support request against the affected Container App and describe it as a persistent, resource-specific control-plane failure. Include:

    Subscription ID and full Container App resource ID

    Region and managed-environment resource ID

    First and latest failure timestamps in UTC

    The operation and correlation ID for every failed GET, list, and PUT

    API versions tested

    Confirmation that the live revision and FQDN still work

    Confirmation that other apps in the subscription or region remain manageable

    Relevant ContainerAppSystemLogs_CL and ContainerAppConsoleLogs_CL findings

    A link to GitHub issue #1852

    Microsoft documents the support-request process here: Create an Azure support request.

    Avoid destructive recovery attempts

    While the existing revision is serving production traffic, do not delete and recreate the app merely to clear the management error. Also avoid repeated update attempts, because they do not repair backend resource state and make the activity history harder to correlate.

    Continue monitoring the application endpoint and console logs. Microsoft documents the distinction between Container Apps system and console logs in Monitor logs in Azure Container Apps.

    Validate the recovered resource

    After Microsoft confirms mitigation, verify show, revision listing, replica listing, and a controlled deployment. Also confirm that system logs have resumed and test autoscaling, because continued request serving from the existing replica alone does not prove that scaling or future revision provisioning is healthy.

    The absence of a Service Health advisory does not rule out this type of single-resource backend fault.

    If this answer helps you kindly accept the answer which will help others who have similar questions.

    Best Regards,

    Jerald Felix.

    Was this answer helpful?

    0 comments

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.