WebART Checks

(For a short video about this topic, click here.)

A Web Application Response Time (WebART) check monitors the availability and performance of a single, web-based application. These checks are useful for monitoring the efficiency and usability of commonly trafficked paths that might be taken by that application’s users.

WebART checks are managed on the Web Application Administration pages.

A WebART check loads its specified web application (typically an html web page) and then follows a sequence of steps (called “synthetic checks,” see below) to “use” that application in a way representative of a typical user; optionally interacting with that application by filling out a form and then validating that another web page returned by that form contains a specific string (for example, to determine a successful login attempt by searching for a welcome message). In this way, WebART checks not only monitor the availability of your web applications, but provide performance insights into the user experience for those applications.

WebART and Google

A WebART check will always ignore any Google Analytics code it finds in the target pages during testing.

WebART checks are the most complex of the check types and, in some ways, are actually more similar to a managed device than a type of check—in that they are discreet, manageable objects that get checked for availability and are polled for multiple types of statistical data. The also get their own version of the Device Dashboard called the Application Performance dashboard.

Since WebART checks are not associated with any specific device, they don’t appear in any device-based lists, such as the Devices dashboard. Instead, they appear in application-based lists such as the Application Monitoring dashboard, along with OmniCenter’s single email application check.

The Application Performance dashboard shows detailed information about the current status of a WebART check.

WebART checks report on the basic availability of their target application. But, they also report on and record several performance metrics (any of which can have a threshold check configured for it, just like a device).

Each WebART check can be configured to access their target web application either locally (from the OmniCenter install location) or remotely (by selecting from a variety of Netreo cloud reflectors located around the world). Using a remote reflector is a good way to get an idea of how your application is performing for users in that region.

The following remote reflectors are available for WebART checks:

  • AP – Seoul
  • AU – Sydney
  • UK – London
  • EU – Frankfurt
  • US – East Coast
  • US – West Coast

When a WebART check is executed, the first thing that happens is that the check’s built-in synthetic browser attempts to load the application (this process performs the availability check). If the application is unresponsive or returns an error code, the check stops and an alarm is generated (the timeout for a WebART check is 10 seconds and cannot be changed). If the application responds properly, the various synthetic check steps are carried out and their response times are measured and recorded.

The total load time for an application does include any associated images and javascript. However, a WebART check will not actually execute any Java or Flash objects if they are present (for security reasons).

For remote (as opposed to local) WebART checks, response times are measured from the selected cloud reflector to the target and back, and exclude the time it takes for OmniCenter to communicate with the reflector—thus ensuring the most accurate measurement possible.

Each WebART check includes a built-in availability check (configured like a service check) and a threshold check for the application total load time statistic. Additional threshold checks can be added as desired. The following additional statistics are available for monitoring on WebART checks:

  • DNS, TCP and HTTP times for the first synthetic check step.
  • HTTP times for any additional synthetic check steps after the first.

OmniCenter’s list of WebART checks are run sequentially in a batch (typically, every five minutes). This means that if you have a large number of WebART checks, and one or more bad checks are hanging or waiting to time-out, they may cause the remainder of the checks to fail to execute at all. This will cause any performance graphs for those checks to show no data and any application status indicators for those checks will remain blank. So, be sure to maintain your WebART checks and either fix bad checks or delete them.

The User-Agent request header used by the WebART check’s synthetic browser to load web pages is:

Mozilla/5.0 (Compatible; OmniCenter by Netreo) AppleWebKit/600.6.2 (KHTML, like Gecko) Version/8.0.6 Safari/600.6.2

Synthetic Checks

Synthetic checks are steps in the simulated path of a user. All WebART checks require at least one synthetic check in order for it to have any meaningful functionality. WebART synthetic checks are added and configured to simulate a given path that an end-user might take through your application. This path is then monitored for performance, measuring such aspects as functionality, availability and response time. A WebART check without any synthetic checks will never become active or report anything. Synthetic checks are executed in the order in which they are added, and cannot be reordered. So, it’s best to plan your synthetic checks carefully before beginning.


The first synthetic check step in a WebART check offers the option of filling out a web form. But, only the first step offers that option. Adding the first synthetic check step to a WebART check begins an interactive wizard process that will immediately connect to a user-supplied URL and search that URL for any forms that can be filled out. If any forms are available, OmniCenter will download them and allow you to select which form (if any) to fill out for the first step. A dialog is then provided where you can specify the exact values for the WebART check to use to fill out that form. The web page that results from filling out and submitting the form can then be validated as correct by searching for strings within the page using a search expression or exact text match (see below). Additional steps can be added to the WebART check (to be executed in sequence) by adding additional synthetic check steps to simulate navigation of the application (for example, navigating a website). This path will then be replicated every time the WebART check runs. If you make your first synthetic check step a login step, you will already be logged in if you do decide to add additional steps; such as following additional links or activating other page functions to see if they are performing as desired. It is important to note that OmniCenter will only download forms for the first synthetic check step. This means that OmniCenter cannot log in to sites requiring two-step authentication (i.e. where the username and password are submitted using different forms on different pages).

WebART alert notifications and synthetic checks

Alert notifications sent out for a failed WebART check include a field called “Additional Information” which provides the name of a synthetic check, seemingly implying that this is the point at which the check failed. But, this is not the case. Typically, the synthetic check listed is the last synthetic check to succeed before the failure—although this is not guaranteed to be the case. The information provided in this field merely provides a potential jumping-off point to begin troubleshooting the cause of the failure. It is not intended to be seen as the exact point of failure.

To create a WebART check, see How to Create a WebART Check.

Updated on December 11, 2019

Was this article helpful?

Need Support?
Can’t find the answer you’re looking for? Don’t worry we’re here to help!
Contact Support

Leave a Reply