Hacker News Reader

Comment by tg3 | Hacker News Reader

Their uptime percentage is 99.97%, but I'm having a hard time fighting the recency effect that is telling me to get off the platform ASAP.

View on HN

That was their uptime for May, but looking at June it's going to be a worse picture. They're already down to 99.63% if you only include "red" incidents and down to 99.25% if you include "amber" incidents as well (as of 39m of downtime for this latest incident and assuming they don't have any more downtime for the month).

That's 99.97 for the last month.

Which is ridiculous, 9s for most services use years as standard. Of course if heroku did that they wouldn't look so good.

if you have a year of 99.97 months, don't you have a 99.97 year? how does having a shorter time make the numbers look better?

[edit: i realise they could be hiding worse months, but i don't think that's what the post i am replying to meant. perhaps i am reading it wrong.]

They could have terrible uptime 2 months ago and you wouldn't see it in their status page, because it only showed last month's.

Depends on the month...

31 versus 28 days.

They could have done it to the extreme -- show the numbers for the past hour. Then they could almost always report 100% uptime. And if they ever went down, wait an hour, then go back to reporting 100% uptime again.

Parent post was saying that, without taking into account the entire year, you can have one month that is terrible and the rest quite good.

The measurement in question is supposed to be about consistency.

It doesn't matter whether gauged by the month or year. It's a percentage. If they have 99.97% uptime every month for a year, they'll still have 99.97% uptime for the year.

Or if they have 100% for six months and then 99.97% for one month the long-term average would be better.

I just got up (it's morning in Israel), and a client of mine in the US with a major, mission-critical application was screaming (rightly so) that things are down.

We're already looking into alternatives -- perhaps not leaving Heroku altogether, but certainly not depending on them 100 percent. There's no way that we can entrust the business to something that can just catastrophically fail at any moment. I've been running my own servers for years, and they've never had such unpredictable issues.

I increasingly have to think that a few servers, on different providers, with the application deployed via Capistrano, will be more fault-tolerant than Heroku. At least, it seems that way right now.

Dont overreact... heroku is using AWS which is down for many other sites right now other than heroku. This is an EBS issue that is occurring.

And my guess is his client doesn't give two excrements what the reason is. It's boolean to them; it's up or it's down.

I know AWS EC2 does support multiple global regions and within each region multiple availability zones. You're supposed to host your application across more than one AZ if you want good fault tolerance. Not sure if Heroku uses this though.

> There's no way that we can entrust the business to something that can just catastrophically fail at any moment.

Anything, including service providers, can catastrophically fail at any moment. Fault-tolerant architectures are based on redundancy (including infrastructure provider redundancy, as you mention), not on "guaranteed" SLAs.

Provider redundancy goes against the concept of PaaS IMO (ignoring the sci-fi future where there are multiple 100% compatible providers). Heroku needs to become internally redundant to really live up to its promise.

Reply on news.ycombinator.com