Maybe I am too old fashioned but I don't get this service.
Typically I would have Nagios/ HP OpenView/ Unicenter/Tivoli monitoring my applications -- the application agent would page/text/email prod support whenever the app goes down and also it would automatically configure NGINX to redirect everyone to "ooops we are having technical dificulties" page.It wouldn't take more than a day to configure assuning you have Nagios/OpenView/Unicenter etc in place . This is pretty mundane stuff to implement. And that is why I don't get this service.
The selling point is that it's a service not at the mercy of your network or hosting infrastructure. It's hosted by someone else and across multiple AWS zones, so in theory your customers should always be able to hit your status page, regardless of whether your entire AS has taken a hit.
Also it's aimed at startups who may not necessarily have all their automatic status page bits in play on their own infra.
Finally, I'd rather have human control over what I consider to be the the operational status of my various platform services rather than letting nagios or some other automated. There's a very thin lines between "Degraded Performance" and more critical situations, humans are better at deciding that.
Except that it looks like it was reading from New Relic, etc. So if you're collecting that data already, you have no problem doing devops to spit out a static status page for a simple web server to host.
And the pricing is considerably higher than popping an arbitrary number of VPS on internationally diverse hosting providers (or generated HTML on Google Sites, Github, and Rackspace Cloud Sites, or generated HTML cached by CloudFlare, or whatever). A status page shouldn't cost a dedicated 8-way Xeon or 25 Google Apps accounts.
That said, if it were priced differently, I'd recommend it in a heartbeat. Looks great, does what it needs to.
For ecommerce sites, customers would hardly care to see the status of my servers. They would just go to competitors.
It would make sense for SaaS sites for the black swan event -- the whole network infrastructure/rack cage going down. I can see how $5 per month would be justified for SaaS to be notified of a network blowout event.
Can this service host selenium scripts that walks a browser through several key pages of a site and monitor the page load/response time ? I would pay more for that.
I agree it's not for everyone, but I can see its usefulness for a number of service scenarios such as PaaS/SaaS.
I signed up for a trial (no CC required), and there's integration support for Pingdom, New Relic and Webmon. i.e. you can get these to send email alerts to status.io which then parses them to set the service status. e.g. http://doers.statuspage.io/integrations/pingdom/
The upshot for us is that we can let customers know not just that we're having an issue, but also details about the issue that might impact the service. As a SaaS API, its important that we give good transparency into even minor blips in the service. Statuspage.io isn't as customizable as I would like it to be, but it makes it really easy for someone not on the dev team to manage communication while others fix the problem. Also, its hella straightforward to set up and use.
http://status.stormpath.com/
Typically I would have Nagios/ HP OpenView/ Unicenter/Tivoli monitoring my applications -- the application agent would page/text/email prod support whenever the app goes down and also it would automatically configure NGINX to redirect everyone to "ooops we are having technical dificulties" page.It wouldn't take more than a day to configure assuning you have Nagios/OpenView/Unicenter etc in place . This is pretty mundane stuff to implement. And that is why I don't get this service.