Uptime Monitoring

Akeeba Panopticon does not offer uptime monitoring — and there are no plans for offering this feature. This is intentional.

Why using a third party service makes more sense

When you think of a site's “uptime” the only definition which makes sense is that typing the site's URL results in a response being generated in a reasonable amount of time, which contains the output you expect from the site — and this happens regardless of where in the world you are accessing the site from.

Just by this definition we are putting three major demands on an uptime monitoring system:

• It must measure and log the response time of the site, not merely if the HTTP request is (eventually) responded to or not. If the site takes 150 seconds to respond it's far from being usable by real humans.
• It must examine the contents of the response, not just the HTTP status code. Getting an HTTP 200 OK with an empty response, or with the default “It works!” page of the Apache web server does not mean that our site is up.
• The above must take place from disparate geographic locations and the results correlated to determine if a site is up. For example, if your site can be accessed just fine from Germany, very slowly from the US east coast, it takes well over two minutes to respond for users trying to access it from the US west coast, and returns a blank page for users in Australia and Japan then probably your site cannot be called online. This would be true even if the site is German-speaking only because you cannot guarantee neither the geographic path a request will take, nor that there are no Germans in Japan trying to access it.

In short, it gets very complicated very fast.

We could easily implement the first two requirements in Akeeba Panopticon. Having this code run every minute to few minutes would make it a bit harder for you to set up CRON jobs but it would be workable.

The third requirement, however, is by definition impossible with Akeeba Panopticon which is self-hosted on a single server, therefore a single geographic location. Even if we created small clients to install on servers across the world the set up of this constellation of servers would be both complicated and expensive, thereby negating the reason you are using Panopticon in the first place.

Therefore, it makes far more sense to use a third party service. We recommend HetrixTools, the same service we use for our own sites.

Why not integrate with a third party service

The next question is, naturally, why not integrate with a third party service. They all offer an API.

There are three reasons.

First, integration requires an API key. We cannot include an API key with our mass–distributed software because it's both a violation of the Terms of Service of third party services, a stupid business move (we'd have to pay for everyone's uptime monitors), and a security concern (everyone could see everyone else's uptime monitors). This means that you'd have to create and set up your own API keys for your own Panopticon installation which, again, becomes a bit too involved but still manageable.

The second, and more important, reason is that every third party update monitoring service we've seen has very restrictive API usage limits. We could request an update on the site's status once every hour to once a day. This would be totally useless for any practical use, such as notifying you by email when your site is down. On the other hand, all of these services do allow you to set up email alerts and some of them even allow you to set up push notifications or SMS (text) alerts as well. Therefore, integrating with their API would yield much less functionality than these services already offer.

The third and final reason can be summed up as “nobody will be content no matter which service(s) we integrate with”. Should we choose HetrixTools? Uptime Robot? Something else? Which one? All of them? When does this madness stop? We end up in a situation where we need to implement and maintain a lot of integrations with a plethora of services, even though we know there is absolutely no benefit from doing so and it will lead to frustrated users submitting support requests for what cannot be fixed except by removing these integrations altogether.

Therefore, we chose not to implement an integration with any of these services.

But…

So, you think we're wrong in our assessment about this feature being a bad idea — most likely because you have a use case where (you think) it's not.

No problem! This is Free and Open Source Software which can be extended with User Code. You can hire a developer (not us; that would be hypocritical on our part) to implement this feature for you, as long as you abide by the software license.