How to delete a App Service health check (or classic ping) from account that shouldn't exist any more (site is deleted)

Question

Hello,

I am trying to find a rogue health check hitting one of my servers. I can tell its from a site that we used to have but I cannot find the resource to delete from in our subscription. Here is an image of the telemetry data of the request I am trying to track down the source for:

See the above image for details but the source of this request is noted in azure as being from azure's synthetic traffic source. I have tried to identify an application insights "App Id' in my account

Since I cannot find the application insights application id matching the source I have also tried querying all resources in our subscription trying to find the url being hit or the resource in question. Below are some of the resource queries I have tried.

Does anyone know how I can find the source of this "rogue health check" so that I can delete / stop it. Thanks!

-Adam

Answer 1

Hi there,

These availability tests are hosted here, did you check this?

Answer 2

Hello,

Thank you for taking to time to look at my dilemma. I agree with you that in the application insights is where you would typically you would find the availability test. However, I am unable to navigate to the application insights of the site that should have the availability check since it does not exist because the site was deleted a long time ago (or should have been). Please note that this site was originally created in 2014 probably and things may have been different back then. I am worried there is some rogue web job that I can't get access to any more or something causing the requests stuck in the infrastructure somewhere. Here is some further clarification of the problem:

As per my original post I tried to look to for an orphaned application insights (one where the site/appservice does not exist but the application insight resource does) where I would be able to access the availability test to delete but I cannot locate it. (I don't believe it is accessible to me).

Using the source ID i tried to find a possible orphaned application insight.

I went through manually all of my application insight resources and could not find it.

Additionally... I tried to find the orphaned availability test by querying for the availability test resource directly. Availability tests that I can find in my account match 2 different flavors (probably based on changes in azure over time,... ie older vs newer), Sometimes they have SyntheticMonitoringId and sometimes they have a configuration.Webtest.

Here are the list of availability tests I can find in my account by manually attempting to query the resources. These match what I expect to exist but the results do not have the "phantom/orphaned" web test that I'm trying to track down and delete:

I can also query for the webtests using the correct type but it comes up with the same list as above and does not show the one i'm trying to track down:

Perhaps someone knows how I can use the find the source of the traffics id's to do a more specific query some how?

Thanks again for taking the time to try to help!

Answer 3

Hi @ Adam-5361

Welcome to Microsoft Q & A community Forum!

Could you please try logging inbound IP address on the health check site?

Answer 4

Hello,

Thank you for looking into this further. You can see that because this is synthetic traffic generated by azure there is no ip address to log. Here is a more recent request than what is in my original post but same idea:

Just to add some additional context, you can see here that these requests are clouding up my failure display on my server which is why it is important to me to try to stop these requests.

Again, thank you for the time for looking at this!

Answer 5

Hello,

I finally have an update for this support ticket. Azure support were able to identify the external subscription id that has the rogue health check running and have provided me with contact details of who owns the subscription id. I am in the process of checking to see if we can can still access this external subscription to shut off the requests. However this explains why none of my queries could discover the resource that was responsible for the rogue health checks. Special thanks to Ashi Sunnam for being so patient and sticking with this issue since November.

A feature request that I think would be helpful for others who find themselves in this situation: The external subscription id should show up in the properties of the request. For instance this would have cut down the time of discovering the problem by a lot if we were able to know ourselves the subscription id of the external resource making these requests. Even if we can't divulge the subscription Id I think at the very least the source of synthetic traffic should be flagged as external to your current subscription.

-Adam