Live data from Hacker News

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

blog.pardner.com

21–30 of 139 posts

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

#21

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)…

In my experience, users actually do care quite a bit. Back when my company was on Rackspace, we had several periods of significant downtime that weren't our fault. Customers who contacted us were very upset, but when we made it clear that it wasn't a bug with our software, but rather a problem with the hosting provider, they all calmed down. I believe there are at least a few key things a customer takes away from a message like that, even if they don't understand anything about website hosting:

1) This isn't a bug with our software. They don't need to worry about the security of their data or anything else like that.

2) There's no point in getting mad at us. Sure we chose our hosting provider, but we're just as upset about the downtime as the customer is.

3) This problem is affecting other websites as well. People seem to be better at handling stress if they think everyone else is stressed out too.

4) There's a team of professionals working on the problem. My customers know I run a small company, and they seem to appreciate knowing that a much larger company handles the hosting.

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

#22
post #15

I don't think the OP is right in general. What if your customer sees Heroku's name, and gets confused? She starts asking questions like: Who is on the other end? Am I in business with X or with Heroku? Who should i call?

This is actually a really good point. I can't find it now, but there's an article floating around somewhere about a government employee in some small town accusing Apache or Debian or some project of being "hackers" because his web server broke and was showing the default "congrats it works!" page instead of the town web site.

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

#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 smattering of blog posts, but I haven't learned much. The only clear-cut answers I've seen are:

1. Hire a sysadmin who knows more than you do (But whole point is that I want to learn for myself!).

2. Pay for a service that will host in multiple geographic locations for you, and do the switchover (recovery? fallback? I don't know my terms here) for you.

3. A few mentions of "load balancers" and "heartbeat monitors". Sounds self-explanatory, and these are my current terms of googling.

Any suggestions on where to start acquiring this sort of skill? I'm prepared to teach myself anything, but the problem is not knowing the terms for what I want to learn.

EDIT: Well, just watching this thread is helping a bit.

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

#26
post #20

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)…

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 certainly not any kind of improvement for either Heroku's customer or their customer's customer.

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

#27

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)…

[deleted]

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

#28

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

Actually I do not disagree.... I make the platform choices, so i live with the results. However, IMO an error message that distinguishes between an "hosting" issue and an "app" issue is not only fair, it is in fact, meaningful data to (at least some) customers.

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

#29
post #22
post #15

I don't think the OP is right in general. What if your customer sees Heroku's name, and gets confused? She starts asking questions like: Who is on the other end? Am I in business with X or with Heroku? Who should i call?

This is actually a really good point. I can't find it now, but there's an article floating around somewhere about a government employee in some small town accusing Apache or Debian or some project of being "hackers" because his web server broke and was showing the default "congrats it works!" page instead of the town web site.

That's not an isolated occurrence. Most Web projects get it all the time from randoms, sometimes completely unaffiliated with the site in question.

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

#30
post #15

I don't think the OP is right in general. What if your customer sees Heroku's name, and gets confused? She starts asking questions like: Who is on the other end? Am I in business with X or with Heroku? Who should i call?

Just don't mention Heroku by name. "Webhost" or something is enough. I'm in two minds about the whole thing though.
Post reply on HN