App Service Using Streamlit Gets Stuck and Does Not Load the Application Intermittently

Hi Dcm

We haven’t heard from you on the last response and was just checking back to see if you have a resolution yet. In case if you have any resolution please do share that same with the community as it can be helpful to others. Otherwise, will respond with more details and we will try to help.

Hi Dcm

Thank you for posting your question on the Microsoft Q&A forum.

Based on your description, it seems that the Health Check feature in Azure App Service is not enabled. The Health Check feature helps improve availability by automatically removing unhealthy instances from rotation.

This feature works by pinging a specified health check path on all instances of your web app every minute. If an instance does not respond or responds with a failure for the configured number of attempts (by default, 10 minutes, defined by the WEBSITE_HEALTHCHECK_MAXPINGFAILURES setting), that instance is marked as unhealthy, and Azure App Service will stop routing traffic to it.

For production workloads, it is strongly recommended to configure the Health Check feature. This can help minimize potential downtime that may occur due to a faulty instance and ensure more reliable operation of your application.

You can find detailed guidance in the official documentation here: Monitor App Service instances using Health check

Hi Vimal Lalani
Thank you for sharing details, we will add Health Check feature in Azure App Service.
Please help us investigate root cause of the issue, I have shared details yesterday about resources used in private chat.

Hi Dcm

A likely cause of the intermittent “stuck” behavior is that the app is running on an App Service Plan that isn’t optimized for production workloads. Lower-tier SKUs (Free, Shared, or Basic) share infrastructure and can experience resource contention, which may result in intermittent slowness or unresponsiveness. For production scenarios, it’s recommended to run the app on Standard, Premium, or Isolated App Service Plans, which provide dedicated resources, better performance, and stronger isolation from noisy neighbors.

In addition, make sure health probes are properly enabled and configured on the Azure Application Gateway for your App Service. The probes continuously monitor the health of your App Service instances. If an instance stops responding (for example, due to a transient glitch or resource exhaustion), the gateway marks it as unhealthy and automatically routes traffic only to the healthy instances. This prevents users from being sent to a “stuck” instance and reduces the likelihood of intermittent failures.

Hi Dcm

Just checking in to see if above information was helpful. If you have any further updates on this issue

Hi Vimal Lalani
Thank you for sharing details.
So cause is App Service Plan (B3) that isn’t optimized for production workloads
Could you recommend which plan to use as per as per users count and cost effective point of view, currently we have B3 plan.

E.g. users count < 100 then use Standard S3, users count is between 100 to 200 then Premium v3 P2V3 something like that.

Hi Dcm

In general, scaling should be based on application workload (CPU, memory, I/O, network), not just the number of users, since user activity patterns vary. However, as a rough guideline you can consider:

Standard (S1–S3): Best for small production workloads, light to moderate traffic.

Premium v2/v3 (P1v2, P2v3, etc.): Recommended for medium to large production workloads, improved performance, advanced scaling, and VNET integration.

Isolated (I1–I3): For high-security, compliance, or enterprise workloads requiring isolation.

Instead of mapping plans directly to user counts, monitor App Service metrics (CPU %, memory, HTTP queue length, response time) and scale up/down accordingly.

Azure also supports autoscaling, which helps manage cost-effectiveness while ensuring performance.

Hi Vimal Lalani
Thank you for response.

Q#1:
So to summarize below are two recommendations.

1. Upgrade App service plan
2. Use multiple app service instances (auto-scale)
   Is this correct ?

Q#2 : Regarding "Health probes are properly enabled and configured" --> With single app service, we have below configuration (PFB screenshot) , I hope this is properly configurated ?
Let us know, if any changes/recommendation if we use only single app service.

Yes, it's look correct, Dcm

Kindly ensure that the probe path returns a healthy HTTP 200 response.

Hi Vimal Lalani
Thank you for response.
We checked HTTP 200 as below
I hope this is fine ?

Hi Vimal Lalani
Thank you everyone for your guidance and suggestions. (I am replying from another individual account.)We upgraded our App Service plan from B3 to S3, and the application ran fine for the first 4–5 days. However, we are now facing the same issue again — the application does not load and only shows a blank screen, exactly as described in the original post.

We checked the application logs, but there are no errors reported.

Memory usage: ~1.4 to 1.5 GB (Note: S3 supports up to 7 GB)

