5 ms·

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 t

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) to Heroku so that my technical team spends less time writing chef scripts, less time managing database clusters and more time adding value. But when Heroku goes down my customers will be just as screwed.

deleted 14y ago
[deleted]
bcrescimanno 14y ago
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 companies.
- dkersten 14y ago
  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).
doktrin 14y ago
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 NetApp filer. Both are reasonable solutions in their appropriate environment, yet both may fail. There's a significant difference between downtime caused by the failure of a reasonably trusted solution as opposed to that due to design flaws, bleeding edge prototyping and flat out bad decisions. The former wouldn't undermine my faith in a service provider, while the latter certainly might.
- bcrescimanno 14y ago
  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.
  - doktrin 14y ago
    That's correct. I certainly am not pretending to speak for all consumers in all situations, which is why I stated it can matter. My primary point was that since it can matter, the information should be presented. An underlying assumption being that it can't hurt, but could help. However, you brought up a point I hadn't fully considered : namely that this information could be directly confusing to some users and by extension undermine their faith in their service provider. That said, I think the sample error message in the OP is sufficiently clear for the broad spectrum of users. Therefore, I believe presenting users with that message, or something similar, would do more good than harm.
  - dkersten 14y ago
    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?
    - bcrescimanno 14y ago
      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.
- adgar 14y ago
the_bear 14y ago
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.
- deleted 14y ago
  [deleted]
- deleted 14y ago
  [deleted]
- seanp2k2 14y ago
  >"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." So I guess no one has ever loosed up a firewall rule when something was down to try to get it back up again, providing a perfect opportunity for someone with, let's say, stolen MySQL credentials to connect to your now-exposed DB. >"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." And they're losing just as much business because /their/ site/service is now broken too. That is plenty of reason to get mad at you guys, since to them, /you are the total solution/. >"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." Maybe, but then I'd just say "wow, so you have really bad planning and expect that this stuff is all very reliable then, no?" The internet goes down. Power goes out. Expect it and build around it. >"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." Yes, because I fully expect IBM to resolve my issue faster than a mom-and-pop store. If anything, that would make me /more/ anxious. Ever had to call Level3, Cogent, or ATT for a null route? It takes us ~1 minute and them at least 20, sometimes much longer.
deleted 14y ago
[deleted]
eric-hu 14y ago
Suppose some of your customers see an error message and report it. You could deliver valuable uptime to them that much faster when you know it's a bug in your code and not Heroku. When you know it's Heroku, you can deliver valuable uptime to your customers faster because you don't have to spend time testing for bugs and checking server logs--jumping straight to what you would do: contacting Heroku. Your customers won't be just as screwed--3 hours of down is not the same as 6 hours of down.

deleted 14y ago

[deleted]

bcrescimanno 14y ago

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

dkersten 14y ago
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).

doktrin 14y ago

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 NetApp filer. Both are reasonable solutions in their appropriate environment, yet both may fail. There's a significant difference between downtime caused by the failure of a reasonably trusted solution as opposed to that due to design flaws, bleeding edge prototyping and flat out bad decisions. The former wouldn't undermine my faith in a service provider, while the latter certainly might.

bcrescimanno 14y ago
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.
- doktrin 14y ago
  That's correct. I certainly am not pretending to speak for all consumers in all situations, which is why I stated it can matter. My primary point was that since it can matter, the information should be presented. An underlying assumption being that it can't hurt, but could help. However, you brought up a point I hadn't fully considered : namely that this information could be directly confusing to some users and by extension undermine their faith in their service provider. That said, I think the sample error message in the OP is sufficiently clear for the broad spectrum of users. Therefore, I believe presenting users with that message, or something similar, would do more good than harm.
- dkersten 14y ago
  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?
  - bcrescimanno 14y ago
    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.
adgar 14y ago

the_bear 14y ago

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.

deleted 14y ago
[deleted]
deleted 14y ago
[deleted]
seanp2k2 14y ago
>"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." So I guess no one has ever loosed up a firewall rule when something was down to try to get it back up again, providing a perfect opportunity for someone with, let's say, stolen MySQL credentials to connect to your now-exposed DB. >"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." And they're losing just as much business because /their/ site/service is now broken too. That is plenty of reason to get mad at you guys, since to them, /you are the total solution/. >"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." Maybe, but then I'd just say "wow, so you have really bad planning and expect that this stuff is all very reliable then, no?" The internet goes down. Power goes out. Expect it and build around it. >"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." Yes, because I fully expect IBM to resolve my issue faster than a mom-and-pop store. If anything, that would make me /more/ anxious. Ever had to call Level3, Cogent, or ATT for a null route? It takes us ~1 minute and them at least 20, sometimes much longer.

deleted 14y ago

[deleted]

eric-hu 14y ago

Suppose some of your customers see an error message and report it. You could deliver valuable uptime to them that much faster when you know it's a bug in your code and not Heroku. When you know it's Heroku, you can deliver valuable uptime to your customers faster because you don't have to spend time testing for bugs and checking server logs--jumping straight to what you would do: contacting Heroku. Your customers won't be just as screwed--3 hours of down is not the same as 6 hours of down.