504.0 Gateway Timeout

Question

504.0 Gateway Timeout

fceci90 25

ASP.NET 10 Blazor SSR website on Azure Linux App Service B1 plan.
On 5/13 I updated my website and published and it resulted in a gateway timeout. I have since:

Reverted back to old Program.cs and republished
Deleted and recreated new web app and republished
Spent countless hours trying to look through logs and publishing with console logs to figure out the issue (inconsistent every time even when nothing changed but republishing which makes zero sense)
Created a temporary Windows App Service plan (B1 tier) to see if it was my code (this worked right away)
Created a site on a Windows Server 2019 machine hosted on IIS and published there and it works right away.
Created a new branch based on code from before 5/13 and republished and it still doesn't work.

I have spent two weeks and countless hours trying to figure out why this site no longer works on my Linux app service plan. The container keeps timing out and after 230 seconds shuts down. I cannot figure out why. I did notice, even with a very basic one page "static" Razor pages .NET 10 site it takes a very long time (five minutes or so) for the app to publish and be accessible publicly again. Perhaps since this particular site is larger it takes too long? But this site is pretty small so that doesn't make sense to me. Please help.

Thanks,
Frank

Golla Venkata Pavani 6,445 Reputation points Microsoft External Staff Moderator

2026-05-29T16:12:25.8166667+00:00

Hi @fceci90

Thank you for reaching us reaching us regarding the issue.

We have begun looking into it and will share our suggestions with you as soon as possible. If you have any additional details or concerns in the meantime, please let us know. We appreciate your patience while we work on this.

Answer accepted by question author

Sina Salam 30,816 Volunteer Moderator

Hello fceci90,

Follow, I'm glad that you were able to resolve your issue and thank you for posting your solution so that others experiencing the same thing can easily reference this!

Since the Microsoft Q&A community has a policy that "The question author cannot accept their own answer. They can only accept answers by others ", I'll repost your solution in case you'd like to "Accept " the answer. Accepted answers show up at the top, resulting in improved discoverability for others.

Issue:

ASP.NET 10 Blazor SSR site on Azure Linux App Service B1 is failing with 504.0 Gateway Timeout after deployment, while the same application works immediately on Windows App Service and Windows Server IIS.

Error Message:

NIL

Solution:

Customer @fceci90 upgraded from B1 plan to the B2 plan to publish and the plan going forward is to Scale up manually, publish, test site, scale down manually.

I hope this is helpful! Do not hesitate to let me know if you have any other questions, steps or clarifications.

Please don't forget to close up the thread here by upvoting and accept it as an answer if it is helpful.

0 comments

2 additional answers

Your answer

Golla Venkata Pavani 6,445 Reputation points Microsoft External Staff Moderator

2026-05-29T16:12:25.8166667+00:00

Hi @fceci90

Thank you for reaching us reaching us regarding the issue.

We have begun looking into it and will share our suggestions with you as soon as possible. If you have any additional details or concerns in the meantime, please let us know. We appreciate your patience while we work on this.

Answer 1

Well none of this did it for me, but I tried something that seemed somewhat obvious, but I couldn't think it would work... I upgraded to the B2 plan to publish. So the B1 level of Linux app service is too slow to publish a site? The description says it can handle low traffic production sites. Well my site has 0 traffic, and is pretty basic, so I find this hard to believe. I guess running 5 sites oversaturates the 1 vCore and 1.75GB of memory? The other 4 sites are all super basic and have little to no traffic. Perhaps there should be better guidelines to the capabilities of app service plans? I've lost soo much sleep over these last two weeks trying to figure this out. I've tried and tested soo many different things I can't even remember anymore. I guess this will be the plan going forward. Scale up manually, publish, test site, scale down manually.

Answer 2

Sina Salam 30,816 Volunteer Moderator

Hello fceci90,

Welcome to the Microsoft Q&A and thank you for posting your questions here.

I understand that your ASP.NET 10 Blazor SSR site on Azure Linux App Service B1 is failing with 504.0 Gateway Timeout after deployment, while the same application works immediately on Windows App Service and Windows Server IIS.

This is caused by the Azure Linux App Service container not becoming ready within the platform startup/response window, not by Blazor SSR code itself. This is strongly supported by the fact that the same code works on Windows, but the Linux App Service container waits around 230 seconds and then shuts down. Azure App Service has a platform timeout when the application does not return a timely response, and Linux App Service requires the deployed .NET app to start correctly from the compiled application output. - https://ruslany.net/2019/06/azure-app-service-deployment-slots-tips-and-tricks/, https://appservicesperformance.github.io/2023/05/26/arraffinity/

The best practice for resolution is to:

Confirm that the Linux App Service is actually using the supported .NET 10 runtime.
Set the Linux startup command explicitly to the deployed application DLL.
Ensure Kestrel listens on the expected Linux container HTTP port.
Enable App Service logs and check the Linux container startup logs.
If the Linux runtime path remains unstable, temporarily run the app on Windows App Service or publish the app as a self-contained Linux x64 deployment.

After correcting the Linux runtime, startup command, and port binding, the container should respond to the App Service startup probe and the 504.0 Gateway Timeout should stop.

Use the below resources for more reading, validation and steps:

Configure ASP.NET Core apps in Azure App Service: - https://learn.microsoft.com/en-us/azure/app-service/tutorial-custom-container
Azure App Service on Linux FAQ and startup command guidance: - https://appservicesperformance.github.io/2023/05/26/arraffinity/
ASP.NET Core container port change to 8080: - https://medium.com/@g.sowinski/slow-start-of-azure-appservice-on-linux-when-using-a-custom-port-372c11b309f8
Enable diagnostic logs in Azure App Service: - https://azuretar.com/using-startup-command-to-pass-command-line-arguments-to-azure-app-service-for-linux/
App Service request timeout behavior: - https://ruslany.net/2019/06/azure-app-service-deployment-slots-tips-and-tricks/

I hope this is helpful! Do not hesitate to let me know if you have any other questions, steps or clarifications.

Please don't forget to close up the thread here by upvoting and accept it as an answer if it is helpful.

fceci90 25 Reputation points

2026-05-29T18:34:28.35+00:00

Thanks. I'll take a look through these as soon as I can. Still very confusing how the same exact code just stopped working, and my 2 other .NET 10 sites on the same app service plan with similar setups also work without issues, and no other default Azure container settings changed.
Sina Salam 30,816 Reputation points Volunteer Moderator

2026-05-30T01:48:54.34+00:00
Hi @fceci90

Thank you for sharing the outcome and the details of your troubleshooting process.

From what you've described, upgrading from the B1 plan to B2 appears to have resolved the publishing issue, which suggests the problem may have been related to resource constraints on the original plan. That's a good news that it's working for now.

While a B1 plan can support low-traffic production workloads, resource consumption is shared across all applications running within the same App Service Plan. Hosting multiple sites on a single B1 instance can result in CPU or memory pressure during resource-intensive operations such as deployment, application startup, package extraction, or build processes, even when the sites themselves receive little traffic.

We understand that this can be confusing, especially when the applications are relatively simple and traffic levels are low. Your feedback regarding clearer guidance on App Service Plan sizing and multi-site hosting capacity is valuable, and we'll ensure it is passed along to the appropriate team.

We're sorry to hear about the amount of time and effort you've spent troubleshooting over the past two weeks. We appreciate you sharing the resolution, as it may help identify opportunities to improve our documentation and recommendations for similar scenarios.

As a next step, you may want to monitor CPU and memory metrics on the B1 plan to confirm whether resource saturation was the underlying cause. This could help determine whether a permanent scale-up is necessary or whether your current scale-up/scale-down workflow remains the most cost-effective approach.

Meanwhile, in my return I will also try to close this thread by posting your solution as an answer to help others in the community that might be facing similar issue. This will help you to accept as an answer too since you're the only one that can do that.

Regarding your question and requested guideline, use the below reference and additional resources in the link:

B1 is not inherently too slow for publishing, but deployment operations compete for the same CPU and memory as all hosted applications.

Five apps can absolutely saturate a B1 plan if their combined startup, deployment, or runtime resource usage exceeds the available 1 vCPU and 1.75 GB RAM.

Microsoft provides sizing guidance and density recommendations, but exact capacity depends on workload characteristics, which is why scaling from B1 to B2 often resolves resource-related deployment issues.

https://learn.microsoft.com/en-us//azure/app-service/overview-hosting-plans

Thank you once again.
fceci90 25 Reputation points

2026-05-31T01:29:02.4166667+00:00

Hi Sina, thank you for your feedback and for setting up the answer for me to accept. I haven't bothered scaling back down as I am not around this weekend, but on Monday I will scale back to B1 and monitor B1 CPU and memory usage and see how it goes. But seeing as it all ran fine before and it was just the publishing causing issues, I think this would continue to work. Have a nice day and thanks for the help.