Azure Container Registry dedicated agent pool stuck in Queued state

AKA Technologies AS 0 Reputation points
2026-08-15T20:00:30.59+00:00

An Azure Container Registry dedicated Tasks agent pool is stuck in a transitional Queued state and does not recover after repeated scale operations.

Environment:

  • Region: Sweden Central
  • VNet-integrated dedicated ACR Tasks agent pool
  • Agent pool tier: S1
  • Non-production staging workload

Reproduction and observations on 15 August 2026:

  1. az acr agentpool update --count 1 --no-wait is accepted.
  2. Repeated az acr agentpool show polling never reaches count=1 with provisioningState=Succeeded within 15 minutes.
  3. No ACR build is queued.
  4. az acr agentpool update --count 0 --no-wait is accepted during cleanup.
  5. Repeated polling never reaches count=0 with provisioningState=Succeeded within 10 minutes.
  6. The behavior is reproducible across multiple controlled attempts, including after the Azure subscription and payment method were confirmed active.

The workflow is bounded and always requests scale-down, but Azure cannot confirm a healthy zero-capacity state. This also creates concern that agent compute might remain billable while the pool is stuck.

This appears consistent with cases where Microsoft backend remediation/reset is required. Please have an Azure engineer escalate this to a private support case so we can provide the subscription ID, registry name, resource group, agent pool name, and diagnostic run links securely.

Requested outcome:

  • Reset/remediate the agent pool provisioning state in the Azure backend.
  • Confirm the pool is healthy at count=0 and provisioningState=Succeeded.
  • Confirm whether any agent compute remained billable while the pool was stuck.
  • Advise when it is safe to retry the staging deployment.
Azure Container Registry
Azure Container Registry

An Azure service that provides a registry of Docker and Open Container Initiative images.


1 answer

Sort by: Oldest
  1. Allan Solomon Mejia 8,175 Reputation points
    2026-08-15T20:10:18.1333333+00:00

    Hello @AKA Technologies AS

    Given the repeated scale-up and scale-down attempts, I agree this looks less like a task configuration problem and more like the dedicated ACR Tasks agent pool provisioning operation being stuck.

    A few points are worth confirming before escalation:

    • Check the agent pool with az acr agentpool show and capture the complete provisioning state/output.
    • Check the subscription Activity Log for failed or incomplete Microsoft.ContainerRegistry/registries/agentPools operations.
    • Since this is VNet-integrated, verify that the subnet/network configuration still meets the requirements for a dedicated agent pool.
    • Avoid further repeated scale operations while the existing operation remains transitional.

    Microsoft documents dedicated agent pools as infrastructure managed by Azure, while you control the pool configuration and instance count.

    Since both --count 1 and --count 0 are accepted but never converge to provisioningState=Succeeded, and there are no queued tasks, I would open an Azure Container Registry support case at this point. Include the registry and agent-pool resource IDs, region, timestamps of the scale operations, Activity Log correlation IDs, and the output of az acr agentpool show.

    The billing question also needs Microsoft to confirm from backend records. I wouldn't assume that count=0 stopped billing while the resource remained stuck in Queued; support can verify whether agent-pool compute was actually allocated during that period.

    I would also avoid deleting/recreating the pool until Microsoft has captured the backend state, since the current stuck resource may provide useful diagnostic evidence.

    Please "Accept the Answer" if this information helped you. This will help us and others in the community as well.

    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.