Making this as an answer due to character limitations.
Hello @Anonymous , Thank you for reaching out, apologies for the delay.
I tried a similar set-up on my end and was able to generate the alert when one of the backend web-app was in degraded state.
I think the issue observed here is due to the status of the backend web as mentioned by you above the app service was in stopped state. As per the documentation here
An endpoint with a Stopped status isn't monitored. When App Service endpoints are added to an Azure Traffic Manager profile, Azure Traffic Manager keeps track of the status of your App Service apps (running, stopped, or deleted) so that it can decide which of those endpoints should receive traffic.
For example, when I stopped my web-app above the Monitor status immediately changed to stopped.
In order to test this scenario, I think you can set-up a probe path in such a way that it can return a non-200 response when configured to do so.
As per the documentation here. A best practice is to set the probe path to something that has enough logic to determine that the site is up or down. In the previous example, by setting the path to "/favicon.ico", you are only testing that w3wp.exe is responding. This probe may not indicate that your web application is healthy. A better option would be to set a path to a something such as "/Probe.aspx" that has logic to determine the health of the site. For example, you could use performance counters to CPU utilization or measure the number of failed requests. Or you could attempt to access database resources or session state to make sure that the web application is working.
I tried this using a simple test app at my end where I set the /healthstatus
as my probe path and I manipulated the status code to test the alerts.
Hope this helps! Please let me know if you have any additional questions. Thank you!