Oct-17 Scheduled downtime for server migration

Exciting times abound as we prepare to move our data processing and web serving infrastructure into Amazon’s EC2 Cloud. This move has become increasingly necessary with the substantial growth Wormly has seen in the past 18 months. Moving to the cloud allows us to offer a substantially more robust, higher availability system.

We will be performing the cut-over on Sunday October 17 at 11:30am (GMT+1100). We expect wormly.com will be unavailable for three hours during this period, which means you will not be able to modify monitoring configuration or view reports during this time.

Rest assured, though, that both uptime and server health monitoring will continue unaffected during this time. All data samples will be accrued and all alerts will be sent as normal.

We appreciate your patience during this time, and trust that the extra scalability and reliability that this move brings will be worth it.

If you have any queries at all, please don’t hesitate to contact our support desk.

Additional notes

The IP address used for health monitoring (inbounddata.wormly.com) will change from to This address will also become the source IP requesting the agent for Linux health monitoring installations.

The uptime monitoring node IPs will remain the same – an up to date list of monitoring node IPs can always be found here.

These can and will change over time, however, so we do not recommend creating IP-specific firewall rules for use with our service.

Filed under: Announcements — Jules @ 12:58 pm - October 2, 2010 :: Comments Off

Wormly API Now Available

It’s been in private beta for quite a while now, so we’re very pleased to announce the immediate availability of the Wormly Developer API. Or ‘WAPI’ for everyone who loves an acronym.

Head over to:


And check it out. Or just click the “Developer API” link that you will now find at the bottom of every page.

We’re still in the early stages of WAPI’s development, and consequently the API coverage of Wormly’s functionality is by no means complete. With your feedback and suggestions, though, we will be increasing API coverage as quickly as possible.

So drop us a line if we’re missing something crucial to you!

Filed under: Announcements,Features,Meta — Jules @ 3:17 pm - March 17, 2010 :: Comments Off

Alert logs now exportable & include host details

Primarily to assist those who on-charge the cost of notifications (SMS, phone calls, etc) to their customers, the alert log browser now includes the name and numeric ID of the host that triggered the alert.

These records can now be exported in .CSV format in addition to being viewed on screen.

The alert log browser can be found under Settings, Alert Recipients, View Alert History (toward the bottom of the page).

Filed under: Announcements,Features,Meta — Jules @ 12:21 am - September 17, 2009 :: Comments Off

Pre-Payments Now Available

Due to (somewhat surprising) popular demand, we have implemented a system allowing customers to make pre-payments of any amount to their Wormly account.

The pre-payment is added to your account balance, and used to pay subsequent invoices automatically as they fall due.

Additionally, the process includes the creation of a print friendly invoice.  This can be handy if your accounts department needs to see some paper before they hand over the cash, figuratively speaking.

The pre-payment invoice can then be settled via Visa, MasterCard or PayPal.

You can access the facility directly or via the Add funds link on the Billing page.

Filed under: Announcements,Features — Jules @ 1:10 pm - March 5, 2009 :: Comments Off

SMS Delivery Outage

