Control Panel Configuration

Select HTTP from the monitoring catalog:

The HTTP check has multiple check types that fulfill different services.

HTTP port configuration

HTTP port checks are much lighter and are only checking to see if a specific port is available.

HTTP HEAD configuration

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.

HTTP check configuration

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 you would create a server with a fully qualified domain name (FQDN) of 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 Matching 

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:

In Katalon:

Select Browser Synthetic check from the metric list, then enter the source code under Check Source > Selenium Source

Once entered, you can select Save and it will run every 10 minutes.

HTTP JavaScript synthetic check configuration

JavaScript synthetic checks allows you to perform tests that the browser synthetic (multistep) checks do not support. Use JavaScript synthetic checks for complex actions, such as: 

  • 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

Here are some specific examples of what you can test using JavaScript synthetic checks:

  • 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
Information Note: JavaScript synthetic checks operate in a restricted JavaScript sandbox environment with limited support for libraries. For more information, contact

This article provides information on how to set up an environment for JavaScript synthetic checks. The article also inludes a JavaScript test template, a sample test, and more information and resources to help you create your own JavaScript synthetic checks. 

To create a JavaScript synthetic check:

  1. Make sure that you already configured a JavaScript synthetic check environment.   
  2. Select JavaScript Synthetic when creating an HTTP metric. 
  3. Under the JavaScript Source module, paste your JavaScript test code.
  4. Configure the metric as usual. 

  1. Select Save.
    If a check fails, an incident will be created depending on how you configure the metric's thresholds and alert timeline.
Information Note: JavaScript checks will timeout if an individual steps takes more than 30 seconds, or if the whole test exceeds 2 minutes.