Docs
HTTP monitors

Introduction

Table of contents
  1. Success criteria
    1. Response
    2. SSL
    3. Status code
  2. Downtime verification

HTTP monitor periodically checks the status of a URL. You can use HTTP monitors to monitor;

  • websites,
  • API endpoints.
Please see here if you need help configuring the HTTP monitor's requests' HTTP method, headers, or body.

Success criteria

Response

For a check to be successful, of course, it must first complete the request-response cycle. WebGazer fires an HTTP request with the configured header and body parameters in the monitor's settings. A downtime is recorded if the server somehow fails to respond to the request. For example, DNS resolution failure, connection denial, or connection timeout causes a downtime.

The timeout limitation for the whole request is 10 seconds. This limitation is set considering the industry standards. If the server doesn't fully deliver the response in 10 seconds, it is considered a timeout, and a downtime is recorded.

SSL

If the HTTP monitor's URL's protocol is HTTPS, the server is expected to respond accordingly. If anything unexpected occurs in the SSL communication, it is recorded as a downtime.

SSL monitoring is available for subscription Basic or higher plans.

Status code

The response is evaluated according to the status code. Considering the Internet Engineering Task Force (IETF)'s successful response status code definition, the check is considered successful as long as the status code is 1xx or 2xx. If the response code is 4xx, it is considered unsuccessful, and a downtime is recorded.

If the server responds with a 3xx redirection header, that redirection is followed. Redirection count limit is 10. If there are more than 10 redirections, a downtime with the message "Too many redirects" is recorded.

Downtime verification

A momentary network connectivity hiccup between the WebGazer's servers and the HTTP monitor's server can cause connection failure and generate a false downtime alert. In order to prevent this, when a downtime is detected, it is verified by firing another immediate request. If the first request indeed failed due to a momentary issue, downtime is discarded, and the check is registered as successful.