URL (string) defines a URL to poll. You can also specify a URL schema ( http:// vs. https://) explicitly. The connection port is part of the URL, i.e. you should specify a non-default port explicitly in the URL parameter, for example: https://server.lan:9443. The default ports for http:// and https:// schemas are 80 and 443, respectively. Make sure the port is specified correctly.

Reverse monitor (OK when site is down) – if set, the monitor is in the OK state when the specified site cannot be connected to. IF the connection attempt is successful, the monitor is in the DOWN state. When checking the response code (using the HTTP Return Code Validation Section), a connection failure is processed as return code 200 in 1 ms.

HTTP Version: allows to choose HTTP version(s) used to establish connection. It is set to 1.1 by default.

Request Method: either GET or POST. For POST requests, the POST Data parameter provides the request body to send to the server. This is convenient if you test an HTML form or XML web service operation.

Custom headers checkbox defines whether to send custom HTTP headers, which you can specify in a common format, e.g. “X-Requested-With: XMLHttpRequest”.
You can also use variables like $HostDNS or Load from file pre-saved headers in text format.
Note: Usage of empty headers is allowed, e.g. “X-Data:”; they can end with colon, semicolon or neither of above (latter two will be automatically converted to format “Header-name:”). Thus multiline values with no colons will be treated as empty headers.

User Agent: allows choosing the “User-Agent” string to emulate one of the popular Web browsers. Use the Custom string option to specify any arbitrary string.

Ignore HTTPS (SSL) errors: allows to ignore various HTTPS (SSL) errors, e.g. self-signed or expired certificate. This option is turned on by default. Turn it off if you need a strict check.

Measurement: allows to configure resource timing measurements in the terms defined at corresponding specification. The diagram below shows the possible start / finish points of measurement in blue:

By default, when measuring performance, the time is taken from the start of connection (connectStart) to the end of receiving the response (responseEnd) – it does not include the time for redirection or the time for DNS lookup, since this time depends on the load of the system, caching, and other factors not directly related to the performance of your web site.
You can include this time in the overall measurement by setting the first switch to startTime if you like. Also you can measure the time before the first byte of the response is received (responseStart).

Proxy server parameters (type and URL) allow you to specify a proxy server to be used. By default, a direct connection is established. If a proxy server is selected (HTTP, SOCKS4 or SOCKS4) and requires authentication, you can specify Proxy Credentials.

Authentication – this monitor uses credentials to be supplied to an HTTP server if it requires authentication. The credentials are not sent if the server does not ask for them. The Basic, Digest, and NTLM authentication methods are supported. When the server does not accept the credentials, a message in the Logs pane indicates server HTTP response code 403 or 401 and the monitor enters the Down state, unless you mark these codes as acceptable on the monitor’s State Conditions tab, as described below. The credentials can be selected in the Credentials section below.

Note: the default parameters for an HTTP monitor (a direct GET request to the default page without content validation) will suffice in most cases.

Some web applications redirect the user to another page through HTML tags such as META HTTP-EQUIV=REFRESH. Unlike a web browser an HTTP monitor does not parse HTML and does not follow such links. It is recommended to indicate the actual page URL as it is shown in your browser after all possible redirections if you want to monitor such applications.

Note: you can specify accepted response codes and configure HTTP response validation on the monitor State conditions tab. You can list acceptable response codes (such as 403 or 404) by adding them to the comma-separated list of Accepted Response Codes. By default a HTTP monitor considers only 200 as an acceptable response code. Also, you can specify whether a particular string should be searched for in the HTTP response and whether it should or should not be present. No validation is the default.

This monitor is an advanced variant of the HTTP one and allows to test a Web application transaction as a sequence of requests. Use this monitor to check that both the HTTP server itself and Web application hosted there behave correctly.

A transaction consists of a sequence of HTTP requests that are sent to the server in succession. Using the built-in browser (WTM Recorder) a transaction can be easily recorded starting from the Login procedure. At each step, an HTTP response can be validated against the stored keyword to check if the transaction is on the right track.

The only parameter is a table of consequent HTTP requests that form a transaction. In order to modify monitor parameters and/or record a transaction press the Edit button. The Web Transaction Monitor configuration form will appear.

Port – is a port number; the default port for FTP and FTPES protocol is 21, for the SFTP protocol it is 22, FTPS uses port 990.

Secure Connection Type – allows you choose a suitable secure connection. There are options:

• Plain FTP
• SFTP (SSH FTP)
• FTPS (TLS used implicitly)
• FTPES (TLS negotiated explicitly by the client)
• FTPES, if available (default)

Ignore SSL certificate errors – allows to ignore various SSL certificate errors, e.g. self-signed or expired certificate. This option is turned off by default. Turn it on if you need a less strict check.

Authentication – this monitor uses credentials to be supplied to a FTP server if it requires authentication. The credentials can be selected in the Credentials section below.

Note that the SFTP protocol does not define response codes; however, SFTP authentication errors are mapped as response code 530; one can add it to the Accepted response codes list if necessary.

Note: you can specify accepted server response codes on the monitor State conditions tab. The Accepted Response Codes section is similar to the HTTP monitor’s one. By default an FTP monitor considers any code starting from 1, 2, or 3 as acceptable.

This monitor allows testing DNS servers. Use it to check that a DNS server works in general, or that it can resolve a given host name to an IP address, or that it can resolve mail servers for a given domain.

Use System DNS – specifies whether to use the default DNS server from the system settings or the monitor’s host as a DNS server.

Port (integer) – specifies on which port the DNS server is listening for connections. The default parameter is 53.

Request Type and Request Data – are used either to check that a DNS server works in general by executing an NS-type request for the “.” domain, or to get an IP address for the host name specified in Request Data, or to get the list of mail servers (MX-records) for the domain in Request Data, or to get the DNS Start of Authority (SOA) record serial number.

When a response from the DNS server contains several answers, each of them is validated independently.

Note: you can configure DNS server response validation on the monitor State conditions tab. Specify whether a DNS server response should be validated against a given set of strings or regular expressions in the DNS Response Validation section. You can check whether:

• some of the DNS server responses matches exactly any of the specified strings/expressions;
• none of the DNS server responses matches any of the specified strings/expressions;
• some of the DNS server responses contains any of the specified strings/expressions;
• none of the DNS server responses contains any of the specified strings/expressions.

By default, the validation is off.