For a number of short periods between  Feb 10 17:05 and  Feb 11 09:36 (GMT+11) our New Jersey node ( failed to deliver SMS and Phone call alerts for some customers.

This was caused by the node’s inability to resolve the DNS record needed to connect with both our primary and backup SMS gateways.

This in turn was caused by failures of the New Jersey data center’s DNS resolvers.

That, however, should not have been a problem because the standard operating environment (SOE) for all Wormly nodes includes a private DNS cache & resolver in order to prevent exactly this sort of problem.

However this particular data center provider uses a DHCP based network configuration process, which caused /etc/resolv.conf to be updated by their DHCP server, thus reverting DNS resolution back to their servers.

We have ensured that this cannot occur again by setting the immutable attribute on /etc/resolv.conf – something which is now part of our SOE.

Needless to say we apologize to the customers this has inconvenienced – and should mention that of course no charges were billed for the failed deliveries.

We’re also pleased to report that our internal monitoring alerted us to this situation, so even in the absence of contact from a couple of helpful customers we would have been able to identify and correct this problem in short order.

Thanks for your support and understanding!

Filed under: Announcements,Meta — Jules @ 10:44 am - February 11, 2009 :: Comments Off

Are Your Servers’ Clocks Accurate?

Despite the prevalence of NTP, many sysadmins do not keep their servers running on the correct time.  This is unfortunate, as it can make troubleshooting via log files much more difficult.

To celebrate 2008 finishing up one second longer than most years, Wormly now reports if a servers’ clock is running slow or fast via the Health Monitoring tab.  e.g.:

So if you notice your servers running with an inaccurate clock, it might pay to put something like the following into cron:

/usr/bin/rdate -s time-nw.nist.gov

Note that this feature is currently only available for Linux servers. We hope to make it available for Windows servers in future.

Feature Deployed @ 2000-01-02 00:30 GMT

Filed under: Announcements,Features — Jules @ 10:42 am - January 2, 2009 :: Comments Off

Adwords Broad Matching: When a visit is not a visit

Don’t want to pay for a search phrase containing the word “visit”?  No problem, just add it to the Adwords campaign negative keyword list.

Then Google will happily sell you clicks on the keyword “visits” instead.

Google is more than happy to offer “broad” keyword matching to increase the inventory of searches available for click & sale, but when it comes specifying keywords you don’t want to pay for, Google insists you be very specific. And able to deliver very poor spelling.

Peek Behind The Keyword Curtain

Just discovering what search phrases Google is selling you can be challenging, and is undoubtedly out of reach for the vast majority of Adwords buyers. Neither Google’s Adwords reporting, nor Analytics product – even with “ad tracking” switched on – will reveal the actual search phrases that were sold to you.

The only reporting Google offers is a carbon copy of the keywords you chose, which Google by default broadly matches against what users actually type into the search engine in order to display your ad and sell you the resultant click.

Instead, you need to scrape the referrer headers from your web server logs to determine what search terms you have been paying for. Which, of course, we do.

The Broad Match

One of the phrases we buy advertisements on is “website monitoring” – certainly a reasonable fit for our target audience. Imagine, then, our surprise at discovering that the following happy searcher was delivered to our website. For a modest fee, of course.

The usefulness of Google’s broad matching abilities have been discussed at length.  We know that the vast majority of advertisers have little idea of what keywords they are ultimately paying for, given the on-by-default nature of “broad matching”.

Even putting this substantial issue aside it is reasonable to expect that one can explicitly choose not to pay for irrelevant searches; for visitors with zero value.

Instead we find that our campaign negative keyword list grows daily, with such delights as “survailance”, “surveilance” and an ever increasing number of spelling variations. Each time because we’ve paid Google to deliver a worthless visit to our website.

Filed under: Google Adwords,Marketing,Sales Process — Jules @ 11:32 am - December 17, 2008 :: Comments Off

Phone Call Alerts Now Available

Owing either to high traffic events or server administrators going on holiday without a contingency plan, our users are likely to see lots of downtime throughout the festive season.

To help out, we’ve brought back the plain old telephone system.

As of today, phone call alerts are available in both our server health and uptime monitoring systems.  For example, you can configure phone alerts if free disk space falls below 5% for more than 30 minutes – or if CPU load stays at 100% for a bit too long.

Calls are charged at a flat rate of $0.40 per call.

Naturally you can also configure a phone call if your site goes down altogether.  A useful escalation schedule might be: Email when the downtime first occurs, send an SMS after 10 minutes, and make the phone call after 30 minutes.

We reckon that a phone call is still the best way to wake up your normally over-caffeinated sysadmin at 4am when The Bad Stuff happens. That little SMS *bleep* noise from their phone doesn’t always do the trick.  And knowing that it’s all automatic is even better.

You can learn more about phone call alerts on this page.

Feature Deployed @ 2008-12-01 09:00 GMT

Filed under: Announcements,Features — Jules @ 12:59 pm - December 3, 2008 :: Comments Off

Health Monitoring Alerts Now Available

We’re very pleased to announce the immediate availability of our server health monitoring alert system; a feature which has been at the top of our most-requested list for some time now.

A simple screenshot explains it nicely:
setup server health alerts

Naturally you can also read about the feature in more detail.

For existing users, simply click on your hosts’ Health Monitoring tab and follow the instructions to start using this new feature.

Feature Deployed @ 2008-11-14 09:00 GMT

Filed under: Announcements,Features — Jules @ 8:59 am - November 17, 2008 :: Comments Off

Are spam filters damaging your cash flow?

One worrying trend we’ve noticed in recent months is the increasing likelihood that our customers’ spam filters catch our monthly invoices, either sending them to the oft-ignored spam folder, or rejecting them outright.

Needless to say this is concerning because our customers either won’t know their credit card is being charged (if they’re on our auto-bill system) or simply won’t know that payment is due; risking suspension of their account.

Intuitively it makes sense that spam filters would attach a high spam score to invoices & payment requests, as these sorts of documents very often feature in spam and phishing attempts.

So, what to do about it?

Our experiments revealed that nearly every major spam filtering system is substantially less likely to classify an email as spam if it originates from a well known, reputable mail service such as GMail, Yahoo Mail, Hotmail, etc.  The identity of the originator is determined by IP address rather than the unreliable From: header.

Bear in mind that your web server either has no reputation value at all or – worse – has an IP address that was previously leased to less scrupulous operators. As availability of IP addresses becomes tighter you can certainly expect that the IPs attached to your shiny new server have been used by numerous websites & servers before reaching you.

We’ve experienced this situation a number of times – as we maintain a large number of servers in physically disparate locations (hence on different networks) and need to ensure email alerts can be delivered from all of them.

Google to the rescue!

At this point a possible solution becomes clear – route important email via a well known and reputable service to improve its chances of successful delivery.

We’ve been trialling this by utilizing the SMTP relay service provided by Google Apps Premier Edition – which powers all email destined for the wormly.com domain. It’s dramatically improved the situation for us thus far, and provides the additional benefit of archiving all web server outbound email within GMail.

To assist if you’d like to try something like this, I’ve posted a howto for configuring Postfix to relay via GMail’s SMTP service.

Filed under: Servers,Web 2.0,Web Services — Jules @ 3:56 pm - November 11, 2008 :: Comments Off
« Previous PageNext Page »

Never Offline

A blog hosted by James Peterson, director of insights @ Wormly

On a semi-regular basis James will be trying to demonstrate that website infrastructure really is an exciting topic, and that your users really do care about the uptime & speed of your website.