Azure App Service - Monitoring Website Availability with Application Insights
- Estimated read time: 8 min read
- Written by Chad Campbell on Jun 25th 2016
Hi there! I’m Chad. I understand how important it is to know if your website or web app goes down. Personally, I had a Node app in Azure that periodically went down. And when it happened, I wanted to know about it right away. So, naturally, I looked for ways to be notified when this happened. In this video, I’d like to share with you what I learned. In short, I learned how to use Microsoft Azure Application Insights to monitor website availability.
To demonstrate, I have a test version of my website showing on the screen. You’ll notice from the URL that this site is hosted as an Azure Web Site. In this site, I have a page that I hit to see if the site is up-and-running. The url for this page is located at
/utils/ping. I use a separate page to keep my site statistics clean. As you can see, when I visit the URL, it’s a basic page that simply says “Success”. Nothing special. Just something to ensure that everything is running.
To get notified if my web site goes down, I’m going to jump into the Microsoft Azure Portal. Once in the portal, I’m going to add an Application Insights service. Application Insights is a service within Microsoft Azure that lets you monitor your app. This includes things like availability, performance, and usage. In short, this service helps you monitor your application’s health.
I’m going to provide some information that identifies the app I want to monitor. First, I’m just going to call this instance of the Application Insights Service “Test Website”. The reason why is because I’m going to use this instance of the service against the test version of my website.
Then, I’ll choose my application type. As mentioned earlier, I have a Node app. For that reason, I’m going to choose the “Other” option. Then, I’ll choose a subscription and one of my existing resource groups. Finally, I’ll choose a location and click “Create”. Once this service is created, I can create a “Web test”.
A Web test is a great way to check web site availability. Availability is one of the most important vital signs of an app. To create a Web test from the “Application Insights” blade, I’m going to click the “Availability” tile. Once clicked, the “Web tests” blade will appear. I’ll click the “Add Web test” button to create a new web test.
The web test blade appears and immediately, I’m prompted to enter the test’s settings. First, I’ll set the “Test name” field to “Is App Running”. I like to prefix boolean type tests with “is” so that I know by looking at it that this test basically has one test with one outcome. Also notice that I was able to use an easily readable name instead of camel-casing or something of that nature.
Next, I’ll leave the “Test type” field as “URL ping test”. I’m doing this because I’m only interested in whether my site is running or not. So, I’ll use one single URL for that purpose. But, there is the “Multi-step test” option if you want to check a series of URLs in succession. However, that is beyond the scope of this video.
Next to bat is the “URL” field. This field is the URL that the Azure Application Insights service will check periodically. For that reason, I’m going to put the complete path to my ping URL into this field. Once set, you can decide if you want to include the URLs referenced by your page in the test. Personally, I choose not to do this.
Simply because it goes beyond the focus of what I’m trying to test: whether my web site is up and running or not.
Next is a flag that determines whether or not to retry failures. As the hint shows, if this is enabled, the Azure Application Insights service will automatically attempt to re-ping the URL if a failure is encountered. This retry attempt will happen in 20 second iterations. If three successive failures happen, the Azure Application Insights service will determine that the web test has failed. Personally, I want to know if my site is down. So, I choose to uncheck this box.
If we go to the next field, you can see that you have some control over how often this test happens. Personally, I like to use the most granular setting: 5 minutes. However, you have the option to choose 10 or 15 minute intervals if you prefer.
You also have the option of choosing which geographies tests are running from. In my opinion, this is a really powerful option. This is really useful if your site is running on multiple servers for load balancing purposes. Personally, I don’t have a need for this at this time. It’s still worth being aware of this setting for more advanced scenarios though.
The next field is the test assertion, or “Success criteria”, field. If I click on this field, you can see that I get a number of new options. These options let me set the situation under which the web test will be viewed as a success. In the “Success criteria” blade, I can set the “Test Timeout”, Whether an HTTP response code has to match a specific value, and if the response must contain specific content. Considering I’m only interested in whether my site is running or not, I’m going to set this value to 200. A 200 is a success status code used for successful HTTP requests.
I’ll click “OK” to set the success criteria. To be notified whenever one of the success criteria have failed, I’ll setup an Alert. Considering I want to be notified immediately, I’m going to change the default threshold from 3 to 1. By default, the web test would have to fail from at least three locations before I’d get notified. But now, if a failure occurs from any of the locations, I’ll get notified.
I now have the option to set how long the failure must persist before being notified. If there’s a problem, I don’t want it dragging on. For that reason, I’ll leave it at the default value of 5 minutes.
The final three fields let me set how to send a notification if the web test fails the success criteria. The first field lets me decide whether or not to notify the Azure Subscription administrators. If this is checked, the email address will automatically be pulled from Azure. If there are additional email addresses I’d like to notify in the event of the error, I can enter them in the next field. If there are multiple email addresses, I can separate them by semi-colons.
Finally, if I want, I can post the notification to a webhook if I know its endpoint. I’m only going to use email addresses in my situation though. I’ll click “OK”, then “Create” to create the web test. Once we know that its been successfully created, its time to test it out.
To test this out, I’m actually going to wait at least an hour. This is just so that I can come back to the “Web tests” blade and see that the web tests have been running. But, I want to test a failure. So, I’m going to show two windows on my screen at once. In the left window, I have the Azure Portal. In the right window, I have my browser open to the ping page. I’ll refresh the page in the right window so you can see that its still running. Now, I’ll go to the App Service powering this site in the left browser window.
Once in the App Service’s blade, I’m going to click the stop button. I’ll then confirm that I want to stop the App Service. I’ll then refresh the “Ping” page in the right browser window. You’ll notice that we see an error. At this point, I can wait for an email to come in. Usually within one minute I’ll receive an email. Here it is.
That email looks like the one I’m showing you on the screen. So, now we know our web test works. For that reason, I’m going to turn my App Service back on. At this point, after a minute or so, I’ll get another email that confirms that the web test is once again running successfully. Here’s that email. It looks like this.
That’s how you monitor your web site availability with application insights. The transcript for this video can be found here. If you’d like to check out some of the courses I’ve created, please visit here. I am also available on these social networks. Finally, if this video was helpful, please click the “thumbs up” below. This lets me know if I’m adding value to your day.
Thanks for watching.