"startup probe failed: connection refused" on Azure Container App with Azure Files volume

Question

"startup probe failed: connection refused" on Azure Container App with Azure Files volume

Daniel Cuellar 0

I have an Azure Container App that is a Web API in .NET 6 and has a volume associated with Azure Files to the /app/wwwroot folder and for a few weeks now when trying to start a new review it throws the error "startup probe failed: connection refused" and that configuration had been working for a year, the source code is functional, the Docker image compiles well and uploads to the Container Registry, the volume configuration has not changed, it works fine locally, it only fails when starting the review in Azure, why is it failing now?

Praveen Kumar Gudipudi 775 Reputation points Microsoft External Staff Moderator

2025-04-21T21:20:07.4366667+00:00

Hello Daniel Cuellar,

Could you please check the private message and provide the required details for troubleshooting the issue further.
Daniel Cuellar 0 Reputation points

2025-04-21T22:25:31.9666667+00:00

Hi, response sent
Praveen Kumar Gudipudi 775 Reputation points Microsoft External Staff Moderator

2025-04-23T18:08:54.4166667+00:00

Hello Daniel Cuellar,

Could you please provide logs from log analytic workspace to identify root cause.
Daniel Cuellar 0 Reputation points

2025-04-23T22:47:18.11+00:00

Hi @Praveen Kumar Gudipudi , in a private message, I'm sharing an exported file of the logs from the ContainerAppSystemLogs_CL table during a patch startup test with the associated Azure Files volume. Change the file extension from .csv to .txt so you can upload the file.
Praveen Kumar Gudipudi 775 Reputation points Microsoft External Staff Moderator

2025-04-24T21:59:35.7133333+00:00

Hello Daniel Cuellar,

I can see ReplicaUnhealthy status in logs. Common Causes and Solutions:

I understand that you are having Startup probe failed error for your container app.

https://learn.microsoft.com/en-gb/answers/questions/2118109/startup-probe-failed

please check above document and if this issue still persistent please let us know.
Daniel Cuellar 0 Reputation points

2025-04-25T19:46:32.3233333+00:00

Hi, I set the maximum possible values for the startup probe, and the revision doesn't work. I'm sharing the configuration and logs in the private messages.
Praveen Kumar Gudipudi 775 Reputation points Microsoft External Staff Moderator

2025-04-28T19:15:08.75+00:00
Hello Daniel Cuellar,

Ensure your startup probe is defined correctly in your configuration file (YAML or equivalent). Here is an example:

Please check the below document: https://learn.microsoft.com/en-us/azure/container-apps/health-probes?tabs=arm-template

startupProbe: httpGet: path: /health port: <your-port-number> initialDelaySeconds: 30 periodSeconds: 10 failureThreshold: 3
Daniel Cuellar 0 Reputation points

2025-04-29T13:50:33.89+00:00
Hi, we configure the application from the Portal, not from the console, to use templates.

The "startup probe" configuration sent is correct: the application is configured with HTTP, port 80, the route is a valid endpoint that responds with 200, and the other values are allowed.

We understand that Azure internally sets default configurations, but as mentioned above, the application has been running with that default internal configuration for a year.

Keep in mind that the error occurs when setting the "Azure Files volume" because without it, the application launches without problems.

On the service's GitHub, we found bugs related to this error where the Azure Files volume issue is present:

https://github.com/microsoft/azure-container-apps/issues/1425

https://github.com/microsoft/azure-container-apps/issues/1423

I would appreciate it if you could validate whether it is a bug in Azure or what alternatives we can implement.
Daniel Cuellar 0 Reputation points

2025-05-02T12:59:02.7166667+00:00

Hi @Praveen Kumar Gudipudi, any news?
LeelaRajeshSayana-MSFT 17,766 Reputation points Moderator

2025-05-14T22:48:53.97+00:00

@Daniel Cuellar Just checking in to see if the above information was helpful. If you have any further query, do let us know. Thank you
Daniel Cuellar 0 Reputation points

