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.
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.
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.
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?
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.
That's a strong statement. Can you please elaborate?
Heroku is generally regarded as a reliable hosting solution. If it was a bargain basement alternative that was expected to fail randomly, then this would in fact be "clownshoes" downtime.
Building in full redundancy behind Heroku is possible, but non-trivial. They are after all being paid to provide a reasonably fault tolerant solution.
Therefore, while not literally unavoidable, it may not make good business sense for a venture to incur the additional expenses associated with implementing full redundancy. Most of their clients probably understand that downtime happens and will be perfectly content as long as every reasonable effort was made to keep the system online.
edited to add : Communication is key. Business relationships typically don't crumble due to aberrations like this (power outage, hosting provider going down, etc.). However, they do crumble if communication either doesn't occur, or the wrong information is conveyed. That is the crux of this discussion.
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.