Your Azure App Service container deployment finished, but all you see is an “Application Error”. Here’s the most common cause and how to fix it for good: mismatched container and platform port configurations.

Azure App Service Container Not Starting After Deployment – Here’s What Fixed It

It’s 11 PM on a Tuesday. The deployment pipeline for `prod-user-service` just went green. You do a quick refresh in the browser, and your heart sinks. All you see is the generic, soul-crushing “Application Error” page. The logs are eerily quiet. You SSH into the container and it’s running, but it’s just not… there. If you’re in DevOps long enough, you’ll burn a whole night chasing this exact ghost. It almost always comes down to one simple, infuriating thing: ports.

So, What’s Really Going On Here? The “Why” Behind the Silence

Let’s get one thing straight. When you see that error, it’s not that your container failed to start. It’s that the App Service front-end, the thing that handles all the incoming public traffic on port 80 and 443, has no idea how to talk to the application running inside your container.

Think of it like this: App Service is the doorman for an apartment building. It knows the building’s main address (your `.azurewebsites.net` URL). But your container is a specific apartment, say, #3000. If you don’t tell the doorman which apartment the guest is visiting, the guest is left standing in the lobby. Your application is listening on a port (e.g., 3000, 5000, 8080), but the App Service platform, by default, is trying to forward traffic to port 80 inside the container. When it gets no answer, it gives up and shows you that lovely error page.

The Solutions: From Quick & Dirty to Clean & Permanent

I’ve seen teams handle this in a few ways. Depending on your situation—whether you’re in a panic trying to fix production or you’re setting up a new service—one of these will be the right call.

Solution 1: The Quick Fix (The “Get Me Out of This PagerDuty Alert” Method)

This is the fastest way to get your site back online. You don’t need to rebuild your container or change any code. You’re just telling the App Service “doorman” which apartment number to buzz.

You do this by setting an Application Setting in the Azure Portal:

1. Go to your App Service -> Configuration -> Application settings.
2. Click “New application setting”.
3. Set the name to WEBSITES_PORT.
4. Set the value to whatever port your application is listening on inside the container (e.g., 8080, 5001, etc.).
5. Save the changes. The App Service will restart.

WEBSITES_PORT = 8080

Within a minute or two, your application should be live. It’s a lifesaver, but I consider it a short-term fix.

Darian’s Take: Look, this works, and it works fast. But it creates “invisible knowledge.” A new engineer on the team won’t know why this is set unless they dig into the portal. It’s configuration living outside of your code and Dockerfile, which I’m never a fan of.

Solution 2: The Permanent Fix (The “Do It Right” Method)

The best long-term solution is to make your container’s configuration explicit and align it with your application code. This means ensuring your Dockerfile, your app, and your App Service config all agree.

Step 1: Update your application code (if needed)
Ensure your app listens on a specific port. For a Node.js Express app, for example, it would be something like this:

const port = process.env.PORT || 8080;
app.listen(port, () => {
  console.log(`Server listening on port ${port}`);
});

Step 2: Explicitly expose the port in your Dockerfile
The EXPOSE instruction is documentation for humans and other tools. It clearly states which port the container is intended to serve traffic on. It makes your container’s contract crystal clear.

# Dockerfile
FROM mcr.microsoft.com/dotnet/aspnet:7.0
WORKDIR /app
COPY . .

# This is the important line!
EXPOSE 8080

# You might also need to tell ASP.NET Core which URL to listen on
ENV ASPNETCORE_URLS=http://+:8080

ENTRYPOINT ["dotnet", "YourApp.dll"]

After rebuilding and redeploying your container with this Dockerfile, you would still set the WEBSITES_PORT Application Setting to 8080. The difference is that now, your infrastructure-as-code (the Dockerfile) and your runtime configuration (App Settings) are in perfect sync. No more guessing.

Solution 3: The ‘Nuke and Pave’ Option (When All Else Fails)

Sometimes, Azure gets into a weird state, especially with persistent storage or networking configurations. If you’ve tried the port fixes and you’re still getting errors, it’s time to check for other culprits before you lose your mind.

1. Check the Container Logs: Don’t just check the “Log stream”. Go to Deployment -> “Container settings”. This view often shows logs from the Docker daemon itself, which can reveal if the container is crash-looping due to a bad environment variable or a missing file before your app even starts.
2. Validate Environment Variables: A typo in a database connection string (e.g., `prod-db-o1` instead of `prod-db-01`) can cause your app to fail on startup before it ever binds to a port. Double-check everything in the Configuration blade.
3. The Nuke: If you are absolutely certain your container runs locally, delete the App Service Plan and the App Service instance completely. Then, redeploy from scratch using your pipeline. It sounds drastic, but I’ve seen this fix unexplainable issues that would have taken another five hours to debug. It’s the “turn it off and on again” of the cloud world.

Warning: Obviously, this is a last resort for production. But for a staging environment that’s acting up? It’s often faster to rebuild than to debug a phantom platform issue.

Comparing the Approaches

Here’s a quick breakdown of when to use each fix:

At the end of the day, the silent container is a rite of passage. Don’t let it discourage you. 99% of the time, it’s just a miscommunication about ports. Fix it right, document it, and save the next engineer (or your future self) from that late-night headache.

Darian Vance

Lead Cloud Architect & DevOps Strategist

With over 12 years in system architecture and automation, Darian specializes in simplifying complex cloud infrastructures. An advocate for open-source solutions, he founded TechResolve to provide engineers with actionable, battle-tested troubleshooting guides and robust software alternatives.

🤖 Frequently Asked Questions