2025-05-15T13:12:12.91+00:00

Arko and LeelaRajeshSayana, Thans. We've already made the changes to the source code to avoid mounting the volume files from /app/wwwroot, and it was successful.

I'd like to know how I could receive alerts, such as email, when a problem with the container or the replicas occurs. Since, as I said, the system had been working well for the past few months with that configuration, this suddenly started happening, I'd like to be alerted when the service degrades.
LeelaRajeshSayana-MSFT 17,766 Reputation points Moderator

2025-05-19T16:18:07.8566667+00:00

@Daniel Cuellar Glad to know that the issue is resolved after mounting the files to a different location.

You can create alert rules by leveraging Azure Monitor alerts. These alerts can be configured based on the metrics data or logs. Refer to the article Set up alerts in Azure Container Apps which walks you through the steps of configuring the alerts and receive individual alerts for specific revisions or replicas by enabling alert splitting and selecting Revision or Replica from the Dimension name list.

I am converting the above feedback from Arko to an answer on this thread as it helped resolve your issue. I appreciate it if you can mark it with Accept Answer so that other community members can identify a solution for this issue.

If you have any further questions regarding enabling alerts, please do not hesitate to reach out to us through comments below or open a new question to address it separately. Thank you.

1 answer

Your answer

Praveen Kumar Gudipudi 775 Reputation points Microsoft External Staff Moderator

2025-04-21T21:20:07.4366667+00:00

Hello Daniel Cuellar,

Could you please check the private message and provide the required details for troubleshooting the issue further.
Daniel Cuellar 0 Reputation points

2025-04-21T22:25:31.9666667+00:00

Hi, response sent
Praveen Kumar Gudipudi 775 Reputation points Microsoft External Staff Moderator

2025-04-23T18:08:54.4166667+00:00

Hello Daniel Cuellar,

Could you please provide logs from log analytic workspace to identify root cause.
Daniel Cuellar 0 Reputation points

2025-04-23T22:47:18.11+00:00

Hi @Praveen Kumar Gudipudi , in a private message, I'm sharing an exported file of the logs from the ContainerAppSystemLogs_CL table during a patch startup test with the associated Azure Files volume. Change the file extension from .csv to .txt so you can upload the file.
Praveen Kumar Gudipudi 775 Reputation points Microsoft External Staff Moderator

2025-04-24T21:59:35.7133333+00:00

Hello Daniel Cuellar,

I can see ReplicaUnhealthy status in logs. Common Causes and Solutions:

I understand that you are having Startup probe failed error for your container app.

https://learn.microsoft.com/en-gb/answers/questions/2118109/startup-probe-failed

please check above document and if this issue still persistent please let us know.
Daniel Cuellar 0 Reputation points

2025-04-25T19:46:32.3233333+00:00

Hi, I set the maximum possible values for the startup probe, and the revision doesn't work. I'm sharing the configuration and logs in the private messages.
Praveen Kumar Gudipudi 775 Reputation points Microsoft External Staff Moderator

2025-04-28T19:15:08.75+00:00

Hello Daniel Cuellar,

Ensure your startup probe is defined correctly in your configuration file (YAML or equivalent). Here is an example:

Please check the below document: https://learn.microsoft.com/en-us/azure/container-apps/health-probes?tabs=arm-template

startupProbe: httpGet: path: /health port: <your-port-number> initialDelaySeconds: 30 periodSeconds: 10 failureThreshold: 3
Daniel Cuellar 0 Reputation points

2025-04-29T13:50:33.89+00:00

Hi, we configure the application from the Portal, not from the console, to use templates.

The "startup probe" configuration sent is correct: the application is configured with HTTP, port 80, the route is a valid endpoint that responds with 200, and the other values are allowed.

We understand that Azure internally sets default configurations, but as mentioned above, the application has been running with that default internal configuration for a year.

