SharePoint Site Connectivity Test

If there is something that can mar user experience with SharePoint Online, then it is the frequent unavailability and consistently poor responsiveness of the sites hosted on SharePoint Online. This is why, administrators prioritize site accessibility-related issues above all else, and strive to capture and fix such issues before users notice and complain. This is where the SharePoint Site Connectivity test comes in handy!

For each site that is configured for monitoring, this test, at frequent intervals, emulates an HTTP/S connection to that site and reports on the availability and responsiveness of that site. Besides sending out pre-emptive alerts to administrators regarding the unavailability/slowness of a site, the test also reports the response code returned by the site for the emulated request. In the event that the site is unavailable, the response code will point administrators to the probable reason for the non-availability. Also, a web site can be considered truly 'available', only if the page that is hit displays 'valid' content - i.e., the content that it is supposed to display during normal operations, and not junk data or error messages. The Site Connectivity test also reports the validity of the content of the target site, and thus paints a 'true' picture of availability.

Target of the test : Microsoft SharePoint Online

Agent deploying the test : A remote agent

Outputs of the test : One set of results for each SITE URL monitored

First-level descriptor: Display Name of a site, in the SITE URL configuration

Configurable parameters for the test

Parameters Description

Test period

How often should the test be executed


The host for which the test is to be configured. By default, this is

O365 User Name, O365 Password, and Confirm Password


For execution, this test requires the privileges of an O365 user who has been assigned theService support admin and SharePoint admin roles and is vested with the View-Only Audit Logs permission. Configure the credentials of such a user against O365 User Name and O365 Password text boxes. Confirm the password by retyping it in the Confirm Password text box.

While you can use the credentials of any existing O365 user with the aforesaid privileges, it is recommended that you create a special user for monitoring purposes using the Office 365 portal and use the credentials of that user here. To know how to create a new user using the Office 365 portal and assign the required privileges to that user, refer to Creating a New User in the Office 365 Portal under Microsoft Office 365 .

O365 Domain


To have a personalized business email address, team site address, or even an account name, you set up a domain name with Office 365. A domain is a unique name that appears after the @ sign in email addresses, and after www. in web addresses. It typically takes the form of your organization's name and a standard Internet suffix, such as or Office 365 gives you an initial domain name to use. By default, this will be of the format: * - eg., To enable this test to pull metrics, you need to configure the test with the name of this initial domain. Therefore, configure the O365 Domain parameter with the name of the initial domain. To know what is your Office 365 initial domain name, do the following:

  1. Log on to the Microsoft Office 365 Online Portal using an administrative account.
  2. Under Management, click on Domains.
  3. The initial domain should be listed with a name ending with

Domain, Domain User Name, Domain Password, and Confirm Password

These parameters are applicable only if the eG agent needs to communicate with the Office 365 portal via a Proxy server.

In this case, in the Domain text box, specify the name of the Windows domain to which the eG agent host belongs. In the Domain User Name text box, mention the name of a valid domain user with login rights to the eG agent host. Provide the password of that user in the Domain Password text box and confirm that password by retyping it in the Confirm Password text box.

On the other hand, if the eG agent is not behind a Proxy server, then you need not disturb the default setting of these parameters. By default, these parameters are set to none.

Proxy Host, Proxy Port, Proxy User Name, and Proxy Password

These parameters are applicable only if the eG agent needs to communicate with the Office 365 portal via a Proxy server.

In this case, provide the IP/host name and port number of the Proxy server that the eG agent should use in the Proxy Host and Proxy Port parameters, respectively.

If the Proxy server requires authentication, then specify the credentials of a valid Proxy user against the Proxy User Name and Proxy Password text boxes. Confirm that password by retyping it in the Confirm Password text box. If the Proxy server does not require authentication, then specify none against the Proxy User Name, Proxy Password, and Confirm Password text boxes.

On the other hand, if the eG agent is not behind a Proxy server, then you need not disturb the default setting of any of the Proxy-related parameters. By default, these parameters are set to none.

Site URLs

Provide a comma-separated list of sites to be monitored. The format of your specification should be as follows: <DisplayName>:<Site_URL>. For example, your specification can be: abc:,zanax:

Note that the <DisplayName> specifications will be the descriptors of this test.

Validity String

For each Site URL configured, specify a validity string. This means that if a comma-separated list of Site URLs has been configured, then you will also have to configure a comma-separated list of validity strings.


  • The number of validity strings configured should be the same as the number of Site URLs configured for monitoring;
  • The validity strings should be specified in the same order as that of the Site URLs. In other words, in a comma-separated list of validity strings, the first validity string will correspond to the first site URL, the second validity string will correspond to the second site URL, and so on.
  • If you do not wish to configure a validity string for any site URL, then make sure that you set the validity string for that site URL as none.

Typically, this test checks whether the contents of a Site URL contains the validity string that corresponds to that URL. If the searched string is found in a URL's contents, then the test reports that the contents are valid.

Measurements made by the test
Measurement Description Measurement Unit Interpretation

Web availability

This measurement indicates whether this site was able to respond successfully to the query made by the test.


If this measure reports the value 100%, it implies that the site is accessible. The value 0 on the other hand indicates that the site is nopt accessible over HTTP/S.

Availability failures could be caused by several factors such as the web site being down, the web site being misconfigured, a network failure, etc. Temporary unavailability may also occur if the web site is overloaded. Availability is determined based on the response code returned by the site. A response code between 200 to 300 indicates that the site is available.

Response code

The response code returned by this site for the simulated request


A value between 200 and 300 indicates a good response. A 4xx value indicates a problem with the requested content (eg., page not found). A 5xx value indicates a server error.

Response time

This measurement indicates the time taken by this site to respond to the requests it receives.


Response time being high denotes a problem. Poor response times may be due to the site being overloaded or misconfigured. If the URL accessed involves the generation of dynamic content, backend problems (e.g., an overload at the application server or a database failure) can also result in an increase in response time.

Content validity

This measure validates whether this site was successful in executing the request made to it.


A value of 100% indicates that the content returned by the test is valid. A value of 0% indicates that the content may not be valid. This capability for content validation is especially important for multi-tier web applications. For example, a user may not be able to login to the web site but the site may reply back with a valid HTML page where in the error message, say, "Invalid Login" is reported. In this case, the availability will be 100 % (since we got a valid HTML response). If the test is configured such that the content parameter should include the string "About Us", in the above scenario content validity would have a value 0.

Content length

The size of the content returned by this site.


Typically the content length returned by a specific URL should be the same across time. Any change in this metric may indicate the need for further investigation.