11–20 of 139 posts
Heroku has a mechanism for displaying custom error and maintenance pages, served off of S3. https://devcenter.heroku.com/articles/error-pages#customize_...
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.
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)…
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)…
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.
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?
(With my developer hat on, Heroku outages are fun: our internal switchboard at http://www.pagerduty.com lights up like a christmas tree)
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)…
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.