App Services Container Stuck In Pulling

Question

Hi,

I'm having trouble with an app service is a pulling the same container for the last 24 hours. I tried several attempt to change this state by:

• Selecting another container
• Restart of app service
• Restart of instance
• Replace of instance
  without any success.

There is not a single log entry available which shows what is happening, except that the container is being pulled at the moment.

Please advise

Answer 1

Hi @Ronny Lerch

Thank you for reaching out to Microsoft Q&A.

When an Azure App Service for Containers remains in the “Pulling image” state for an extended period without producing any meaningful logs, this typically indicates a platform‑level issue during the image pull phase rather than an application startup problem. By default, Azure App Service does not surface detailed errors related to container image pulls unless container logging is explicitly enabled. As a result, issues such as registry authentication failures, DNS resolution problems, network connectivity restrictions (for example, private endpoints or VNet‑restricted registries), or stale image‑pull workers can cause the platform to repeatedly retry the pull operation silently. Standard actions like restarting the app service, restarting or replacing instances, or switching images may not resolve the issue because the underlying image pull process itself is blocked or misconfigured.

Refer below points to resolve this issue or use them as a workaround:

Enable container logging and review image pull logs By default, image pull errors are not visible in standard App Service logs. Enable Docker container logging so that authentication, DNS, or network‑related failures during the pull operation can be identified.

az webapp log config \
 --name <app-name> \
 --resource-group <resource-group> \
 --docker-container-logging filesystem

You can then stream logs using:

az webapp log tail \
 --name <app-name> \
 --resource-group <resource-group>

Alternatively, review logs directly via:

https://<app-name>.scm.azurewebsites.net/api/logs/docker

Verify registry access and network configuration If the container image is hosted in a private registry (such as Azure Container Registry with private endpoint or firewall rules), ensure that the App Service can reach the registry. This includes validating DNS resolution and network paths. If the registry is accessible only through a VNet, the App Service must be configured to pull images via that VNet.

Enable VNet image pull for private registries When using a VNet‑restricted registry, explicitly enable image pulling over the VNet for the App Service:

az resource update \
 --resource-group <resource-group> \
 --name <app-name> \
 --resource-type "Microsoft.Web/sites" \
 --set properties.vnetImagePullEnabled=true

Without this setting, the App Service may continuously retry pulling the image without success.

Validate authentication to the container registry Confirm that the App Service is correctly authenticated to the registry. If using Managed Identity, ensure the identity is enabled and has the AcrPull role assigned. If using username and password, verify that the credentials configured in the App Service settings are correct and not expired.

Force a platform reset using a known‑good image As a workaround, temporarily configure the App Service to use a public, known‑good container image. Once the app starts successfully, switch back to the original image. This action often forces Azure to reinitialize the image pull pipeline and clear any stuck state.

Answer 2

Use logging and image-pull diagnostics to understand why the container pull is hanging, then verify registry access and networking.

1. Enable and check container logs
   • Turn on container logging and stream logs to see what App Service is doing during the pull:

          az webapp log config \
            --name <app-name> \
            --resource-group <resource-group> \
            --docker-container-logging filesystem
          
          az webapp log tail \
            --name <app-name> \
            --resource-group <resource-group>
     

   • Alternatively, browse to: https://<app-name>.scm.azurewebsites.net/api/logs/docker
   • This should show any image pull errors (auth, DNS, timeouts) that are not visible in the main App Service logs.
2. If using a network-protected registry (ACR with private endpoint, on-prem, or registry in a VNet)
   • Ensure the app is integrated with the correct virtual network and DNS is configured so the registry FQDN resolves.
   • Enable image pull via VNet so App Service uses that path to reach the registry:

          az resource update \
            --resource-group <group-name> \
            --name <app-name> \
            --resource-type "Microsoft.Web/sites" \
            --set properties.vnetImagePullEnabled=true
     

   • If the registry is unreachable or DNS cannot resolve it, the pull can hang or repeatedly retry.
3. Validate the image and registry outside App Service
   • From a machine with similar network constraints (for example, a VM in the same VNet), run:

          docker pull <your-registry>/<image>:<tag>
     

   • If this fails, fix registry access (credentials, firewall, private endpoint, DNS) before retrying in App Service.
4. Confirm the image reference and tag
   • Ensure the image name and tag configured in App Service are correct and that the tag actually exists in the registry.
   • If you recently changed tags, App Service will pull all layers again; a missing or inaccessible tag will show up as an error in the container logs.
5. Use a known-good test image
   • Temporarily point the App Service to a public, known-good image (for example, a simple sample container) to confirm that the App Service itself can pull and start containers.
   • If the test image works but the original does not, the issue is with the original image or its registry access.
6. Be aware of pull behavior and delays
   • App Service performs a docker pull on each restart and pulls only changed layers; if the app moves to a new instance or scale-out occurs, all layers must be pulled again.
   • While a new container is being pulled and started, App Service continues serving from the old container until the new one is ready. If the new container never becomes ready (for example, pull never completes), the app can appear stuck.

If, after enabling container logs and validating registry/network access, the pull is still stuck for many hours with no errors, open a support ticket so the platform team can inspect backend logs for that specific app and region.

---

References:

• Configure a custom container for Azure App Service (container-windows)
• Configure a custom container for Azure App Service (container-linux)
• Migrate custom software to Azure App Service by using a custom container (container-linux)
• Quickstart: Run a custom container in Azure (container-windows-cli)
• Troubleshoot start failures in Azure Container Apps