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

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.<p>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?

Why do you care? Do you think this helps your customer at all?<p>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.<p>Down is down. Unavailable is unavailable. To your customers that's all that matters.<p>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.

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

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

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.<p>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:<p>1. Hire a sysadmin who knows more than you do (But whole point is that I want to learn for myself!).<p>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.<p>3. A few mentions of "load balancers" and "heartbeat monitors". Sounds self-explanatory, and these are my current terms of googling.<p>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.<p>EDIT: Well, just watching this thread is helping a bit.

Heroku has a mechanism for displaying custom error and maintenance pages, served off of S3.<p><a href="https://devcenter.heroku.com/articles/error-pages#customize_pages" rel="nofollow">https://devcenter.heroku.com/articles/error-pages#customize_...</a>

From a customer's perspective, there are only two parties in their relationship with you: you, and them. When something goes wrong with your application, you either accept the blame, or you make the customers feel like they broke something. To the average user, seeing an error message like "heroku is down" (or any other jargon) leaves the possibility that they might have broken something, and the failure is on their end. The end result of this interaction is that <i>your software has made your user feel bad about themselves</i>. This is not a way to get your users to return to you.<p>Heroku's error message could be friendlier, but it currently contains only words that any user can understand, which reassures your customers that even though the service they are looking for is unavailable, there is nothing they could have done to improve the situation. Your customers might leave with a lowered opinion of your service, but your app doesn't make them feel ashamed of themselves, which is a much better outcome.

If we put our normal-user-hat on for a minute: I don't see how that would make any difference for 90%+ of users. They'll see the website isn't working, but another site is, so your site is broken. End of story.<p>(With my developer hat on, Heroku outages are fun: our internal switchboard at <a href="http://www.pagerduty.com" rel="nofollow">http://www.pagerduty.com</a> lights up like a christmas tree)

Heroku isn't for apps that can't stand downtime. My experience has been that if you have 2-3 heroku apps, and you monitor them with a 3rd party tool, you'll see random "server not found" behavior every few weeks. (And no, they're not just timing out from dyno spinup). Usually this isn't a system wide outage and never gets mentioned on their status page.<p>So only use heroku if:<p>a) Uptime is non-critical &#38; you just don't want to deal with setting up a server b) Uptime is non-critical &#38; You don't know how to set up a server

You can customize the error page. It is your fault for not reading the docs and serving the default.<p><a href="https://devcenter.heroku.com/articles/error-pages#customize_pages" rel="nofollow">https://devcenter.heroku.com/articles/error-pages#customize_...</a>

I don't want my users to know I use Heroku, and by using Heroku I understand that if they go down my site goes down. It really is "our" problem at that point with regards to how our users understand it.

If Heroku is down, and I discover that site X that I want to visit was hosted on Heroku, I'm more likely to hear that Heroku is back up <i>or</i> that site X is back up, than just that site X is back up. I also can skip checking any other sites I know to be using Heroku during the outage. It is therefore mildly useful data to a user.

Add a custom 500 error page, problem sovled, you can make it say anything you want.

It’s your fault for not having a fault tolerant site that runs on another service provider. This is what happens when you put your eggs in one basket and that basket bursts into flames.<p>If reliability is so important, make it a priority instead of just expecting stuff to work or for a more politically correct error message — which leads me to my next point: who cares about the ERROR message? The damage has been done by that point and half the people won't bother to read any further. Queue sounds of people clicking back buttons as fast as they can.

This seems specious. Correctly assigning blame won't matter to readers; most people couldn't care less. Sticking a different brand name on the failure is side-stepping the issue: nothing stays up 100% of the time. Create a custom page that treats the situation with a little bit of levity.<p>If legitimate downtime happens often enough that someone would <i>actually</i> internalize the difference between your failures and Heroku's, you have bigger problems than your error page.

Quite off topic, but I'm always sad to see really poor scalability:<p><i>To my surprise, this blog post hit the top spot on HN at least briefly. My blog started throwing some app errors.</i><p>I've had a couple of hit HN stories on my blog without a problem, and it was hosted from my apartment on an old server with 256MB of RAM. Now, it is static pages served through nginx, but I'm pretty sure that a few thousand hits shouldn't require 10 Heroku dynos to not fall over.<p>Kids these days. (the mindset, not the age)

I've seen so much blame in IT/systems/coding in the last 15 years that I can't recount it all. Anytime a vendor or service provider or consultant is involved, get ready for finger pointing when things go wrong (from both sides). I think many managers like being able to blame them and see this as a benefit of the relationship. Outside providers should just expect to be blamed for things they did not do and charge for that accordingly.

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

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.

We know when Heroku is down cause our emails from client's app drown our inboxes, and our clients get pounded by their clients.<p>I think it would be ideal to allow you to customize these messages to make things easier, but I can't imagine the infrastructure they would need to have in place to support this.<p>The option presented by the article is lot simpler.

A gentle reminder: <a href="http://whoownsmyavailability.com/" rel="nofollow">http://whoownsmyavailability.com/</a>

Many companies I know would immediately fire a service provider for ever disclosing their existence to an end customer. If anything, Heroku's customers should be able to replace the default error message such that it conforms to the the customer's site branding.

You can customize your error pages to be whatever you want.<p><a href="https://devcenter.heroku.com/articles/error-pages#customize_pages" rel="nofollow">https://devcenter.heroku.com/articles/error-pages#customize_...</a>

They ought to create an interface for serving up a custom 500 error page.

What if the problem only affects a subset of users? Then wouldn't any application errors for unaffected users (e.g. a typo in code) say it is Heroku's fault when it really isn't?

It may be difficult from a platform for them to tell where the outage is exactly.<p>Also I don't think they should tell everyone heroku is hosting it so I don't think that is a good solution.

All this ruckus for 18 mins of downtime? Moved my main app off heroku this monday for various reasons (mainly to get better log access and to run the app in europe).

The only change I would make, if any, is to remove the sentence about being the application owner. Aside from that, that's all I'm going to tell a customer anyway.

This is what a culture of pointing fingers leads to. The author should realize the customer does not care why the site is down.

"throw more dynos at it"<p>You kids and your lingo these days....<p>/back in my day/ we used to have servers. REAL, PHYSICAL servers :)

Does Heroku not have custom ErrorDocumenrs? We had those in the 90's...

Isn't it your fault to have picked Heroku in this case?

Or you could get on Engine Yard and stop caring what Heroku does. That's worked wonders for my business.

Or you could get on EngineYard and stop caring what Heroku does. That's worked wonders for my business.

Wow, didn't know that (don't use Heroku). Good article. Good solution.