Azure Container Apps: ManagedClusterSuspended while environment reports Succeeded — safe recovery without recreation?

mws965 0 Reputation points
2026-10-31T16:04:02.2033333+00:00

Our Azure Container Apps environment zam-production-cae in UAE North reports provisioningState=Succeeded, but deployment of a temporary ingress-disabled administration app failed on 2026-10-31 with ManagedClusterSuspended. The service message describes the underlying compute as suspended for unknown reasons. The environment was created on 2026-10-24 and uses the Consumption workload profile.

We completed a read-only investigation:

  • Power state: the environment API does not expose a powerState field. The Consumption workload-profile status provides no suspension reason. There is no customer-managed AKS resource in the relevant resource groups.
  • Networking: the environment subnet has the expected Microsoft.App/environments delegation and a Succeeded service-association link. No attached NSG or user-defined route table was found. The VNet uses Azure DNS, and the existing private DNS links report Succeeded/Completed. We have not independently verified end-to-end outbound connectivity from the platform, because no approved running probe workload is available.
  • Policy: we found no applicable policy denial correlated with this failure. We are not claiming visibility into all internal platform policy events.
  • Quota and capacity: Consumption quota usage is 0 of 100; regional environment quota is 3 of 15. These are quota observations, not proof of available physical regional capacity.
  • Health and logs: no matching Container Apps incident or suspension cause was found in the successfully retrieved Activity Log window. Resource Health returned UnsupportedResourceType, and the separate current Service Health interface did not provide complete evidence.
  • Environment diagnostics: detector listing with API version 2026-07-01 and the documented ManagedEnvAvailabilityMetrics detector with 2025-07-01 both return InternalServerError. We could not obtain a usable environment-health/down diagnosis.
  • Lifecycle: the environment was less than seven days old at the failure. The documented 90-day inactivity deletion policy does not establish the cause of this suspension.

We have Basic support and would appreciate guidance from Microsoft or the Azure Container Apps team:

  1. Does Microsoft recognize ManagedClusterSuspended with these symptoms as an internal managed-cluster condition? What additional sanitized evidence would distinguish it from a customer-correctable issue?
  2. Is there a documented, supported, non-destructive customer recovery operation for the existing environment? Please identify the exact operation, prerequisites, risks and rollback procedure. We do not want to recreate or migrate the environment.
  3. If platform intervention is needed, how can we escalate this to Azure Container Apps engineering through an available free channel or arrange verified private triage?

We have not attempted a speculative restart, generic update, redeployment, migration or recreation to recover the environment. No automatic recovery or resource changes are authorized. Resource identifiers, correlation IDs and sanitized detailed diagnostics can be provided through a verified private Microsoft channel. We will not publish subscription IDs, IP addresses, credentials, Terraform state or application data.

Azure Container Apps
Azure Container Apps

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

0 comments No comments

1 answer

