Control Panel Configuration
Select HTTP from the monitoring catalog:
The HTTP check has multiple check types that fulfill different services.
HTTP port checks are much lighter and are only checking to see if a specific port is available.
While the HTTP Port check only tests if a port is reachable, the HTTP HEAD check tests if a HEAD request will return its appropriate response. A HEAD request is used to ask only for information about the page and not the whole page itself. This can be useful if you do not want to use up your servers' bandwidth or use unnecessary resources. If the HTTP HEAD check results in a 200 or a 300 status code, then the service is considered up, if it results in a 400 or a 500, then the service is considered down.
The HTTP check is a more thorough check. The HTTP check configuration allows you to specify the URI/path to the resource as well as check for specific content on a webpage. If the HTTP check results in a 200 or a 300 status code, then the service is considered up, if it results in a 400 or a 500, then the service is considered down.
Notice the additional tabs on the side of this configuration window. The Incident Alerts tab will let you select the Alert Timeline for this check.
Monitoring a specific endpoint
The HTTP Options tab, seen below, lets you add a specific path to check.
For example, if you wanted to monitor http://www.panopta.com/why-panopta/ you would create a server with a fully qualified domain name (FQDN) of www.panopta.com and set the Path field to /why-panopta/. This functionality works with both GET and POST requests. For GET requests, the path can contain additional parameters (i.e. /why-panopta/?source=web). For POST requests, additional key/value pairs can be set in the HTTP Parameters field.
Content matches can either be straightforward string matches or, for more complicated matching can be full regular expressions. Our infrastructure uses the Python regular expression module, see the Python docs for details on the exact syntax supported.
Content matching allows you to do a number of in-depth checks such as looking for error messages that might get included on a page. You can also use this functionality combined with the ability to perform HTTP POST operations to perform a login transaction to a web application, and make sure the login succeeds and returns the proper welcome message. This way, you can ensure both your application server and underlying database are working properly.
HTTP browser synthetic check configuration
Get the tools
Before you can add an HTTP browser synthetic (multistep) check to your Panopta account, you need to download the Katalon plugin for Chrome.
This plugin records and plays back user interactions with the browser. Use this to either create simple scripts or assist in exploratory testing.
We have a list of supported commands here.
Below is what the Katalon IDE plugin looks like, when opened:
Once you have the necessary plugin installed to record a browser synthetic check, open your browser, visit the site that is your test's starting point and start the plugin from the tools/extensions menu. Press the record button to start capturing your clicks and key presses.
The IDE will record all of your browsing actions until you tell it to stop by pressing the record button. The plugin is quite powerful and you can read more about them in Katalon Docs.
Once you're test session is complete, export the test as XML like so:
Once you've selected Browser Synthetic check from the metric list, you can enter the source code under the Selenium Source tab.
Once entered, you can select Save and it will run every 10 minutes.
Testing branching, looping, or more advanced control flow
Checking the response content in detail
Testing API endpoints
Creating sessions or generating tokens via a separate API call
Testing against non-HTTP/s endpoints
HTTP page load - Test the speed of specific page load operations
FTP test - Connect to an FTP server or site, then check if an FTP file transfer is successful
Zip test - Download a zip file, then verify its contents
Configure the metric as usual.
If a check fails, an incident will be created depending on how you configure the metric's thresholds and alert timeline.