Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

37Signals benchmarks uptime vs five leading webapps

37signals.com

Post reply on HN
Print view View original

11–20 of 34 posts

Re: 37Signals benchmarks uptime vs five leading webapps

#11

Post by themcgruff »

dhh wrote: post #5
ceejayoz wrote: post #3

Do note that Pingdom, unless specifically configured otherwise, counts a successful HTTP request as uptime. If that HTTP request is returning a page saying "our database servers are down, try again later", it still shows as uptime. You can configure it to send POST data and expect a particular response, but there's no way of telling (other than "yep, that's what we're doing") whether someone's uptime stats are based…

We configured all the benchmark apps to expect a response. So on Github we go and checkout a repo. On Freshbooks a known invoice. On Assistly the agents index. Etc. This is "the app is functional" checking. Not just 200 OK.

That should read we "check a repo". We don't actually do a git checkout.

Re: 37Signals benchmarks uptime vs five leading webapps

#13

Post by jiggy2011 »

skrish wrote: post #7

One of the comments in the blog is: "Just signed up for pingdom and they sent me my password via email in clear. Great!" I signed up to check if they really do. What pingdom does upon sign-up with your email id they send a password via email. I have a high opinion of pingdom & I was expecting them to enforce change of password during first login, but that did not happen!

Even if they enforced a password change it wouldn't help if they are storing them in plaintext.

Re: 37Signals benchmarks uptime vs five leading webapps

#15

Post by smackfu »

jiggy2011 wrote: post #13
skrish wrote: post #7

One of the comments in the blog is: "Just signed up for pingdom and they sent me my password via email in clear. Great!" I signed up to check if they really do. What pingdom does upon sign-up with your email id they send a password via email. I have a high opinion of pingdom & I was expecting them to enforce change of password during first login, but that did not happen!

Even if they enforced a password change it wouldn't help if they are storing them in plaintext.

A one-time password is usually generated and emailed, then hashed and stored, so not generally stored in plaintext.

Re: 37Signals benchmarks uptime vs five leading webapps

#18

Post by verelo »

This is one of those posts that drives me a little crazy :P

We recently started a web monitoring company (in beta) http://www.verelo.com to tackle situations just like this. Pingdom monitors every 60 seconds, its just not enough if you want to make claims like "we were only down for 6 minutes". If you want to make claims at a single digit minute level you need to check more regularly, and your checks need to be robust. We offer monitors that check as regularly as every 5 seconds.

We're going to monitor those same 6 sites for the next 30 days using our service at Verelo and provide comparative results when the next 37signals blog post comes out.

Re: 37Signals benchmarks uptime vs five leading webapps

#19

Post by sunnysideup »

dhh wrote: post #5
ceejayoz wrote: post #3

Do note that Pingdom, unless specifically configured otherwise, counts a successful HTTP request as uptime. If that HTTP request is returning a page saying "our database servers are down, try again later", it still shows as uptime. You can configure it to send POST data and expect a particular response, but there's no way of telling (other than "yep, that's what we're doing") whether someone's uptime stats are based…

We configured all the benchmark apps to expect a response. So on Github we go and checkout a repo. On Freshbooks a known invoice. On Assistly the agents index. Etc. This is "the app is functional" checking. Not just 200 OK.

The most reliable measure of true uptime would be transaction monitoring, e. g. simulating a login into all of these web apps. It also catches those issues were the server itself is up but the site does not work for some other reasons (database issue, javascript issue,...).

Or do you know that all your downtime was "total downtime", i. e. server not reachable at all?

Post reply on HN