Diagnose availability test failures in Application Insights
This article discusses how to access the Application Insights troubleshooting report. This report enables you to easily diagnose common problems that cause your availability tests to fail.
Note
Many webtest-related issues are caused by stale or outdated DNS records. As a first troubleshooting step, we recommend that you flush the DNS cache on your local computer.
In Windows, run the ipconfig /flushdns command. For other operating systems, the equivalent command is different.
View the Application Insights troubleshooting report
To view the Application Insights troubleshooting report, follow these steps:
On the Availability page of your Application Insights resource, locate the Select availability test heading. Under that heading, either select the name of an individual availability test or select Overall to see the combined results of all the test names.
Take one of the following actions:
In the Availability results pane for the test name, locate the Drill into heading, and then select the Failed button. Then, in the Click on a sample availability test pane, select a test run (that represents a particular region and time) for the test name.
In the Availability graph, select the Scatter Plot view, and then select one of the points on the scatter plot graph.
In the End-to-end transaction details page, select an event, and then select anywhere within the Availability Properties table to open the Troubleshooting Report Summary section.
In the Troubleshooting Report Summary section, locate the relevant error name, and then select the Go to step link for that item to view the Troubleshooting Report details.
Use the troubleshooting report to determine possible causes of failure
The following table lists the steps, error messages, and possible causes that you might find in the report.
| Step | Error message | Possible cause |
|---|---|---|
| Connection reuse | No specific error message is returned for this issue. | The web test step is dependent on a previously established connection. Therefore, no DNS, connection or SSL step is required. |
| DNS resolution | The remote name could not be resolved: "<your-URL>" | The DNS resolution process fails. This most likely occurred because of misconfigured DNS records or temporary DNS server failures. |
| Connection establishment | A connection attempt failed because the connected party did not properly respond after a period of time. | Your server doesn't respond to the HTTP request. A common cause is that a firewall on your server is blocking our test agents. To test within an Azure Virtual Network, add the Availability service tag to your environment. |
| TLS transport | The client and server cannot communicate because they do not possess a common algorithm. | Only TLS 1.0, 1.1, and 1.2 are supported. SSL isn't supported. This step doesn't validate SSL certificates, it only establishes a secure connection. This step appears only if an error occurs. |
| Receiving response header | Unable to read data from the transport connection. The connection was closed. | Your server commits a protocol error in the response header. For example, your server closes the connection if the response isn't fully read. |
| Receiving response body | Unable to read data from the transport connection: The connection was closed. | Your server commits a protocol error in the response body. For example, your server closes the connection if the response isn't fully read, or the chunk size is wrong in the chunked response body. |
| Redirect limit validation | This webpage has too many redirects. This loop will be terminated here since this request exceeded the limit for auto redirects. | Redirects are limited to 10 per test. |
| Status code validation | 200 - OK does not match the expected status 400 - BadRequest. |
The returned status code is counted as a success. The "200" code indicates that a normal web page was returned. |
| Content validation | The required text '<expected-response-text>' did not appear in the response. | The string isn't an exact case-sensitive match in the response. For example, the string "Welcome!" must be a plain string, without wildcard characters (such as an asterisk). If your page content changes, you might have to update the string. Content match supports only English characters. Content match also fails if the response body is more than 1,000,000 bytes long. After the client reads that number of bytes, it stops reading the response body and drops the connection. Because of this behavior, the server experiences a |
| Missing test results in Azure portal | No specific error message is returned for this issue. Test results are missing in the Azure portal when viewing the end-to-end transaction details of an availability test. | Non-UTF8 characters aren't supported for viewing web test results. Ensure there are no non-UTF8 characters in the response from the endpoint that's called using the availability test. |
| Unsupported URL | This URL is not supported | Availability tests only allow communicating over publicly available IP addresses and hostnames. This error might occur when you try to communicate with an internal IP address that isn't routable via the public internet. To resolve this error, ensure only public IP addresses are defined in your web test and that any DNS lookups your web test depends on return only valid publicly routable IP addresses. |
Note
If the connection reuse step is present, then the following steps won't be present:
- DNS resolution
- Connection establishment
- TLS transport
Next steps
Use TrackAvailability to submit custom availability tests.
Learn about URL ping tests.
Contact us for help
If you have questions or need help, create a support request, or ask Azure community support. You can also submit product feedback to Azure feedback community.