Two major things:

“It should be mentioned that a limitation of this survey is that we only monitored the home page of each service.”

This is a major thing. Squarespace is the only service in the above list that actually uses its own system to power its own site. Blogger, Wordpress, TypePad, et al. don’t use Blogger.com, Wordpress.com and Typepad.com the application to run the pages you’re actually running the test against — so you’re more or less testing some sort of Datacenter uptime with this report, and not service uptime. The system could have the application you’re testing down, but their homepage up. You should be testing against a hosted blog on each platform. It’s easier to keep a regular homepage up than a user service.

Further, you’re reporting our service as down for 5h during these 3 months — but this is incorrect as it doesn’t take into account *scheduled* downtime. Aside from a 1H – 1.5H datacenter power outage in November — you’ve tracked our scheduled downtime as part of our overall downtime — since you’re just polling our homepage.

We’ll pull a report from Gomez (our 3rd party monitor) and post to our service blog shortly.

Further on Squarespace — we pulled our report from from Gomez (http://www.gomez.com/) that tests our system from 10 national and international locations. The service operates like pingdom but is more granular. These numbers are averaged and actually *include* scheduled maintenance:

TestTime ResponseTime (seconds) Availability (%)
11/01/08 0.29 99.95
12/01/08 0.44 99.92
01/01/09 0.44 99.93
02/01/09 0.31 99.92

I don’t think this study was scientific by any means. I question your methodology.

“It should be mentioned that a limitation of this survey is that we only monitored the home page of each service.”

In the case of Typepad, you’re going to get false uptime reads off of that, and they’re not going to leave a comment like I will to tell you so. Typepad’s main page is often up while individual blogs are down.

Also, LiveJournal was not out for 13 hours and 50 minutes for the last five month period. The time period they were down almost wholly constitutes one 24 hour period this January that just passed. That’s it outside of another minute or two here and there.

This study should not be taken seriously – not when combined with the fact that you ignored uptime for individual blogs on each service entirely and you did not review the services to compare the features each one offers, their pricing levels, their community feel or lack thereof, etc.

great work here guys.

Ha, so much for squarespace’s “99.98%” uptime they claim

Squarespace is by far the best blog service.

Squarespace is so much better than the other services tested it hurts.

@Pngdom- because I like to finish what I started –

http://community.livejournal.com/lj_maintenance/

You tell me where you got your figures. If there was less downtime this year than I thought I recalled then you’re case just got weaker. Also, dispute this: almost every minute of LJ’s downtime was scheduled and warned about in advance – we don’t go down all willy-nilly like Typepad and Blogger do in their usual “Whoops…where’s my page…did we just get hacked?” sort of way. Your article’s inaccuracies and overall vagueness do a grave disservice to every blogging platform you surveyed.

(Re-posting)

“but you mention that we included downtime caused by scheduled maintenance as if this was something incorrect on our end. Yes, we did include all downtime, no matter what the reason was (does it matter to the end user why the site is down?).”

This isn’t true — of course this matters from an end user perspective. Maintenance scheduled and planned for at 1-3AM EST is completely different than unexpected intermittent availability during working hours of the day.

“Regarding the numbers you included from Gomez, it would be helpful if you disclosed what they were measuring. How often were tests performed? What was the timeout limit? What (exactly) did you test (network uptime? site uptime? what URL? what were the critera for downtime?).”

The reason this is an Apples to Oranges comparison is that you actually tested our application service, but tested the static front pages of the remaining services. Squarespace is the only provider listed that uses its own hosting service for it’s front page. Why not test an actual TypePad blog, including the back-end application availability?. If you’d like us to set up a front page disconnected from our real application that you can test against for future tests of this nature, let me know. We’d rather just test the real service though.

To answer your Gomez questions specifically:

> If you disclosed what they were measuring. How often were tests performed?

They’re testing our application availability (www.squarespace.com availability, which is an account called ‘www’). The tests are conducted against a live page from our application, and test that the page is served in a reasonable amount of time. Tests that take too long to complete (over 2 seconds) are considered failures. This isn’t a simple ping or some sort of network level test.

The timeout limit is actually tracked 4 different ways — depending on what’s really timing out (socket read, socket connect, etc). These vary from 12-60 seconds, but are ultimately irrelevant, as the tests are against if the dynamic page is sent completely in a reasonable amount of time.

Further, the tests are conducted every minute from 10 geographically diverse nodes (some US, some elsewhere). Thus, it would seem the test is actually more sensitive than yours.

As a final point, can you explain how you’ve only tracked 20 minutes of blogger downtime during this period, when their own status blog seems to indicate more downtime than that from only scheduled maintenance (http://status.blogger.com/) — though this could be the “not testing the actual service issue” from my previous point.

Since the availability and reliability of the Wordpress is so high, I build all my blogs on the wordpress platform.