External Web Checks using LM Uptime

External Web Checks are designed to simulate the experience of real users when attempting to access your website. This provides a more accurate picture of availability and performance from your perspective, helping you identify and respond to issues that internal monitoring might not detect.

Requirements for Creating External Web Checks using LM Uptime

To create external web checks, you need the following:

• LM Uptime license edition
• A user with “Manage” permission for Resources. For more information, see Resource Role Permissions.

Creating External Web Checks using LM Uptime

1. In LogicMonitor, navigate to Resource Tree >  > select Web Check.
2. Select the Basic tab and do the following:
   1. In the Name field, enter a name for the Web Check.
   2. In the Description field, describe the scope and purpose of the Web Check.
   3. In the Where should it be placed? section, in the Groups table, select from the existing group list where the Web Check should belong. By default, the root (top-level) website group is selected.
   4. In the Properties table, add the relevant properties. For example, add http.port with the value 80.
      
3. Select Settings tab and do the following:
   Note: External Web Checks only support requests that are built based on pre-defined request settings. 
   1. In the Default Root URL section, select http://or https:// protocol depending on your web server settings, and enter the website domain to which your Web Check request must be sent.
   2. In the Step One URL Path field, enter the first path that you want to test for your website. Enter the path relative to the website domain (For example, /folder/page.htm).
   3. In the HTTP Version field in Request, select the version of HTTP that must be used to make the request. The version you select is based on the settings of your website.
      Note: You can determine this setting in the response headers using the Linux or Unix cURL command (For example, curl –head help.logicmonitor.com).
   4. In the Method field in Request, select the HTTP method (GET, HEAD, or POST) for making the request.
      If you select the POST option, additional configurations display that enable you to specify the data to be included in the request payload. In addition, the Formatted Data option allows you to specify how the data must be formatted.
   5. Toggle on the Follow Redirect switch to allow the HTTP request to follow any redirects configured for the URL.
      By default, this toggle is on. 
   6. (Optional) Toggle on the Wait for all page elements to load switch to allow the HTTP request to wait for all page elements (For example, headings, paragraphs, images) to load before checking the response.
   7. (Optional) Toggle on the Authentication required switch for requests that go to a page requiring either HTTP Basic authentication or NT LAN Manager (NTLM) authentication. In addition, configurations display that enable you to specify the type of authentication and the authentication credentials that are used in the HTTP request. 
      
   8. Select the type of authentication (Basic or NTLM) used by the page from the Auth type dropdown menu.
      Basic—HTTP Basic authentication passes the username and password as fields in an HTTP header.
      NTML—NT LAN Manager (NTLM) is a suite of Microsoft security protocols that provides authentication, integrity, and confidentiality to users. This authentication type is usually recognizable by a grey dialog that prompts you for a username and password.
   9. In the Username and Password fields, enter your authentication credentials. If using NTLM authorization, you are prompted to enter a domain as well.
   10. In the HTTP Header table, add any header key-value pairs that should be included in the HTTP request.
   11. Select a format for the response to the HTTP request from the HTTP Response Format dropdown menu. After selected, some of the fields on the page are dynamically updated enabling you to specify format-specific criteria that should be included in (or absent from) the response.
       “Plain text/ string” is the default value. 
       Note:
       • If relying on the presence of a string, entries are case-sensitive.
       •  If you select the XML option, additional configuration settings display, and Xpath processing does not support regular expressions. In order to find string matches in the returned XML page, you need to use the contains query, as displayed in the following image. This query returns true if the string is present. For more information on a useful tool for testing Xpath queries, see freeformatter.com.
         
   12. In the Expected status code response field, enter the expected HTTP status codes that are included in the response. Enter only integers. Commas must separate multiple status codes. If no status is specified, a 200/OK response is expected.
       Note: You can execute your web check using Groovy scripts. For more information, see Executing Web Checks using Groovy Scripts.
       
4. Select the Checkpoints tab, and select the checkpoint location.
   LogicMonitor hosts five geographically dispersed checkpoints, from which the check can be sent. All the checkpoint locations, along with the Use Default Website Settings toggle, are selected by default.

5. Select the Alert Triggering tab and do the following:
   Important: If you want to customize and not use the default settings, you need ‘Resources: Group Threshold’ permission. For more information, see Access Group Permissions.
   1. Toggle the Use Default Alert Settings switch to use the recommended default settings. 
   2. Select how often the designated checkpoints should check the website from the Time Interval to Run Web Check dropdown menu. 
   3. In the The total download time must be less than X milliseconds field, specify the number of milliseconds in which the website must load.
   4. Select the number of consecutive checks that must fail for an alert to be triggered from the After X failed checks dropdown menu. You can select the location and severity of multiple or one selected alert. 
   5. Toggle on the Alerts on SSL Errors switch to trigger alerts if a certificate experiences issues like unsupported algorithms, an untrusted or incomplete certificate chain, CName and HostName mismatch, or an expired certificate.
   6. (Optional) Toggle on the Halt on SSL Errors switch to stop the Web Check and send an alert accordingly if any issues are encountered.
   7. Toggle on the Alert on Certificate Expiration switch and enter the number of days in advance of expiration for which you would like to receive a corresponding alert for each severity level.
      
      For more information on the different scenarios on alert generation, see Website Data Alerting for LM Uptime.
6. (Optional) Select Test connections to verify that the selected locations can successfully reach your website.
   The Test Connection Results pane displays the status of the checkpoint locations. 
   
7. Select Save. 
   
   The external web check is added to the resources.