Live data from Hacker News

Dear Heroku: Quit blaming all of us when you fail. Do this instead…

blog.pardner.com

61–70 of 139 posts

Re: Dear Heroku: Quit blaming all of us when you fail. Do this instead…

#62
This is misguided. Nobody cares why your site is down, and for most sites 99% of your users will have no clue what is meant by "This site is hosted by Heroku". And a good chunk of that other 1% isn't even going to bother reading the error text accompanying the whitescreen.

In the end, you chose to host your site on a platform that went down. That is just as much your fault as a typo in the code. If you had a setup with a hosted machine at Rackspace and the power goes out, you don't expect a custom error. So why would you expect one from Heroku?

Re: Dear Heroku: Quit blaming all of us when you fail. Do this instead…

#63
post #20

Earlier quoted context omitted.

Frankly, I believe it certainly can matter. It may not make any difference to all clients, but some will draw a distinction between avoidable / unavoidable downtime. Rational clients understand they are not hiring demigods or living in some uptime utopia. However, they expect their service providers to adhere to best practices and make logical decisions. In this case it's Heroku, in another setting it might be a NetA…

I believe you're looking at this issue through the eyes of a technical person who understands those distinctions. There's a huge group of sites and apps catering to entirely non-technical folks to whom that distinction would only bring confusion. For a software bug tracking app, I can see why you'd want this. For a store that sells something like cloth diapers, I think it would be confusing (at absolute best) and cer…

But how do you know what kind of users Heroku's customers' customers are? How do you know that none of them are technical users? How do you know that none of Heroku's customers are running a software bug tracking app?

Re: Dear Heroku: Quit blaming all of us when you fail. Do this instead…

#64
post #45

Bullshit. It's your fault. I'm your user, you took my money. We're done here. Everything is your fault.

Continue in that vein, then if there is a natural disaster then it is their fault as well. The information is useful. Heroku should provide it. We're done here.

It is absolutely your fault if the site does down due to natural disaster. This is why companies who are large enough to do so host the site at multiple locations with the ability to failover.

Re: Dear Heroku: Quit blaming all of us when you fail. Do this instead…

#65

Bullshit. It's your fault. I'm your user, you took my money. We're done here. Everything is your fault.

If you want to look at it that way, in most cases it's the customer's fault, because they don't want to pay what it would require to have a fully redundant system that could weather certain kinds of outages.

You get what you pay for.

Re: Dear Heroku: Quit blaming all of us when you fail. Do this instead…

#66

Why do you care? Do you think this helps your customer at all? Perhaps you're worried about your technical reputation. All you're doing is moving the blame to some part of your code to the decision you made to host on Heroku. Down is down. Unavailable is unavailable. To your customers that's all that matters. For what it's worth I think hosting on Heroku makes plenty of sense and I'm actually moving my app (Crisply)…

Well said; I'd even take it a step further and say that your customers (unless your customers are technical folks) have absolutely no idea about the distinction anyway. Saying that it's hosted on Heroku means nothing to them. Moreover, there may be companies hosting on Heroku who insist that the service is "white label" for any number of reasons; forcing something like onto them would devalue Heroku to those companie…

unless your customers are technical folks

But Heroku can't know if the customer of their customers are technical folks or not and neither can you. Some people do care, the OP for example seems to care and we can assume thats because his customers do in fact care (only the OP can decide if his customers care or not).

Re: Dear Heroku: Quit blaming all of us when you fail. Do this instead…

#67
post #60

Bullshit. It's your fault. I'm your user, you took my money. We're done here. Everything is your fault.

not always true, as a freelance dev I tend to give options to my clients so they end up owning their hosting, something happens I'm authorized to get in and contact support, but I always make it clear to them they are responsible for it

Wow, totally. Really good point. In this situation your client is a hosting user and the distinction between the error messages makes loads of sense.

Re: Dear Heroku: Quit blaming all of us when you fail. Do this instead…

#69
post #65

Bullshit. It's your fault. I'm your user, you took my money. We're done here. Everything is your fault.

If you want to look at it that way, in most cases it's the customer's fault, because they don't want to pay what it would require to have a fully redundant system that could weather certain kinds of outages. You get what you pay for.

Bullshit again. Most customers think they have paid for a fully redundant system... unless I missed a recent wave of conversion funnels that included a message about how the reason it's only 9$ a month is because it might go down, like, whenever.

But you're right about the second part. You get what you pay for... unfortunately that's often different than getting what you bought.

Re: Dear Heroku: Quit blaming all of us when you fail. Do this instead…

#70
post #24

As someone who was inconvenienced by the outage, and with no mitigation strategy in place, I DON'T blame Heroku. The weight is placed squarely on me (lone tech in our company) for not having researched how to distribute services alongside Heroku, or fall back to something else, or whatever the proper term is. I've been googling like mad since this morning, finding a few mostly-unanswered StackOverflow questions and a…

The cost of running your own infrastructure at this level is slower development and ongoing hassle, vs. Heroku.

Unless your application absolutely must be up with higher availability than Heroku provides, it's probably not worth the effort. The easiest thing to do is to use something like Cloudflare in front of Heroku, so at least when Heroku is down, you can serve a static page to customers informing them of the problem and estimated time to fix.

Post reply on HN