Uptime checks

Last updated:

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.

To make it more concrete, here is the fictitious example that illustrates a short downtime:

timestamp uptime status server location
Up and running Location #1
Up and running Location #2
Down (unconfirmed) Location #3
Down Location #1
Down Location #2
Down Location #3
Down Location #4
Down Location #2
Down Location #3
Down Location #4
Down Location #1
Down Location #4
Down Location #3
Down Location #1
Down (first notifications sent) Location #2
Up and running Location #1
Up and running Location #2
Up and running Location #4
Up and running Location #3
Up and running (website back up notifications sent) Location #4

The start time for this downtime will be (time of the first incident), and the end time will be (time of the last incident).

Note that you can tweak when to send the first notification in each website's settings. This is useful when some of your websites usually go down for short periods, and you only want to be notified when longer downtimes occur.

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, workers will try to record HTTP response headers, response body, connection log, and IP address on every request. When the downtime is confirmed, workers will attempt to infer the potential reason for the downtime so that you don't start with a blank slate while troubleshooting the incident.

Pausing checks

If you'd like to pause uptime 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.

Notifications

By default, you will receive the first notification after 3 minutes of downtime. In addition to that, you will keep getting reminder notifications every 30 minutes as long as downtime is active. You can change those thresholds in each website's settings. You will also receive the final notification when your website goes back up.

As of today, notifications can be sent via email, SMS, or Slack. Refer to notification docs to learn more about how to configure each channel.

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 (for example, http://3.229.127.34 or http://[2a05:d01c:db:c101:9e5c:2aed:c051:76f1]). Both IPv4 and IPv6 addresses are supported.

To preserve the integrity of the data, you won't be able to modify the URL after creating the check.

HTTP methods

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

Request body

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 4xx responses.

HTTP request headers

You can specify up to 10 HTTP headers per website that should be sent with each request. To preserve the integrity of the request, you won't be able to set some headers, namely:

  • Accept-Encoding
  • Cache-Control
  • Connection
  • Host
  • Keep-Alive
  • Pragma
  • Proxy-Connection
  • Referer
  • TE
  • Transfer-Encoding
  • Upgrade
  • User-Agent

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.

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). This check can only be performed if it is possible to reach your website and HTTP response code is 2xx.

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.

Workers support brotli, gzip, and deflate compression algorithms.