Web Servers (HTTP, HTTPS) Sensor Types

The HTTP protocol (Hypertext Transfer Protocol) is most commonly used for the World Wide Web. Web browsers request web pages, graphics etc. from web servers using this protocol. With PRTG, you can monitor your web server's performance and availability.

Overview: HTTP Sensor Types

PRTG offers the following HTTP-based sensors to monitor web servers:

  • HTTP: Monitors a web server via the HTTP protocol. This is the easiest way to monitor if a website is reachable.
  • HTTP Advanced: Monitors a web server via the HTTP protocol with various advanced settings (e.g. to check the content of a web page or to use authentication or a proxy server).
  • HTTP Transaction: Monitors a web server using a set of URLs to monitor whether logins or shopping carts are working fine. You must supply a series of URLs (GET and/or POST requests) including the parameters to monitor a transaction.
  • HTTP Content: Monitors a return value provided by a HTTP request. This sensor requests a HTTP URL and then parses the returned result for a value in square brackets. This is mainly used in combination with scripts running on a server.
  • HTTP Full Web Page: Monitors the full download time of a webpage including images etc. (uses Internet Explorer to perform a full page download).

All sensors support HTTP and HTTPS.

Common Settings - HTTP Sensors

All HTTP sensors include basic sensor settings and these HTTP specific parameters:

  • Timeout: Time in seconds after which the request is aborted.
  • URL: The URL address of the web page to monitor (including the leading http://).
  • Request Method: The HTTP request mode to use (GET, POST, HEAD). GET requests the website directly, like browsing the web. If you want to monitor a URL for a POST form, you must select the POST method and enter the "Postdata". The HEAD method only requests the HTTP header from the server without the actual web page. Although this saves bandwidth since less data is transferred, it is not recommended because the measured request time is not the one experienced by your users and you might not be notified for slow results or timeouts.
  • Postdata: When using the POST request method, you can enter the data part here.
  • SSL Method: Relevant only when you're using HTTPS. If you are using a HTTPS URL and do not get a connection, please try with another SSL method.

For monitoring a simple web page, choose a simple "HTTP" sensor (for more advanced HTTP sensor types see below). Enter the URL (with http:// at the beginning) and keep the default request method selection GET.

Notes For HTTP Advanced Sensors

For general settings, please refer to "Common Settings - HTTP Sensors" (above). Using the HTTP Advanced sensor, you can optionally enter the following advanced settings (you can also leave any of them blank):

  • Content: Check "Monitor Changes" if you want to monitor any changes on the HTML page at the given URL. You can combine this setting with a "On Change" notification.
  • Response must include: If you enter a string here, the sensor will check if this string is part of the HTML page at the given URL. If so, the sensor status will be "OK".
  • Response must not include: If you enter a string here, the sensor will check if this string is not part of the HTML page at the given URL. If so, the sensor status will be "OK".
  • Limit download: To avoid exhaustive bandwidth usage, you can enter a kb limit for the data transferred per request. If you're using "Response must (not) include" options, only the part of the HTML page that is retrieved before reaching this download limit can be compared to your strings.
  • Authentication User/Password: If the website at the given URL needs authentication, you can enter the credentials here. Please also choose if the website uses a HTTP-Basic or a Windows Integrated (NTLM) authentication.
  • Proxy: If you want or need to access the given URL via a certain proxy, please enter the according information in these fields.

Notes For HTTP Transaction Sensors

This sensor is a special kind of HTTP Advanced Sensor. Instead of one single URL, it will check a series of URLs. For your HTTP Transaction Sensor, you can additionally configure the following settings:

  • Timeout: This HTTP specific setting defines the time in seconds after which the complete series of transactions is aborted.
  • Single URL Timeout: With this HTTP specific setting you can define a timeout in seconds after which a single transaction step is aborted. If this happens, the complete transaction series is set to "failure".
  • Use cookies: If cookies are needed for one of the transactions, check this option. If you are unsure, keep it checked.
  • Authentication User/Password: If the websites at the given URLs (below) need authentication, you can enter the credentials here. Please also choose if the websites use a HTTP-Basic or a Windows Integrated (NTLM) authentication.
  • Proxy: If you want or need to access the given URLs (below) via a certain proxy, please enter the according information in these fields.
  • Transaction URL #1 to #10: In these fields, you can enter up to 10 different URLs that will be requested in a series. If all of them succeed, the sensor will be in "UP" status. To help you find the right transaction URLs, you can use the Paessler URL Recorder to build a suitable URL list (see "Tools" at the end of this section).
  • Please see "Common Settings - HTTP Sensors" and "Notes For HTTP Advanced Sensors" for information about the other fields.

Notes for HTTP Content Sensors

This sensor requests a URL with a script and in the result received, it searches for a certain values. In the script's results which are sent back, each value must be enclosed in square brackets ("[ ]"). The sensor then handles each value in a separate channel (this can be one or more). You can use this with a script running on a web server. Usually, your script won't give back a whole HTML page, but rather one line containing result values. However, this sensor parses the results and uses anything written between square brackets as a value for one sensor channel. Numbers are expected as values. Anything else will lead to a zero ("0") value for the channel.

The most common use is to monitor a particular value inside a web server for validity. For example, if you have a script or CGI running on the web server that merely publishes the free disk space of the server's hard disk and the current processor usage (e.g. "[10222][12]" as result) you can actually monitor these values in two different channels of the sensor. Of course many other usage concepts are possible.

For general settings, please refer to "Common Settings - HTTP Sensors" (above). Additionally, you can enter the following settings:

  • Script Url: Enter the URL of the script you want to request the results from.
  • Value Type: Enter the type of values that your script sends back as results. You can choose between Integer and Float values.
  • Number of channels: Enter the number of values your script will send back. Remember: Each value must be enclosed in square brackets and each value is handled in an own sensor channel. So, if your script sends back e.g. "[10222][12]" as result, enter "2" for "Number of channels" to catch both values. If your script sends back less values than the number specified here, this will result in an error.
  • Content: Check "Monitor changes" to monitor any changes to the values your script sends back. In a second step, this can be combined with an "On Change" notification.

Notes for HTTP Full Web Page Sensor

This sensor uses Internet Explorer to load a full web page, including all images and page elements, and monitors the loading time. Please note that only the given URL is monitored and no links are followed.

What it Means When the HTTP Sensor is "Up"

The UP status of an HTTP sensor means that the web server delivers an HTTP result that is correct according to the HTTP protocol and that the URL is available. This means that the web server software is up and running but you do not know whether the results are correct, e.g. the webpage can contain error messages. So you don't know whether the CGI scripts etc. are working correctly or whether, for example, the database of the web server is ok. It is recommended to also check the content of a web page by using the HTTP Advanced Sensor, instead of the simple HTTP sensor, for added reliability.

What it Means When the HTTP Sensor is "Down"

There are numerous reasons for an HTTP sensor to fail. Besides normal connectivity problems, the most common problems are internal server errors (error codes 50x) and problems caused by an incorrect URL (error code 404, page not found).

Bandwidth Issues and Log File Analysis Issues

Important: Keep in mind that the HTTP sensor can create substantial bandwidth load since it is one of the sensors that transfers many bytes per requests (sometimes 1000 times more that a simple ping). So, choosing a URL that only provides a small HTML page in return is recommended if you have to pay for the bandwidth (either for your connection or for your web server). This is certainly not a major problem in most LANs and Intranets, but bandwidth usage should always be monitored. Requesting a 25 kb web page with an interval of one minute creates a traffic of 36 MB per day or more than one Gigabyte per month.

Also, keep in mind that the monitoring requests will show up in your web server log analysis (one month of monitoring with a one minute interval will create 43,200 requests). You should filter out the requests from PRTG when analyzing log files. Filtering can be done based on the IP address of the server running PRTG or by filtering requests from PRTG's browser agent:

Mozilla/5.0 (compatible; PRTG Network Monitor Vxxxx; Windows)


Paessler URL Recorder: Find out the URLs and the POSTDATA strings that a user sends to a web server while surfing a sequence of URLs - useful when setting up HTTP Transaction sensors.


Keywords: HTTP,HTTPS,Sensor,GET,POST,Proxy,Transaction