Dec 03


I have been migrated to the Australia’s national broadband network (nbn). Soon after the migration I begun experiencing Internet connectivity issues which my old cable internet service did not have. I got fed up with waking up to find that my ISP-provided nbn router lost connectivity overnight and never regained it, or that it did this in the middle of the day when I needed to work, or when I was not at home and my family was inconvenienced. I decided to figure out a way to “monitor” my Internet connection and get alerted when it went bad. This is so that I had an opportunity to investigate and reboot the router, which was the only way to deal with the issue most of the time.

In this article I outline how I set up connectivity monitoring for testing Internet connectivity of my internal network from the “outside”, that is an Internet-based monitors testing connectivity to my infrastructure.

It seems perhaps strange that I would want to test my Internet connectivity from the outside as the first thing I wanted to do. The reason is simple. If I set up an internal monitoring mechanism then I couldn’t get email notifications about connectivity issues – there would have been no connectivity, right?

Need Internet-based monitoring service

First, one has to find an Internet-based monitoring service which to use; free if possible, cheap if no satisfactory free service is available.

A bit of research lead me to the UptimeRobot – This organisation offers a free service with some limitations which did not matter to me as what I needed to do did not require their premium service.

I signed up and set up a single monitor which would “tickle” my infrastructure every 5 minutes and email me when it failed to get a response and then again when it succeeded in getting a response after an interruption.

Since my mobile device can receive emails regardless of whether my internal network has Internet connectivity I started getting notifications about outages within 5 minutes of outages being detected and if I did not resolve the issue myself and the issue “went away” I started getting notification within 5 minutes of the connectivity being restored.

How I set up the “tickle” “responder” is discussed next.

Need Internet-visible “Responder”

For the external connectivity monitor to work I had to have a “responder” which was visible from the Internet, responded to queries and was of the kind that a monitor service could deal with.

UptimeRobot offers monitors which:

  • connect to a HTTP(s) URL
  • connect to a HTTP(s) URL and do look for a keyword
  • connect to a specific port on a specific host
  • Ping a specific host (presumably using an ICMP Packet but I was not motivated to look into this closely since the Ping request failed when I tested, presumably having been blocked by the ISP or the router)

While my ISP-provided router has web-based UI this UI is not accessible from the Internet, that I can detect, and it offers no other Internet-visible HTTP(s) endpoints to which for the monitor to connect.

I have a small PC, with the address in the ISP router’s DMZ, on which I created a HTTP responder and exposed it to the Internet via a port forwarding rule on the ISP’s router. The HTTP connection request from the monitor will get a response if the router is accessible from the Internet, meaning that my internal network can connect to the Internet. That’s it.

Later on I configured another UptimeRobot monitor, which simply needed a listener on a TCP port, whether that listener did anything or not. This eliminated the need to run a web server, however minimalist.

Configure a Monitor

A server or URL monitoring service can be used to monitor connectivity and notify of service interruptions and resumptions once the “responder” service is running and can be “tickled” from the Internet.

UptimeRobot (

An UptimeRobot monitor can be configured with the URL of the “responder” and the email address(es) to which to send notification emails. UptimeRobot tests connectivity every 5 minutes in the free service.

One issue I detected with the UptimRobot is that is occasionally uses outdated cached IP address of the target host, which may have changed and has been updated in the Dynamic DNS service, thus it does not recognise for a while that the host is visible form the Internet because its IP address has changed.

StatusCake (

A StatusCake monitor can be configured with the URL of the “responder” and the email addresses to which to send notification emails, and a mobile phone number to which to send text messages. StatusCake tests connectivity every 5 minutes in the free service.

I recently signed up to the free service because of the IP address caching issue with the UptimeRobot and I am watching how the StatusCake behaves and what it produces.

Port Monitor (

A Port Monitor monitor can be configured with the URL of the “responder” and the email address(es) to which to send notification emails. Port Monitor tests connectivity every 60+ seconds in the free service.

Monitoshi (

Monitoshi offers a service which may cease to be free at some point in time. It does not have a status UI and the monitors are enabled/disabled via API URLs.


A couple of issues make this solution less than perfect.

The first issue is that of dynamic IP addresses. If the externally visible IP address of the server, configured in the monitor definition, changes then the monitor will report downtime regardless of whether the physical server is up and accessible. This necessitates manual change of the I address in all monitors or the use of a Dynamic DNS service and some mechanism to detect the address change and update the Dynamic DNS.


To test internal-to-external connectivity, and receive notification of connectivity issues an external monitoring service is needed. This service needs to be able to connect to an internal responder. The internal responder must be “visible” from the Internet. Once both are configured, one gets notified when the connectivity disruption is detected and when it is restored.

Leave a Reply

preload preload preload