Cannot Diagnose SocketException problems with App Service Plan, documentation out of date


  • I'm looking into an intermittent SocketException in a production environment. After some googling, I found this article:

    The deep dive article it links to is broken. I eventually googled the title and found another instance of it hosted on github, here: 

    The user interface shown in the article is out of date, it is completely different now. You can check for TCP Connection issues if you know to search for it (it's not linked on the landing page like the blog, it's buried). The report it gives back is different as well. Instead of TCP Connections, Connection Rejections, and Open Socket Handles as mentioned in the blog article, the report only shows TCP Connections, Connections per Instance, and Connection Rejections. Nothing about socket handles.

    Because of this, you can figure out that an instance of an app service plan is leaking outbound connections, and you can look at the outbound ports to infer what kind of connection it is (80 means web service, 1433 is sql, 27017 is mongo, etc), but you can't tell which app service is doing it.

    For my case there are like 40 apps running on this service plan, any one of them could be causing the leaks, and there is apparently no way to narrow it down in production. I reached out to the Azure Support twitter (, they asked me to post about it here.

    I also tried CMD and Powershell terminals through Kudu on some of the apps running on the service plan. Unfortunately netstat requires elevation, so I can't get any network metrics that way either. So...I guess the next step would be to orchestrate the whole infrastructure locally and hit them one at at time until I find the leak.

    Tuesday, May 21, 2019 8:59 PM

All replies

  • Hello dusda, thank you for reaching out. I apologize for the trouble you had with the documentation. I have shared your experience with the Azure App Services Doc lead for awareness.

    Troubleshooting outbound connections can be tricky as there are platform limitations as to what can be exposed externally when dealing with this type of data. As a result, the best option is to open a support to have a support engineer drill into the logs and see what app might be leaking. If you do not have a support plan, please reach out to me at with your subscription ID and the URL of this forum post.

    We look forward to your reply.

    Wednesday, May 22, 2019 2:57 AM