This issue is affecting our production environment, so any further help or insight will be greatly appreciated.

Thank you in advance for your support.

Hi @Bipin Kadam / @Dcm

Could you please share web app name & web app url on private message ?

Could you please share web app name & web app url on private message ?

--> Hi Vimal Lalani, Can you tell me, how to share this on private message as this is my new id, can't find any option.

Hi @Bipin Kadam ,

At the top of this thread, you can find a private message like the one shown in the image. I will send you the message, and you can reply to it.

Hi Vimal Lalani,
Thank you for response.
Might be because of my login-id has changed, I can't see the "Private messages" now.

Is there anything can be done ?

Hi @Bipin Kadam

I recommend posting a new question on the forum with new account, if you’re unable to access your DCM account, as we may need to communicate via private messages in the future. Once you create the new post, please share its link here in a public comment so others can reference it as well.

Hi Vimal Lalani,
I am able to old account and shared the required details on private message.

Hi Vimal Lalani
Thank you so much for response.
As per your hint about CPU usage, we have drilled down from when this issue occured.
Please find below more details. Application got stuck on 4-Nov-2025 approx. from 11 am to 4 pm JST. We checked Process full list for this app service from Azure Portal at the time of 4-Nov-2025 approx. 4pm JST. [UTC time: 2025-11-04T06:58:00]

After that manually we restarted the approx. between 6:40 to 7 pm JST and then it started working.

CPU Usage

• Python process (PID 2199359):

%CPU = 100.0% → Using 1 full vCPU.

• Total CPU capacity (vCPU) = 4 × 100% = 400%

Remaining CPU = 400 − 100 = 300% → ~3 vCPUs free

Even though the main Python process is using ~1 vCPU (%CPU ~100) and the S3 instance has 4 vCPUs in total—leaving ~3 vCPUs free— Why is the application still experiencing stuck behavior for few hours ?

Could you help pinpoint the cause, considering most other processes are idle and memory usage is moderate?

Please also recommend Should we try some different settings for app service e.g. different plan or other region etc. ?

Hi @Bipin Kadam / @Dcm

Sure, I'll check and get back to you.

Hi Vimal Lalani
We experienced the same issue in the production environment today. Kindly provide an update and assist in identifying the root cause. Our primary concern at this stage is understanding the initial cause of the problem.

Hi Vimal Lalani
Could you please provide an update and assist in identifying the root cause.
Thank you.

Hi RAMAMURTHY MAKARAPU •Vimal Lalani
We are still facing issue on production.

Can you please give us assist in identifying the root cause.

Hi @Dcm
Apology for delay response.
We reviewed your App Service instance using our internal diagnostics, and it shows that the Health Check feature is currently not enabled, and your application is running on only one worker. When Health Check is disabled, the platform cannot detect if the application becomes unresponsive due to a long-running Python/Streamlit process or a blocked request thread. As a result, even if the instance becomes unhealthy or stuck, Azure continues routing traffic to it, leading to the blank screen and intermittent loading issues you are experiencing. Enabling Health Check allows Azure to automatically monitor your application’s health endpoint every minute and remove the instance from rotation if it stops responding, which significantly reduces downtime and “stuck” scenarios. We strongly recommend enabling Health Check with a valid health endpoint and also considering running more than one instance for production workloads to avoid single-instance failures.
https://learn.microsoft.com/en-us/azure/app-service/monitor-instances-health-check?tabs=dotnet
Let me know if you have any further assistances needed.

Hi Shree Hima Bindu Maganti
Thank you very much for your response.

We reviewed your App Service instance using our internal diagnostics, and it shows that the Health Check feature is currently not enabled, and your application is running on only one worker.

Currently, our application is designed to run on a single instance. Supporting multiple instances would require significant changes.

Question#1 : With the current implementation, if we ensure that a health check endpoint (e.g., /custom_health_check) correctly returns the application’s status, will Azure automatically replace the instance when it becomes unresponsive, even if we continue using a single instance? As per current documentation, I can see it's not possible.

Question#2 : For a single instance only, do you have any recommendations to avoid long-running processes, for example, restarting the app daily? Currently only after restart stuck issue is getting resolved.

Question#3 : By any chance whether this is stuck issue due S3 plan, in other words if we go with premium plan then will this stuck issue gets resolved ?

Hi **Shree Hima Bindu Maganti
**Could you please reply on above questions.