Come join our live training webinar every other Wednesday at 11am PST and hear LogicMonitor experts explain best practices and answer common questions. We understand these are uncertain times, and we are here to help!
Web Checks periodically make HTTP GET, HEAD or POST requests to one or more URLs. LogicMonitor supports two types of Web Checks:
The processes for creating Standard Web Checks and Internal Web Checks are largely identical. This support article covers the creation of both types of checks.
Note: For information on the type of data that is monitored for your configured Web Checks and how that data is organized on the Websites page, see What Is Website Monitoring?.
To create a new Web Check, select Websites > Add > Web Check or Websites > Add > Internal Web Check, depending upon whether you want the tests to be performed from locations external or internal to your network.
Note: Web Checks can also be added using LogicMonitor’s API. For more information, see Using LogicMonitor’s REST API.
In the Name field, enter a descriptive name for the Web Check.
In the Description field, describe the scope and purpose of the Web Check.
From the Website Group dropdown menu, select the group the Web Check should belong to from the list of existing groups. By default, the root (top-level) website group is selected.
From the Default Root URL dropdown menu, select “http://” or “https://” depending on your web server settings. Enter the website domain to which your Web Check request will be sent.
For every Web Check, you must configure at least one URL path, along with the corresponding request and response settings for that URL path. Additional URL paths can be added, but only after the configurations for the first URL path have been saved.
In the Step One URL Path field, enter the first path that should be tested for your website. Enter the path relative to the website domain (e.g., “/folder/page.htm”).
From the Request area of the dialog, notice the following difference between Standard Web Checks and Internal Web Checks:
Note: Script settings are not discussed in this support article. For more information on using a Groovy script to execute an Internal Web Check, see Executing Internal Web Checks via Groovy Scripts.
For Web Checks that are not using a Groovy script, there are several HTTP request settings that must be completed for the URL.
Note: If you are testing a path that uses form-based authentication, there are browser tools you can use to identify what information you need to include in your request. For more information on using these tools, see Web Checks with Form-Based Authentication.
For the HTTP Version field, select the version of HTTP that should be used to make the request. The version you select is based on your website’s settings.
Note: You can determine this setting in the response headers using the Linux/Unix cURL command (e.g. curl –head help.logicmonitor.com).
For the Method field, select the HTTP method that should be used to make the request: GET, HEAD, or POST.
If you select the POST option, additional configurations display that allow you to specify the data to be included in request payload. In addition, the Formatted Data option allows you to specify how the data should be formatted.
Note: As discussed in Web Checks with Form-Based Authentication, there are browser tools you can use to identify what information you will need to include in your request and what format it should be in.
If the Follow redirect option is selected, the HTTP request will follow any redirects configured for the URL.
If the Wait for all page elements to load option is selected, the HTTP request will wait for all page elements (e.g., headings, paragraphs, images) to load before checking the response.
For requests that are going to a page that requires either HTTP Basic authentication or NT LAN Manager (NTLM) authentication, select the Authentication Required checkbox to have LogicMonitor construct the authentication headers for you. Additional configurations display that allow you to specify the type of authentication and the authentication credentials that will be used in the HTTP request.
Note: If the website uses form-based authentication, you can add steps to the Web Check that POST the username and password values. For more information, see Web Checks with Form-Based Authentication.
From the Auth type dropdown, select the type of authentication used by the page:
In the Username and Password, enter your authentication credentials. If using NTLM authorization, you are prompted to enter a domain as well.
In the header table, click the + button to add any header key-value pairs that should be included in the HTTP request.
The Response area also features a Groovy scripting option for Internal Web Checks only.
For Web Checks that are not using a Groovy script, there are several HTTP response settings that must be completed for the URL.
From the HTTP Response Format dropdown, select a format for the response to the HTTP request. Once selected, some of the fields on the page are dynamically updated to allow you to specify format-specific criteria that should be included in (or absent from) the response. If relying on the presence of a string, note that the entry is case-sensitive.
In the Expected status code response field, enter the expected HTTP status code(s) that will be included in the response. Enter only integers. Multiple status codes should be separated by commas. If no status is specified, a 200/OK response is expected.
Note: If you choose “XML” as the response format, it’s important to note that Xpath processing does not support regular expressions. In order to find string matches in the page’s returned XML, you will need to use the contains query, as shown in the following screenshot. This query returns TRUE if the string is present. A useful tool for testing Xpath queries can be found at freeformatter.com.
When you add a new Web Check, at least one URL path (called the Step One URL Path), must be specified, along with its corresponding request and response settings. However, multiple steps can be added to the same Web Check in order to support more complicated checks that require a series of URL requests and responses in order to verify that a website is in full working order.
Additional steps are added from the Steps tab after the Web Check is saved.
Click the Add Step button and enter a path (either relative to the root URL previously established for the Web Check or independent from) and a description for this additional step into the Add a Step dialog. Then, proceed to configure request and response settings as outlined in this support article.
Each step you add is saved individually and available for management and testing from the Steps tab. For more information, see Testing Web Check Steps.
In the Checkpoints area, specify the locations from which Web Checks should be sent. The types of locations that are available here vary depending upon whether you are adding a Standard Web Check or an Internal Web Check.
Note: If your Web Check consists of multiple steps, the checkpoints configured here apply to all of these steps.
Note: If you have default checkpoints established and want to use or build on those, leave the use default Website settings checkbox selected. For more information, see Website Default Settings.
If you are adding a Standard Web Check, there are five geographically dispersed checkpoints, hosted by LogicMonitor, from which the check can be sent.
Click the Test button to verify that the selected locations can successfully reach your website.
If you are adding an Internal Web Check, you will need to specify the Collectors that will be sending the checks. Click the + button to add Collectors to the table.
Note: Your user account must have Collector view permissions in order for you to be able to view and select Collectors from this area of the dialog. For more information, see Roles.
In the Alert Triggering section, you must specify the conditions that must be met in order for a website alert to be triggered, as well as the severity of the resulting alerts.
Note: If your Web Check consists of multiple steps, the alert triggers configured here apply to all of these steps.
Note: If you have default alert triggering settings established and want to use or build on those, leave the use default Website settings option selected. For more information, see Website Default Settings.
From the Run this Website Check every X minutes dropdown menu, select how often the designated checkpoints should check the website. You can choose from frequencies that range from once a minute to once every 10 minutes.
In the Total download time must be less than X milliseconds field, specify how many milliseconds in which the website must load.
From the After X failed checks dropdown menu, select the number of consecutive checks that must fail in order for an alert to be triggered.
This field gives you the ability to designate a different alert severity should checks from multiple checkpoints fail, as compared to the failure of just one checkpoint. For example, you could specify that if all checkpoints report failure for three consecutive checks, an alert with the severity level of critical will be triggered.
This field gives you the ability to designate a different alert severity should checks from only one checkpoint fail, as compared to the failure of multiple checkpoints. For example, you could specify that a failure at a single checkpoint location for three consecutive checks will trigger an alert with the severity level of warning. In addition, using individual checkpoint alerts allows for greater request/response detail in the alert messages, since it is not simply a summarization of all checkpoints.
In the SSL Alerts area of the Alert Triggering section, you can configure LogicMonitor to alert you when SSL certificate issues are encountered during a Web Check.
When selected, the Alert on SSL Errors option triggers alerts if a certificate experiences any of the following issues:
If any of the above issues are encountered and the Halt on SSL errors option is also selected, the Web Check will stop and send the alert without continuing.
You can also choose to get proactive notification of certificate expiration. Select the Alert on Certificate Expiration option and enter the number of days in advance of expiration in which you would like to receive a corresponding alert for each severity level.
Once you have configured the conditions that must be met in order for a website alert to be triggered, you can use the Test Routing hyperlinks to see what alert rule will match each condition, along with the escalation chain associated with that alert rule.
From the test display, the Test Now button can be used to send a synthetic test notification to the first stage in the specified escalation chain.
Note: Synthetic alert messages use LogicMonitor’s default global alert message templates. Any customizations, such as addition of alert tokens, are ignored during testing. You must use a live alert to test customizations. For more information, see Alert Messages.
For more information on alert rules and their associated escalation chains, see Alert Rules.
Properties can be added to your Web Checks to facilitate organization, customize alert message templates, set authentication credentials, and more. For more information, see Website Properties.
In This Article