Keep in mind that the error occurs when setting the "Azure Files volume" because without it, the application launches without problems.

On the service's GitHub, we found bugs related to this error where the Azure Files volume issue is present:

https://github.com/microsoft/azure-container-apps/issues/1425

https://github.com/microsoft/azure-container-apps/issues/1423

I would appreciate it if you could validate whether it is a bug in Azure or what alternatives we can implement.
Daniel Cuellar 0 Reputation points

2025-05-02T12:59:02.7166667+00:00

Hi @Praveen Kumar Gudipudi, any news?
LeelaRajeshSayana-MSFT 17,766 Reputation points Moderator

2025-05-14T22:48:53.97+00:00

@Daniel Cuellar Just checking in to see if the above information was helpful. If you have any further query, do let us know. Thank you
Daniel Cuellar 0 Reputation points

2025-05-15T13:12:12.91+00:00

Arko and LeelaRajeshSayana, Thans. We've already made the changes to the source code to avoid mounting the volume files from /app/wwwroot, and it was successful.

I'd like to know how I could receive alerts, such as email, when a problem with the container or the replicas occurs. Since, as I said, the system had been working well for the past few months with that configuration, this suddenly started happening, I'd like to be alerted when the service degrades.
LeelaRajeshSayana-MSFT 17,766 Reputation points Moderator

2025-05-19T16:18:07.8566667+00:00

@Daniel Cuellar Glad to know that the issue is resolved after mounting the files to a different location.

You can create alert rules by leveraging Azure Monitor alerts. These alerts can be configured based on the metrics data or logs. Refer to the article Set up alerts in Azure Container Apps which walks you through the steps of configuring the alerts and receive individual alerts for specific revisions or replicas by enabling alert splitting and selecting Revision or Replica from the Dimension name list.

I am converting the above feedback from Arko to an answer on this thread as it helped resolve your issue. I appreciate it if you can mark it with Accept Answer so that other community members can identify a solution for this issue.

If you have any further questions regarding enabling alerts, please do not hesitate to reach out to us through comments below or open a new question to address it separately. Thank you.

Answer 1

Hello Daniel Cuellar,

Thanks for providing all the detailed context, configuration, and logs. I reviewed the behavior you've described and also went through the logs you shared from the ContainerAppSystemLogs_CL table. The issue appears to consistently occur when your Azure Container App tries to start with the Azure Files volume mounted to /app/wwwroot, and the error "startup probe failed: connection refused" follows shortly after the container is created.

Based on the symptoms and the fact that the app launches fine without the Azure Files volume, it looks like to me a regression or timing issue introduced recently when mounting Azure Files to system-critical paths like /app/wwwroot. The container may be trying to start the ASP.NET Core app before the volume is fully mounted and ready, especially if the runtime is expecting to read from or write to that path during startup. This behavior aligns with recent issues reported on the Azure Container Apps GitHub repository, where mounting Azure Files to /app/wwwroot leads to container startup failures or readiness probe timeouts.

One workaround you can try is to avoid mounting Azure Files directly to /app/wwwroot. Instead, try mounting the volume to a different path inside the container, such as /mnt/azurefiles, and adjust your application code if needed to reference files from that new location. This prevents potential interference with the ASP.NET hosting environment, which uses /app/wwwroot internally to serve static files and perform initialization tasks. If you must use files during startup, consider adding logic to copy them into /app/wwwroot after ensuring the volume is ready, or delay access to the volume until after the app is fully initialized.

I understand that your setup has been working for a year, and it's frustrating when something breaks without any configuration changes. However, this looks very likely to be a timing or mounting regression on the Azure platform side affecting certain paths. Mounting to a non-critical path like /mnt/azurefiles should give your application a stable environment to initialize correctly without hitting startup probe failures.

Let me know if trying that helps resolve the issue. Thanks

Share via

"startup probe failed: connection refused" on Azure Container App with Azure Files volume

1 answer

Your answer