Live data from Hacker News

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

blog.pardner.com

111–120 of 139 posts

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

#111

Earlier quoted context omitted.

you're missing the point what OP is complaining about is that when Heroku has an outage it says that there's an error within the client's application. I agree that it's the client's responsibility to have an up-and-running app, while the average user doesn't really care what's going on behind the scene, in this case Heroku is still giving out factually wrong and misleading information. I can imagine users will oftent…

I don't think so. I think you're missing the point. I think the point is that there is an error in the application. Heroku is part of the application, and the customer doesn't care. If you extend your line of thinking then you could put up error messages like "We're sorry, but this gosh darn database driver has totally let us down but we didn't write it so go complain to the people who did". > "...in reality there's…

A hundred times. You need a backup plan for if Heroku is out.

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

#112
post #71

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

This is a poor response: Abusive, insulting and makes only a token effort to advance the discussion. Does the fact that it sits at the top of the page mean that it's the most highly rated? And in practical terms, it seems totally theoretical. In my experience, more information is always valuable. It's not a matter of shifting responsibility, it's a matter of understanding what the problem is and efficiently getting i…

Please take a close look at the comment you replied to and your response. I think you'll see that you're feigning outrage, in an attempt to advance your own point of view.

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

#113

Earlier quoted context omitted.

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?

I don't know; but your comment suggests you're missing my point entirely. It's not about what each individual customer does; it's that implementing such a feature across the board might work well for Heroku customers whose own customers are technical; but, would fall down big time for those whose customers are non-technical.

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

#114
I think that for completeness, it should display a complete blame derivation graph that explains to the user the full chain of events, right back to the original person who was ultimately responsible.

After all, it wouldn't be fair for Heroku to be blamed just because a piece of networking equipment failed - the user should be informed which vendor is at fault, and in turn, which supplier the failed component within said equipment came from.

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

#115

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

Exactly! A customer could care less who you host with and what stack you use. The customer thinks one thing: if YOU are down, then YOU are down.

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

#116
at the end of the day, if you have a service that other people/businesses/clients rely on, that they need 24/7 up time, then you really need to have a plan B that is not on heroku or aws. a REAL disaster recovery plan needs to be thought out and implemented. if you dont want your users to see the "there is a problem with this app" on heroku, then its your job to figure out that plan B is. If you cant afford it a plan B, then well, tough shits. as someone that has worked in the hosting business for years on the operations side, its also the responsibility of the client to plan that scenario where your primary host is not reachable (regardless if its an application level issue, network or power outage). the hosting company can only build so many N+1 backups (network/power/etc) as they can afford/physically fit. you can buy all the load balancing you want, redundant web servers and database servers. if you arent hosting in a secondary place and your primary host fails, all those redundant servers you are paying for arent going to mean a damn thing.

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

#117
post #79
post #78

Earlier quoted context omitted.

My only gripe with the heroku app error page is it doesn't show your companies branding. I would like to be able to upload a static fail page with a generic message for my customers. Heck, let me specify a URL to redirect to when Heroku crashes.

This might help: https://devcenter.heroku.com/articles/error-pages#customize_...

response from the OP:

"Thanks, yes, but when the platform itself fails it seems that doesn’t always work. Hence my suggestion they temporarily change the default error message."

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

#120
post #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 wi…

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

What you say is true for a certain type of users and a certain type of business, but not for all the users and uses that a Heroku app might have - big companies, small companies, consumer sites, internal tools, iOS apps, etc. You have to assume a variety of use cases here, because that's kind of the whole point of a platform business.

What about when the user is your boss? "Hey, did you fuck this up?" is not a question people want to hear all day.

Or when it's an internal tool, and your users are a whole bunch of people who work with you?

Or when the site that went down is the system you use to invoice your consulting client, and they know you wrote it? Would you be anticipating repeat business?

A tiny portion of consideration for other people when you write your error messages can save those other people a great deal of stress. 37Signals wrote a book on that in around 2005 or so:

http://www.amazon.com/Defensive-Design-Web-improve-messages/...

It's short but it's good. (twss)

I think people are getting way too angry about this, and geeks get awfully weird (and often oddly furious) whenever you suggest employing simple social graces, but I also think it's indisputable that OP is absolutely right.

And to be fair, I didn't have any apps hosted on Heroku when this took place, so that might even be the reason why I think people are getting too angry about this. Maybe they're right to be mad.

"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?"

Because Heroku's not Rackspace. It's a service, and one thing people like from a service business is good service.

I like Heroku, it's awesome, but asking them to take responsibility for their downtime is a reasonable request.

Post reply on HN