Because a HeartBeat Uptime Monitor has only one point of failure, which is your server’s ability to send data to our platform, unlike all of the other Uptime Monitor types where your monitored target is checked from different geo-locations around the world. So, with a HeartBeat Uptime Monitor, if at any time for any reason your server is unable to send data to our platform, your Uptime Monitor will be declared as being offline even if your server may not actually be down.
If you wish to install our Server Agent on your server in order to monitor metrics such as CPU/RAM/Disk/etc usage, you can attach it to a classic Uptime Monitor, as explained here:
How is the uptime checked for other types of Uptime Monitors?
The classic types of Uptime Monitors (ie: Website Uptime Monitor, Ping Uptime Monitor, etc) are the monitors where you define a target IP/Domain/URL to be monitored. Our platform then uses our global monitoring network to check your monitored target from around the world, from different geo-locations, from different hosting providers, multiple times per minute and retrying multiple times if fails are detected. Meaning that it’s a very very accurate system that will precisely detect when your monitored target is offline or online.
Furthermore with these classic Uptime Monitor types, our platform will also collect all of the fails encountered from our monitoring locations, into your Location Fail Log, where you can see the actual errors that have been encountered, in order get a better overview of what’s wrong with your website/server.
Going even further, our platform will also collect Ping and MTR samples when an outage is detected, so you can debug possible network issues (if the downtime was caused by such type of issues). These samples are conveniently stored in your Network Diagnostics, so you can easily review them for each of your detected downtimes.
How is the uptime checked for a HeartBeat Uptime Monitor?
The uptime for such Uptime Monitors is solely determined on whether or not your server is sending data to our platform, because this is what a HeartBeat monitor is; which means that none of our global monitoring nodes are checking up on your server to make sure it’s actually online or offline.
There can be times where a HeartBeat type of monitor can generate false positive downtimes because for some reason your server isn’t able to send data to our platform. There can be plenty of reasons why this may happen, such as (but not limited to):
- regional network issues between your server and our platform
- local DNS issues on your server or network
- high CPU load on your server that may crash or impair our agent’s functionality
- cronjobs not functioning properly on your server
The HeartBeat Uptime Monitor, by design has only one point of failure, which makes it less reliable for uptime tracking than other types of monitors.
Furthermore, considering that none of our monitoring locations are checking up on your server, there are no Location Fail Logs or Network Diagnostics being collected, as with classic Uptime Monitors. So the issue that is preventing your server from sending data to our platform will be completely isolated on your server, and would have to be investigated by your system admin.
At this point you may be asking yourself: why are we claiming that all of the issues are on your server and may not be something wrong on our end that’s preventing your data to be received by our platform?
Our platform is configured to have High Availability, so for us to have data receiving issues on our end would require multiple parts of our infrastructure to be having issues. This is not impossible, just not likely. However to go a step even further, we’ve also configured multiple fail safes in place where our system will not issue HeartBeat alerts if it detects receiving issues on our end; so even if multiple parts of our infrastructure start failing which would prevent our platform from receiving your server’s data, you would still not receive false positive alerts. So if data is not received for your HeartBeat Uptime Monitor, the issue is most likely on your server or on the connection between your server towards our platform, rather than on our end.
If you want truly accurate Uptime Monitoring then a HeartBeat type of Uptime Monitor is not the most reliable to go with, because as explained above it only has one point of failure, as opposed to multiple points of failure around the world as classic Uptime Monitors have.
Our advice is to setup a classic Uptime Monitor (ie: Website Uptime Monitor, Ping Uptime Monitor, etc) to which you can attach a Server Agent if you wish to monitor things such as (CPU/RAM/etc usage as well), as described here: