Monitage: Uptime monitoring beta

Many Clicky users have asked us about site monitoring. We are happy that this is top-of-mind for some of you because its importance should not be understated. Often we will receive emails from Clicky users asking why there was a dramatic lag in visitors tracked or a complete drop-off altogether. While there can be many explanations, it is not uncommon that the site itself went down unbeknownst to the site owner. Standard web analytics will not be able to tell you this, but site uptime monitoring and alerts will.

With this in mind, we are excited to announce a closed beta in partnership with Monitage, a newly-developed site uptime monitoring service by Roxr Software (that's us). We have integrated Monitage into Clicky to give you a bigger picture of the health and activity of your web sites.

Monitage monitors web sites from five locations around the world (three in the US, one in Paris, one in Japan) and only declares a downtime event if a majority of its servers agree on it. This prevents network hiccups on the monitoring end from sending false alarms.

Pro Plus users and above receive access to the Monitage closed beta. When we officially launch, you will have the ability to create up to 30 checks per site with intervals as fast as 1 minute, but during testing we want to keep resource usage within a reasonable range. So for the time being, we are limiting to 3 checks per site with a max interval of 5 minutes. We expect to officially launch within 4 weeks, at which point Monitage will also be available as a standalone service.

To access Monitage, go to your site dashboard and click the Uptime tab. You can create checks for HTTP, HTTPS, SSH, FTP, IMAP, IMAPS, and ICMP (ping). We've also created a dashboard module.

You can also access uptime stats from the API. Check the API docs and search for "uptime". type=uptime will give you the current status of all of your checks for a site. type=uptime-list will give you a chronological list of all downtime events for your site for the date range requested.

Last, we added uptime stats as an option in email reports as well.

When Monitage officially launches, we will determine what intervals and types of tests will be included with Clicky Pro Plus plans and above.

We are asking that you test Monitage, and let us know your thoughts, what you like, don't like, and want to see. As Monitage is in its infancy, we want your feedback to help mature it into a stalwart companion to Clicky.

Note to white label customers: Monitage will be added as an option to white label service when it officially launches, but for now it is only available to Clicky users.

Update, Feb 4: Just pushed an update that integrates uptime monitoring into the Big Screen report. Also added web hooks to the setup page. Enter a URL and we will POST a JSON object (documented in the setup page) to that URL for events.

Also we've been getting reports of false positives since launch, we are pushing some updates later today that should fix it entirely, or at least close to.
21 comments |   Jan 22 2013 6:23pm

'GetClicky' no more!

You may have noticed that we're now live on! Yay!

For 6 years, our brand has always been "Clicky". Excluding our domain name, nowhere on our site has the brand "GetClicky" ever been mentioned, other than some testimonials that we didn't edit. However, because of the old domain name, the majority people have always referred to us as "GetClicky". It didn't help that our Twitter handle was also @getclicky, but we wanted it to match our domain name (bad idea). It's always kind of driven us insane, but it's been an interesting lesson. If you can afford the right domain name, do yourself a favor and buy it as soon as possible. We paid a pretty freaking penny for, but the second it was in our possession was just pure unadulterated joy.

We've had the @clicky Twitter handle from the beginning, but it was just a placeholder. We've now swapped @getclicky with @clicky so all of our followers and tweet history remains in place. Fun fact, Twitter does not offer an official method to do this - you have to actually relinquish your brand for a brief few seconds while you swap things around, which is extremely nerve racking to say the least. So @clicky became @clickyx, @getclicky became @clicky, and last @clickyx became @getclicky. Scary 20 seconds or so. Anyways, please note: If you tweet at us in the future, use @clicky, not @getclicky! But if you were already following us you will keep getting our tweets without having to do anything.

Any page viewed on is now redirected to, with a little note at the top about updating your bookmarks. That note will go away in a few weeks, but for now we want as many people to notice the change as possible.

You do NOT need to update your tracking code, because isn't going anywhere. Your existing tracking code, along with any integrations you have with the API, widgets, or whatever via, all will continue to work. Going forward, will only be seen in the tracking code (we are using it indefinitely for tracking). And we'll continue to use it for email, for now at least, since that's a nightmare to change. So... = web site domain, = tracking domain, email, and indefinite backwards compatibility.

This was not as easy as just acquiring and pointing it to a new IP address. A service of our size and complexity, there's a LOT of things to deal with when changing your domain name. My checklist is ridiculous in length and I hope to go into it more in a later blog post.

There may be a few bugs lying around... we'll squash them tomorrow as they come to our attention.
32 comments |   Dec 19 2012 12:34am

On-site analytics update

Just pushed a much needed tracking update for sub-user accounts, so now they can use on-site analytics, and their traffic will now also be automatically ignored.

Previously this was not possible because of the way our tracking servers were caching information about each site in memcached. After banging heads on keyboards for a while, we finally figured out a way to do it (it's more complicated than it sounds). So, now sub-users will have their traffic ignored automatically, and they will see the on-site analytics widget.

One caveat - the master account's preference for disabling on-site analytics on an account wide basis will override a sub-user's preference.

Making this change also addresses a bug that popped up after the four-week heatmap trial ended a few days ago. All sub-user accounts are created as "Pro", since Pro has always had access to every feature, and a Pro account was required to have sub-user accounts. But now that heatmaps require Pro Plus or higher, heatmap tracking broke for some of you if you had created another sub-user account and assigned them admin access to a site in your account. Their account features were overriding yours on the tracking servers for the sites they had admin access to. So this update fixes that. But we went ahead anyways and made sub-users account types mirror the master accounts - any time the master account type changes, the sub-users are updated accordingly, to address any future updates that might cause this scenario to come up again.
2 comments |   Nov 16 2012 2pm

Update on heatmaps

Heatmaps launched four weeks ago. As we said in that post, everyone would have it for four weeks, but then we would be requiring a Pro Platinum account to continue usage after that point. The reason for this is because the extra bandwidth and storage requirements for this data are significant, which has proven to be the case as we've monitored resource consumption since launch.

After listening to your feedback, we've decided to add a new plan (Pro Plus) with pricing in between Pro and Pro Platinum. It is the exact same as standard Pro, except that it includes heatmaps.

As of now, these changes are live. So if you are the standard Pro plan, you will need to upgrade to at least Pro Plus in order to keep heatmap tracking going forward.

Note to white label account holders: We've had a few of you ask about heatmaps for white label, we are including this feature with all account levels.
12 comments |   Nov 12 2012 2:28pm

Please do not place third party javascript in your HTML head.

There were a few bugs with our new heatmaps for people who were putting our tracking code in their HTML head tag, and there were an alarmingly large number of you doing so. Those bugs are fixed now, but that's beside the point of this little post.

Web browsers download page elements in the order that they are listed in your HTML - CSS, javascript, and images (mostly). If the domain that any of those are hosted on is offline or going slow, a web browser will "hang" for up to 60 seconds while it waits for the item to load, before moving on to the next item. (Asynchronous javascript is an exception but that's still not very common - although we do offer it an option - but again, that's not the point. And besides, if you're loading it asynchronously, you're not depending on it being available for immediate execution, so what would be the point of putting it in your HTML head?).

If you have third party javascript in your HTML head and that third party server goes offline, your web site is effectively dead because nothing else is going to load for up to 60 seconds. When I visit sites that hang like that, I immediately close them as I'm sure 99% of people do.

If the javascript was instead in the footer of your web site, the web browser would still hang trying to download the item, but most of your site would already be loaded in the visitor's web browser. In other words, your site would still be (mostly) usable while the engineers for the third party service go into panic mode.

Our CDN never really goes "offline" but there are obviously thousands of services out there that ask you to put their javascript on your web site. Any third party javascript code that's not critical to your web site working properly should never go in the HTML head. Tracking code, ad code, widgets, social plugins, etc - these are all non-critical and have no business up there. Help make the internet a better place and always put that code at the bottom of your web site, k?

The only valid exception here is if it's hosted by a major provider such as Google, and you rely on the functionality of that code as the page loads (which we do for Google's map API, but that's it). That is the only exception.

So... if you've got our code in your HTML head, please move it instead to the bottom of your HTML, right before the closing /body tag, as has always been recommended on the page where you grab your tracking code from.

Bonus pro-tip: For first party elements, your CSS file should always be the very first item in your HTML head. That way your site will always look "proper" as soon as possible, beacuse this will be the very first thing the browser downloads after the HTML itself.
3 comments |   Oct 17 2012 4:25pm

Next Page »

Copyright © 2019, Roxr Software Ltd     Blog home   |   Clicky home   |   RSS