Earlier quoted context omitted.
> All of the most talented engineers at Heroku left There are still plenty of talented engineers at Heroku. I used to do architecture work and support for enterprise customers and I knew the whole support team. Heroku support engineers are all devs or former devs; I am surprised at how passionate they can be about their work (ex: Jason, who STILL keeps the subreddit updated in his spare time). I do think there are si…
> I do think there are situations where support can't help, but those are usually situations where Heroku is probably not the right place to host a service. This hasn't been my experience at all. Mysterious performance issues are met with "We can't help, just install NewRelic" (the issues don't exist when running the same code on other services). Billing questions have yielded delayed and cryptic responses. Table sta…
Yeah, there are definitely details Heroku didn't have; for example, we only had something like the past 500 (or was it 100?) lines from a customer's logs; you would need to have an add-on to retain them.
There were no internal logs to consult about app performance; the New Relic install requests were probably to see if there is an issue related to the app. If the issue went deeper, we would work with the engineering team for the feature in question; but with the volume of tickets, we would have to categorically rule out an app issue first as 99% of issues happened while I was there. I think it is fair to say Heroku's support tried to embrace the "teach a man to fish" strategy, and that wouldn't work if the problem wasn't with the app.
I can't really speak to the billing issues, but that team was tiny; two or three people. I could definitely see them getting overwhelmed, and I heard about the lack of detailed billing support.
(Out of curiousity, were you using Heroku's docker product? I could definitely see that as having caused the sort of problems you mention as Heroku's docker platform was not vanilla docker.)