Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Heroku don't hide this, it's in their documentation https://devcenter.heroku.com/articles/dynos#dyno-idling.

Imagine how many free apps are created that are never used again. Should Heroku really devote resources to these apps? I think it's perfectly reasonable to idle them after a period of inactivity. If they didn't, they would need more resources and ultimately the customers would be paying for that. They aren't a charity, they are a business.

It's pretty simple, if you don't want your app to idle out after 1 hour of inactivity, buy a dyno for $35 p/month.



From the documentation they "...will have that web dyno idled out after one hour of inactivity."

The issue is that there is no hour of inactivity because there is web monitoring/querying supposedly going on automatically. So there should be no idling.


They are trying to "cheat" the system by setting up automated pings to keep it alive. Do you really think that's in the spirit of the offering from Heroku? I don't know why it isn't working but I hope Heroku just "handles" that scenario.

Like I said, if Heroku did provide the resources for all these free apps (and there must be so many that aren't used) then that would be reflected in their pricing. I pay for Heroku and don't want to be paying more to compensate resources for their free apps.


I don't think it's in the spirit of the offering, but that's up to individual interpretation. What is very clear is that it doesn't seem to be behaving as documented. That's a problem.

Also, bgentry stated "We idle single-dyno apps that have not recently received requests. We do no caching." This also seems to contradict what is happening and adds to the confusion.

Why not just clarify what exactly is going on? It's completely reasonable to be handling this kind of situation however they are doing it, but it's not reasonable (IMHO) to repeat and support misleading/incorrect documentation.


Well, it's documented in the sense that the free web dyno is documented to spin down sometimes; if you pay $35/month for the extra web dyno, it ought not to.

This seems like a reasonable pricing model to me. And it seems reasonable to me that they don't document _exactly_ in what circumstances the free dyno might spin down on idle. Free is free.

If on the other hand even with the paid extra web dyno you were still getting ~10 second spin up times after idle, that would be something I'd get annoyed at too.

If you're willing to pay over $100/month on services you may or may not need just for the learning experience -- perhaps scale some of those back, and instead pay $35/month for the web dyno you do actually need to avoid the idle spin up time.

I do think it's true that heroku can end up being a lot more expensive than you initially expect for what you need, the extras can add up quick. This certainly can be frustrating. Even when you really are paying only for what you need, things can get expensive for a non-tiny app. But if you want to minimize your costs, you definitely want to avoid paying for add-ons you don't need.


I agree they should be transparent about how it works, no argument there.


Exactly. It's not a problem that Heroku has implemented such a system, but it is a problem that it's not disclosed. The details do not have to be spelled out, but the system should be documented.


He is paying over $100 per month though (due to addons). The issue is single web dyno idling so simply paying $35 a month won't do any good.


They have an "addon" called a dyno for $35 p/month that stops the idling. He didn't choose that one.

He has purchased other addons and is complaining he isn't getting the benefit from this one. Of course not.


I don't need another dyno. I'm already running way more than this app requires. (with addons, etc..) I think the service would be more fair if the time threshold for being set to idle was governed by the amount you are paying.


You are paying for 0 web dynos. They happen to be giving you one for free, but the free one comes with limitations.

Yes, you are paying for a bunch of other services; but, well, those services aren't the actual web dyno that processes the actual request.

Perhaps they could phrase their offerings better, but my impression was that the 1 free dyno with idling is intended for development and testing, not for production use. Once you actually need to use it in production, you need to pay for a dyno.


Yes, that was my impression also, especially since there's no limit on the number of free dynos you can have (for different projects). I was actually surprised to learn that when I looked into setting up a separate staging server for my current project -- I'd thought the free dyno was one to a customer. Nope. The staging dyno is free; I just have to wait a few seconds for it to spin up if I haven't been working with it for a while.

So now I have 3 dynos (2 production, one staging) for $35/month, I can scale up or down at will, deployment is dirt simple, and I don't have to do the sysadmin crap myself.

It's an extreme bargain, IMO.

Now if the project takes off to the point where I need dozens of dynos all the time, that will be different, but ideally in that case I could hire a sysadmin. :-)


I think it's much fairer that you can choose what you pay for. If you don't want it to idle, pay $35 and get a dyno. I wouldn't want to have to pay $100+ (or some other amount) before it stops idling.


The amount your paying and the performance you're experiencing are entirely dependent on your architecture priorities.


hedging your|you're grammatical bets using both forms :)


fair point.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: