504.0 Gateway Timeout

Question

504.0 Gateway Timeout

fceci90 0

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 5,490 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.

1 answer

Your answer

Golla Venkata Pavani 5,490 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

Sina Salam 29,516 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 0 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.
fceci90 0 Reputation points

2026-05-30T00:45:35.28+00:00

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.
Sina Salam 29,516 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.

I will surely get across to you as soon as possible the document resource links as requested. 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.

Thank you once again.

Share via

504.0 Gateway Timeout

1 answer

Your answer