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

Gazer is the HTTP monitoring component of WebGazer. It periodically checks the status of a URL. You can use gazers to monitor;

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

Success criteria


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 gazer'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.


If the gazer'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 plans Basic or higher.

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 gazer'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.