“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.