🚨 Azure Error Guide: 'Container didn't respond to HTTP pings on port' — Fix App Service Startup

Overview

When Azure App Service (Web App for Containers / Linux) starts your container, it waits for the app to accept HTTP on the expected port. If it never does, the platform kills the container and logs:

2026-07-09T10:14:52  ERROR - Container myapp_0 for site myapp did not start within
expected time limit. Elapsed time = 230.41 seconds
2026-07-09T10:14:52  ERROR - Container myapp_0 didn't respond to HTTP pings on port: 8080,
failing site start. See container logs for debugging.
2026-07-09T10:14:52  INFO  - Stopping site myapp because it failed during startup.

The site then shows “Application Error” or an HTTP 503 until it starts responding on the port App Service is probing.

Symptoms

• Deploying a custom container leaves the site returning HTTP 503 / “Application Error.”
• Log stream repeats “didn’t respond to HTTP pings on port: , failing site start.”
• The container runs fine locally with docker run but fails only on App Service.
• Startup succeeds intermittently for slow-booting apps, failing when boot exceeds the ping timeout.
• The app listens on a port (e.g. 3000) different from the one App Service is probing (8080/80).

Common Root Causes

• App listens on the wrong port. App Service defaults to probing port 8080 (Linux) unless told otherwise; an app bound to 3000/5000/80 is never reached.
• WEBSITES_PORT not set / mismatched. The app’s real port is not communicated via the WEBSITES_PORT app setting.
• App binds to localhost only. Listening on 127.0.0.1 instead of 0.0.0.0 means the ping from outside the app never connects.
• Slow startup exceeding the timeout. Heavy init (migrations, JIT warmup, downloading models) takes longer than the container start time limit.
• App crashes on boot. A missing env var, bad connection string, or unhandled exception kills the process before it can listen.
• Wrong entrypoint / no listener. The image never actually starts an HTTP server (bad CMD/ENTRYPOINT, wrong start command).

Diagnostic Workflow

All commands below are read-only. First read what the container actually logged during startup:

# Tail the live log stream to see the app's own startup output and the ping failure.
az webapp log tail --resource-group <rg> --name <app>

# Download the full docker/container logs for the failed start.
az webapp log download --resource-group <rg> --name <app> --log-file logs.zip

Check the port-related app settings and startup command:

# Is WEBSITES_PORT set, and to what? Any custom startup command?
az webapp config appsettings list --resource-group <rg> --name <app> \
  --query "[?name=='WEBSITES_PORT' || name=='PORT'].{name:name, value:value}" --output table

az webapp config show --resource-group <rg> --name <app> \
  --query "{startupCommand:appCommandLine, linuxFxVersion:linuxFxVersion, alwaysOn:alwaysOn}" --output json

Confirm the image and container settings:

# Which image/tag is configured and from which registry?
az webapp config container show --resource-group <rg> --name <app> --output json

Example Root Cause Analysis

A team containerized a Node.js API that listened on port 3000 and worked perfectly with docker run -p 3000:3000. On App Service it returned 503, and the log stream showed “didn’t respond to HTTP pings on port: 8080.”

The log made the mismatch obvious: App Service probed 8080, but the app listened on 3000. Checking app settings with az webapp config appsettings list confirmed WEBSITES_PORT was not set, so the platform fell back to its default probe port. The container itself was healthy — it just wasn’t reachable where App Service looked.

The fix was to set WEBSITES_PORT=3000 (az webapp config appsettings set), telling App Service to probe the port the app actually uses. On the next restart the pings succeeded and the site came up. As a hardening step they also confirmed the server bound to 0.0.0.0, not 127.0.0.1. Root cause: port mismatch between the app’s listener and App Service’s HTTP ping, resolved with WEBSITES_PORT.

Prevention Best Practices

• Set WEBSITES_PORT to the exact port your app listens on whenever it is not 80/8080, so App Service probes the right port.
• Bind to 0.0.0.0, never localhost/127.0.0.1, so the container is reachable from the platform’s health ping.
• Keep startup fast, or move heavy init (migrations, warmup) out of the critical boot path; increase WEBSITES_CONTAINER_START_TIME_LIMIT only if genuinely needed.
• Fail loudly and log to stdout/stderr so az webapp log tail shows why the process died before listening.
• Validate required config at startup and provide clear errors for missing connection strings/env vars.
• Test the exact image the way App Service runs it (correct port, env, no host networking) before deploying.

Quick Command Reference

# Watch startup logs live.
az webapp log tail -g <rg> -n <app>

# Check/Set the port App Service should probe.
az webapp config appsettings list -g <rg> -n <app> --query "[?name=='WEBSITES_PORT']"
az webapp config appsettings set -g <rg> -n <app> --settings WEBSITES_PORT=3000

# Inspect startup command and runtime.
az webapp config show -g <rg> -n <app> --query "{cmd:appCommandLine, fx:linuxFxVersion}"

# Show the configured container image.
az webapp config container show -g <rg> -n <app>

# Restart to re-run startup after a fix.
az webapp restart -g <rg> -n <app>

Conclusion

“Container didn’t respond to HTTP pings on port” means App Service started your container but never got an HTTP response where it probed. The overwhelmingly common cause is a port mismatch — fix it by setting WEBSITES_PORT to your app’s real port and binding to 0.0.0.0. For the rest, read the container log stream: a crash-on-boot or a startup slower than the time limit will be visible there. Fast, loud, correctly-bound startup keeps this 503 from recurring.