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?
"99% of your users will have no clue what is meant by "This site is hosted by Heroku""
Couldn't agree more.
Further I wouldn't want anyone to know where the site is hosted anyway. We have some customers on a VPS at Media Temple and use custom dns so they don't see MT's dns servers (which of course they could find out if they want to check the IP obviously). They don't need to know that info. As far as they are concerned we are the vendor.
The message could simply say "We are having technical difficulties and we're working to get the service restored as quickly as possible".
I don't think anyone should take it upon themselves to say "Nobody cares" about the relevant details of an error. It's not just an issue of blame, but what the end customer can do with the information. The information that it is the platform that failed temporarily is useful for the end customers because they don't have to lose too much confidence in the software vendor because their code is failing. It lets the customers know the problem is probably temporary. Customers do care because a lot of them can interpret that level of error detail, and it is actionable, useful information to them. Heroku should at least give developers the option of finer grained error messages.
>In the end, you chose to host your site on a platform that went down.
That's only partially true, there are limited viable options for platform hosts out there, and virtually no one has cracked the 100% up-time challenge, so there isn't any degree to which a software developer could choose a host with 100% up-time if it doesn't exist. Thus they're not at fault for choosing the "wrong" host or not creating something that is astronomically difficult themselves.
"The information that it is the platform that failed temporarily is useful for the end customers because they don't have to lose too much confidence in the software vendor because their code is failing."
You're failing to understand that the overwhelming, vast majority of people have no idea what half the words in your sentence meant, have no idea what idea you're trying to convey, and even if they understood the idea, wouldn't be able to get it from your sentence.
Nobody cares whether it's a bug in your code or your host going down, because 99% of people don't know the difference.
I think that business customers do care quite a bit, actually. If, for instance, your business customer experiences significant downtime, but loves you otherwise, a verifiable explanation as to the source of that downtime can be the difference between keeping that customer or loosing that customer.
If the customer attributes the downtime to your host rather than you, then your customer might tell you to switch hosts rather than fire you. If you have a good relationship, the added transparency can be the difference between keeping the customer and loosing the customer.
Of course, this line of thinking is no incentive for heroku to change its practices.
When our service is down for some reason, the ONLY question we get (like this one we got today) is - "Has the service been down recently? If so, no worries - it happens, just wanted to report and see if this is temporary or if it is just me."
Having a "holy shit our entire service is down" message means your users dont' have to ask "is it just me?".
That's a big difference. It has nothing to do with shifting blame, it's about keeping your users informed. Information makes people happy.
Yes, information does make people happy. And my point is that a message that says "this site is hosted at Heroku" gives absolutely zero information to the vast majority of internet users. Most people simply don't know what that phrase means. It's no different than if someone suggested a new feature that is only visible for Opera users. It's just a waste of time and effort to do something that caters to such a small sliver of the market.
Also, a Heroku-specific error page would give zero help to the problem you describe above. Anecdotal evidence in this thread suggests Heroku sometimes goes down briefly for small chunks of its users. So if you see the Heroku error, it could be for just you. Or it could be system-wide outage. It wouldn't even solve that problem!
Showing enough information for your users to sensibly understand what they should do is important, but thats not what the article was about[1], it was about the application developer wanting to pass-the-buck when there application failed because of a Heroku error.
This is really lame because, you chose to host on Heroku not your customers, so it is your fault. You can play pass-the-buck but as far as your customers are concerned it is your fault.
You say "pass the buck" I say "tell the truth." Heroku's current message says it's an "application error" even when it is not an application error. It is incorrect. And I suggested one simple way to correct it. They could word the message as they see fit, but platform_problem != application_error. What percent of customer grok/care about the difference is irrelevant... an incorrect error message should be corrected.
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.
> 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 you pay them to be a platform? (As apposed to paying rackspace for some hardware to run things youself)
This is exactly the same stance that allowed Netscape to win the browsers wars initially by being more user friendly. Arrogant and 'misguided' technical people wanting to see developers shamed for not conforming with strict HTML standards. They instead took it out on the end user.
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?