Uptime monitoring

Sequence and frequency

Uptime checks are performed approximately once every minute from one of the available locations worldwide. During downtimes, checks are performed from four different locations simultaneously. Downtime is only recorded if more than half of servers can confirm it. This drastically reduces the number of false positives.

Downtime

Website is considered down if any of the following cases apply:

• Failure to resolve the hostname
• Website took more than 15 seconds to connect
• Website redirected more than 5 times
• After exhausting all redirects, HTTP status code is other than 2xx
• At least one of response keywords were not found (when applicable)
• Untrusted certificates in the chain (including self-signed and expired)
• TLS handshake failure

If your website appears to be down, servers will try to record HTTP response headers, response body, connection log, and IP address on every request. When the downtime is confirmed, Hexadecimal will attempt to infer the potential reason for the downtime so that you don’t start with a blank slate while troubleshooting the incident.

Notifications

By default, you will receive the first notification after 3 minutes of downtime. In addition to that, you will keep getting reminder notifications during the duration of the downtime. You can choose when to receive the first notification in each website’s settings. This is useful if some of your websites usually go down for short periods, and you only want to be notified when longer downtimes occur.

You will receive the final notification when your website goes back up.

As of today, notifications can be sent via email, SMS, or Slack. Support for webhook notifications is planned.

URL

To ensure the accuracy of checks, always specify the URL in full, including the scheme (http or https). The easiest way to achieve that would be to copy the URL from your browser window instead of typing it by hand.

If you’d like to indicate a specific port number to connect to, append it to the end of the URL (for example, https://example.com:4242).

You can monitor endpoints using their IP addresses as well. Both IPv4 and IPv6 addresses are supported (for example, http://3.229.127.34 or http://[2a05:d01c:db:c101:9e5c:2aed:c051:76f1]).

To preserve the integrity of the data, you won’t be able to modify the URL.

Response keywords

For added assurance that your websites are up and running, you can set up to 10 unique keywords per website to be checked on every request. If one of those keywords doesn’t appear in the response body, your website will be marked as down.

You can also add negative keywords, which is the opposite of response keywords. You will be notified if one of these keywords is found in the response body.

Keywords are case sensitive, and whitespace is always preserved, empty strings being the exception (for example, " Duct tape and bubble gum " will be checked verbatim, while " " will be ignored). These checks are carried out if it is possible to reach your website, and the HTTP response code is 2xx.

Note that keywords won’t be found in Single Page Applications (SPA), where entire pages are rendered with JavaScript unless you do Server Side Rendering.

Request body

Apart from the GET request, which is the default, you can perform HEAD, POST, PUT, and PATCH requests as well.

With POST, PUT, and PATCH methods, you can additionally specify a payload to be sent on each request. By default, all payloads are sent with Content-Type: application/x-www-form-urlencoded header. If you want to send a response body as a JSON payload, set Content-Type header to application/json. Make sure that your payload is a valid JSON, otherwise, your endpoint might return HTTP 4xx response.

HTTP request headers

Hexadecimal sends the following HTTP headers with each request by default:

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Cache-Control: no-cache
Pragma: no-cache
User-Agent: Hexadecimal/1.0 (+https://tryhexadecimal.com/robot)

You can optionally specify up to 10 HTTP headers per website to be sent with each request. To preserve the integrity of the request and prevent abuse, you won’t be able to set some headers, namely:

• Accept-Encoding
• Host
• Referer
• User-Agent

Supported protocols

These protocols are supported out of the box:

• TLS 1.0, TLS 1.1, TLS 1.2, TLS 1.3
• HTTP/1.0, HTTP/1.1, HTTP/2
• IPv4, IPv6

If your endpoint doesn’t support the latest version of a particular protocol, the connection will automatically fall back to use the highest supported version.

HTTP/2 connections will be attempted only over TLS. Support for HTTP/3 is planned.

Brotli, gzip, and deflate compression algorithms are supported as well.

Pausing checks

If you’d like to pause uptime and certificate checks for any given website, you can do so in each website’s settings. This is useful when you want to take the website down for maintenance and don’t want checks running in that period.