Last week we finished adding more uptime monitoring capacity for our users that are working out of Australia, to provide faster uptime monitoring.

Faster uptime monitoring, latency matters

If the network packets need to travel half the world, it adds up to a noticeable amount of latency when monitoring remote websites.

For instance, we are based out of Europe. If we were to connect to a server somewhere in Australia, we'd quickly lose 300ms for every packet we send over the network just to make it to the other side.

$ ping uptime-checker-sydney.ohdearapp.com
PING uptime-checker-sydney.ohdearapp.com (45.32.189.194): 56 data bytes
64 bytes from 45.32.189.194: icmp_seq=0 ttl=42 time=304.764 ms
64 bytes from 45.32.189.194: icmp_seq=1 ttl=42 time=304.861 ms
64 bytes from 45.32.189.194: icmp_seq=2 ttl=42 time=304.750 ms

This same delay is present when we perform uptime checks. The entire path between EU & Australia also contains over a dozen hops. Each hop has the potential to break the connection, be overloaded, suffer downtime, ...

For us to monitor websites worldwide, we need to be close to the source.

Location detection

When you sign up, we determine your default uptime monitoring location based on the IP address you sign up with. It's a simple check to set a default, where we take Paris as the fallback location for all our EU clients.

protected function determineDefaultUptimeChecker(): string
{
    $detectedTimezone = IpApi::getPropertiesForCurrentRequest()['timezone'];

    if (starts_with($detectedTimezone, 'America')) {
        return array_random(['toronto', 'dallas']);
    }

    if (starts_with($detectedTimezone, 'Asia')) {
        return 'bangalore';
    }

    if (starts_with($detectedTimezone, 'Australia')) {
        return 'sydney';
    }

    return 'paris';
}

Once your default location has been determined, we'll use that for any new site you add.

Of course, you can modify the location per website, right in your dashboard. If you have customers worldwide, chances are your websites are located worldwide, too.

Validation of downtime via secondary location

We'll use the closest available location where we have servers to do our primary probes. For our Australian users, that will now be a server based in Sydney.

Once we detect downtime, we'll use a secondary location to confirm that there is indeed a problem. To confirm this, we'll use a server located in another country which is also served by another cloud provider.

Our Sydney server is run on Vultr, so we'll use one our Digital Ocean servers to confirm the downtime. This way, we eliminate false positive alerts that are caused by connectivity issues at a single cloud provider.