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

Adam 1 Reputation point
2022-11-02T17:08:43.247+00:00

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:

256512-image.png

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

256514-image.png

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.

256494-image.png

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

-Adam

Azure Monitor
Azure Monitor
An Azure service that is used to collect, analyze, and act on telemetry data from Azure and on-premises environments.
2,938 questions
Azure App Service
Azure App Service
Azure App Service is a service used to create and deploy scalable, mission-critical web apps.
7,212 questions
0 comments No comments
{count} votes

5 answers

Sort by: Most helpful
  1. Maxim Sergeev 6,566 Reputation points Microsoft Employee
    2022-11-03T06:58:07.023+00:00

    Hi there,

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

    256682-image.png

    0 comments No comments

  2. Adam 1 Reputation point
    2022-11-03T15:14:56.217+00:00

    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.

    256852-image.png

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

    256809-image.png

    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:

    256855-image.png

    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:

    256730-image.png

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

    256780-image.png

    Thanks again for taking the time to try to help!

    0 comments No comments

  3. Marwa Abouawad 281 Reputation points Microsoft Employee
    2022-11-09T17:53:12.41+00:00

    Hi @ Adam-5361

    Welcome to Microsoft Q & A community Forum!

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

    0 comments No comments

  4. ashelley 1 Reputation point
    2022-11-09T18:37:54.32+00:00

    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:

    258849-image.png

    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.

    258779-image.png

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

    0 comments No comments

  5. ashelley 1 Reputation point
    2023-06-13T15:46:50.3933333+00:00

    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.

    requestproperties

    -Adam

    0 comments No comments