How we detect downtime on your clients’ sites

To monitor the uptime of your clients’ websites, Glow integrates with UptimeRobot.

Here’s a quick rundown on how UptimeRobot detects downtime:

Uptime Robot sends HTTP requests every few minutes from its main engine (US-Dallas).

If no response is received, another request is sent from the same location (in case the previous one was just a hiccup).

If no response is received again, it sends 2 other requests in parallel from 2 random and remote locations (the list of locations can be found here.

If these 2 remote requests fail to get a response too, then the monitor is marked as down and notifications are triggered.

Or, if the monitor returns an erroneous HTTP status, it is instantly marked as down without verification (as the status is returned from the monitor itself).

Once a monitor is down, UptimeRobot keeps sending requests every 1 min (no matter the default monitor interval) for faster uptime recovery, only from the main location.

So, in case of a 30 min downtime (except HTTP-status-based downtimes), the monitor needs to:

• Fail to respond twice from the main engine
• Fail to respond from 2 remote locations
• and must have failed to respond at least 20-25 times in a row from the main location (as the requests are sent only from the main location once the monitor is down)

There are some rare/edge scenarios such as (both of these scenarios have a very low possibility, yet, still possible):

• Our requests/IPs may have been temporarily blocked by a firewall
• There may have been a problematic hop between UptimeRobot’s servers and monitor’s server. And, if all the requests UptimeRobot has sent passed from that problematic hop at some point, the requests may have failed and UptimeRobot would think that the site didn’t respond. This is the main reason we send "verification requests" from multiple locations to minimize this risk and it is very very low