Sort by: Newest
  1. AI answer

    2026-10-31T16:05:29.14+00:00

    There is no documented customer-accessible restart, resume, or repair operation for an Azure Container Apps managed environment in ManagedClusterSuspended; preserve the environment unchanged and escalate the condition through an Azure support request or, if offered for the subscription, Priority Community Support.

    What the current evidence establishes

    • provisioningState=Succeeded confirms that the ARM resource provisioning operation completed; it does not establish that the environment’s managed compute is currently healthy.
    • The Container Apps runtime—not a customer-visible AKS cluster—manages environment OS upgrades, scaling, failover, and resource balancing.^1^
    • The published 2026-07-01 management surface lists managed-environment CRUD, diagnostics, usages, storage, networking, and related operations, but no managed-environment start, restart, resume, or repair operation.^2^
    • Public documentation does not identify ManagedClusterSuspended as a specific known incident, nor does it document a customer-correctable cause for the exact state described. It therefore cannot yet be classified conclusively as an internal defect, regional capacity issue, or customer networking issue without service-side telemetry.
    • The App Service Environment suspension remedy and Arc/Kubernetes pod operations are inapplicable: this is a managed Azure Container Apps environment, not ASE or Arc-enabled Kubernetes.

    Consequently, there are no supported prerequisites, risks, or rollback instructions for a non-destructive “resume” operation—the operation itself is not publicly documented. Do not issue a no-op environment update, modify workload profiles, or repeatedly redeploy merely to provoke reconciliation; none is documented as recovery for this condition.

    Escalate without changing the environment

    1. In the Azure portal, open zam-production-cae → Help → Support + Troubleshooting.
    2. Complete the automated path. If it does not resolve the issue, select Create a support request.
    3. Choose:
      • Issue type: Technical
      • Service: Azure Container Apps
      • The closest environment provisioning/deployment or managed-environment problem type
      • The affected subscription and environment
    4. Select the available support plan and a severity matching the business impact.
    5. If acceptable under your data-handling policy, enable Advanced diagnostic information so support can inspect service-side telemetry unavailable through ARM.

    Creating a technical request requires subscription-level Owner, Contributor, Support Request Contributor, or a custom role containing Microsoft.Support/*. Microsoft recommends supplying start time, reproduction details, logs, and diagnostic files; the selected support plan determines available severity and response time.^3^

    Use a case summary similar to:

    Azure Container Apps managed environment in UAE North returns provisioningState=Succeeded, but a new ingress-disabled app deployment failed at <UTC timestamp> with ManagedClusterSuspended. No environment recreation, migration, update, restart, or redeployment is authorized. Please inspect managed-cluster lifecycle, environment-controller, capacity/allocation, networking control-plane, and platform-policy telemetry; identify whether Microsoft can safely resume or repair the existing environment without changing its resource identity or configuration.

    Attach or provide privately:

    • Environment resource ID, subscription, region, environment type, and workload profile.
    • Exact UTC timestamps, full unmodified error text, deployment operation ID, correlation/request IDs, and failed app operation ID.
    • ARM deployment-operation output and relevant Activity Log export.
    • API versions and timestamps for both diagnostic calls that returned InternalServerError, including request/correlation IDs.
    • Sanitized environment JSON and workload-profile status.
    • Subnet delegation and service-association-link state.
    • A concise statement that quota was available but physical capacity was not independently established.
    • Confirmation that no customer AKS resource exists and no changes are authorized without approval.

    For capacity-related investigations, Microsoft specifically requests the environment/resource ID, region, full error, failed timestamps, and correlation or operation IDs. A support request enables investigation but does not guarantee immediate capacity allocation.^4^

    Free/private escalation path

    If the support workflow offers Priority Community Support (PCS), use it. Eligibility depends on the support entitlement exposed for the subscription; it should not be assumed solely from the plan name. PCS creates a tracked support ticket linked to Microsoft Q&A, and a Microsoft engineer can continue privately through Q&A private messaging or the ticket’s email conversation when sensitive evidence is required.^5^

    1. Start the request through Support + Troubleshooting.
    2. Complete the automated troubleshooting.
    3. Select Priority Community Support if the portal presents it.
    4. Review the generated public post and remove identifiers.
    5. Provide resource IDs, correlation IDs, and detailed diagnostics only through the associated private message or ticket email.

    If PCS is not offered and the Basic entitlement does not expose technical case creation, ask the subscription owner or the owner of any organizational Microsoft support agreement to verify and link the available support benefit. A public Q&A thread can attract product-team review, but it is not itself a guaranteed private engineering escalation channel.

    Diagnostics already attempted

    The documented environment-level path is Container Apps environment → Diagnose and solve problems → Container App Environment Down / Container App Environment Health / Container Create Failures.^6^ Since the equivalent environment detector requests already returned InternalServerError, record those failures as evidence rather than repeatedly invoking them. A detector failure alongside ManagedClusterSuspended is itself useful for Microsoft’s service-side triage.


    References

    1. Azure Container Apps environments
    2. Resource Manager
    3. Create an Azure support request
    4. Troubleshoot environment capacity errors in Azure Container Apps
    5. Get Azure help through Priority Community Support (PCS)
    6. Diagnose and solve problems in Azure Container Apps
    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

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.