Time taken by the backend to respond to application gateway's health probe is more than the time-out threshold in the probe configuration. Either increase the time-out threshold in the probe configuration or resolve the backend issues.

Question

I am trying to configure Azure Application Gateway to route traffic to an Azure Container App running in an internal Container Apps Environment.

The application is a simple Flask service exposing:

/ -> returns JSON

/health -> returns 200 {"status":"ok"}

Architecture:

Application Gateway -> Backend pool → Azure Container Apps internal ingress -> Container App

Network setup:

VNet: vnet-aca-demo Subnets: - snet-public-agw (10.x.x.0/24) – Application Gateway - snet-private-aca (10.x.x.0/24) – Container Apps Environment

The Container Apps internal load balancer address is:

10.x.x.x

Application Gateway configuration:

Backend pool target: 10.x.x.x Backend settings:

Protocol: HTTP

Port: 8080

Override hostname: No

Health probe:

Protocol: HTTP

Path: /health

Port: 8080

Match status: 200-399

Main Problem:

Application Gateway backend health shows:

Status: Unhealthy

Error message:

Time taken by the backend to respond to application gateway's health probe

When running Connection troubleshoot from Application Gateway:

Destination: 10.x.x.x

Results:

Connectivity test: Unreachable

However:

both subnets (snet-public-agw and snet-private-aca) have no NSG assigned

routing appears correct

• the Container App is running and reachable internally via its ingress URL Expected behavior Application Gateway should successfully probe:

    http://10.x.x.x:8080/health
  

  and mark backend as:

    Healthy
  

Answer 1

Hello dawidk

It looks like your Application Gateway can’t reach your Container App’s internal ingress on 10.0.3.123:8080 fast enough (or at all), so the health probe is timing out. Here are a few things to check and try:

1. Verify raw connectivity Spin up a quick VM in the same VNet/subnet as your App Gateway and try: curl -v http://10.x.x.x:8080/health If that fails, you know it’s a network issue (NSG, UDR or platform‐level policy blocking traffic).

Also, please review the application gateway response logs and check how long the server is taking to respond. You can also try accessing your container directly, bypassing the application gateway, to see how your backend is performing and measure its response time. And also share the error status code.

1. Ensure your Container App’s internal ingress hostname matches the probe By default the internal ingress expects a specific Host header (e.g. <app>.<env>.internal.azurecontainerapps.io). In your Backend HTTP settings, set “Override with specific domain name” to that internal FQDN. Point your probe to http://10.x.x.x:8080/health but override the hostname to the Container App’s private DNS name.
2. Double-check your VNet/Udr/NSG Even though you haven’t assigned NSGs, Azure Container Apps environments can have built-in network policies. Make sure there are no User-Defined Routes dropping traffic between the AGW and the ILB.
3. Increase your probe timeout (if your service really is slow) Default timeout is 30 seconds. If your Flask health check sometimes takes longer, bump it to 60–90 seconds in the probe settings.
4. Test end-to-end from the AGW host Use the Application Gateway’s “Connection troubleshoot” blade after you fix the above to confirm “Reachable.” Hope that helps you get your backend marked Healthy!

Check the below reference document:

https://learn.microsoft.com/en-us/troubleshoot/azure/application-gateway/application-gateway-backend-health-troubleshooting

I have initiated a private message. Please check it and provide the necessary information so we can discuss further on your concern.

---

Hope the above answer helps! Please let us know do you have any further queries.

Please do consider to “up-vote” wherever the information provided helps you, this can be beneficial to other community members.

Answer 2

hey dawidk,

this is not a timeout problem it is a connectivity problem.

The message about probe timeout is misleading because your connection troubleshoot already says Unreachable, which means appgateway cant reach 10.0.3.123 at all. That ip is the internal load balancer of the container apps environment and it doesnt behave like a normal vm ip. Application gateway cannot just talk to it directly unless the networking and port mapping are aligned with how aca exposes traffic.

Are ur container app ingress is actually listening on port 8080 internally and that targetPort in aca matches what app gateway is probing. In container apps the external port and the container targetPort are different things and many times the app listens on 80 while people probe 8080.

Look at the container apps environment is configured to allow traffic from other subnets in the same vnet. even without nsgs internal aca environments use a managed load balancer and sometimes require proper dns based routing instead of raw IP access. Instead of pointing app gateway to 10.0.3.123 directly try using the internal fqdn of the container app and enable hostname override in backend settings.

See if effective routes on the app gateway subnet to confirm traffic to 10.0.3.0/24 is vnet local and not going somewhere else. If connection troubleshoot says Unreachable, this is network path level, not probe timing. Fiix is usually correct port alignment or using the container app internal fqdn rather than the static environment ip.

rgds,

Alex