Introduction

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

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

Research conducted by Akamai in 2015 shows that response times higher than 2-3 seconds are likely to cause the visitor to abandon the site.

SSL

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.