Azure Web App Container Issue

3 Proven Fixes for Azure Web App Container Not Starting & Deployment Slot Routing Errors

ByMAK
views (Today/Total) 2025 / 2025
6 min read
ChatGPT Summarize in ChatGPT
Deploying containers to Azure App Service should be seamless, but often, the “Azure Web App Container not starting” error or “Errors routing requests to application container” during a slot swap can bring your CI/CD pipeline to a halt.

In this guide, we’ll walk through the exact steps to diagnose and resolve these issues using Azure Resource Health and specific environment variables.

Azure App Service on Linux and Web App for Containers
Phase 1: Diagnosing the Startup Failure – Azure Web App Container not starting

Before changing settings, you need to see what’s happening inside the container.

The Diagnostic Path:

  1. Navigate to the Azure Portal and select your Web App.
  2. On the left menu, go to Diagnose and solve problems.
  3. Select Availability and Performance → Web App Troubleshooter.
  4. Check the Container Logs.

The Common Culprit: In our case, the logs showed the app starting successfully and connecting to Redis, but it was listening on the wrong address: Now listening on: http://[::]:*. This indicates a port mismatch between what Azure expects and what the container is providing.

Detailed Troubleshooting Analysis:

Site failed to startup after 1800.0138893 sec

It Means…..Azure waited 30 minutes (1800 seconds) for the container to become “ready”, Azure never received a successful readiness signalAzure then killed the container and marked it unhealthy

Now listening on: http://[::]:*
Application started. Press Ctrl+C to shut down.
Hosting environment: Integration
Content root path: /app

This Confirms that, the container starts. The application boots successfully. The web server binds to a port. No crash, no exception, no OOM. So this is not; Dockerfile issue, Startup command issue, Image pull issue

Now listening on: http://[::]:*

What this means..Azure App Service does NOT probe arbitrary ports. App listens on port 80, OR App listens on port defined by WEBSITES_PORT, OR App responds correctly to Health Check path. If Azure cannot connect → it assumes startup failure.

Phase 2: Fixing the Container Startup (Port Mapping)

Azure App Service defaults to port 80. If your .NET core app or custom container listens elsewhere, the platform’s health check will fail, and it will kill the container.

Step-by-Step Configuration

To fix this, you must explicitly tell Azure which port to use by updating the Environment Variables (Settings → Configuration → Application Settings):

  1. WEBSITES_PORT: Set this to 80. This tells Azure to route traffic to port 80 inside your container.
WEBSITES_PORT
  1. ASPNETCORE_URLS: Set this to http://0.0.0.0:80.Note: Using 0.0.0.0 is critical because it tells the app to listen on all available network interfaces, not just localhost, which is required for container networking.
ASPNETCORE_URLS

Adjusting the Container Timeout

If your app has a heavy startup (e.g., initializing Redis or large DB migrations), the default 230-second timeout might be too short.

  1. Add/Update: WEBSITES_CONTAINER_START_TIME_LIMIT.
  2. Value: Increase this to 400 or 600 (seconds).
  3. Restart the Web App to apply changes.
Phase 3: Optimizing the Health Check Path

By default, Azure App Service attempts to “ping” the root path (/) of your application to see if it is alive. While this works for simple sites, it often causes issues for modern APIs or containers.

The Change: Moving from /health to /

In the Azure Portal, navigate to Monitoring → Health check (or via Application Settings using WEBSITE_SWAP_WARMUP_PING_PATH). We updated the path from the default /health to /

Health check - Errors routing requests to application container
Health Check and Container Status

Phase 4: Resolving Deployment Slot Swap Errors

A common error during a swap from Staging to Production is:

“Errors routing requests to application container”

Azure Deployment Slot Error

This happens because Azure attempts to swap the traffic before the container in the target slot is fully “warmed up.” The platform thinks the container is “up” because the process started, but the application logic isn’t ready to handle requests yet.

The Solution: Warmup Pings

Add these settings to both Production and Staging slots to ensure a smooth transition:

  1. WEBSITE_SWAP_WARMUP_PING_PATH: Set to /health (or your app’s health check endpoint). Azure will hit this path to verify readiness.
Azure Web App Container not starting WEBSITE_SWAP_WARMUP_PING_PATH
  1. WEBSITE_SWAP_WARMUP_PING_STATUSES:
    • The Change: We removed/deleted the value 200 from this setting.
    • Why? By default, Azure is satisfied with any response. When you explicitly set it to 200, the swap will strictly fail if it receives anything else (like a 202 or 302). However, as discussed in How to debug Azure app service slot swap failure, if your app has complex redirects or specific initialization codes, a strict “200” requirement can cause the swap to hang or fail unnecessarily. Deleting it allows Azure to use its default logic, which is often more resilient during complex container boots.

Find out More

My previous blogs;

References