Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
Heroku Scheduler now classified as "Best Effort" (heroku.com)
13 points by carsongross on April 29, 2013 | hide | past | favorite | 9 comments


Hate to pile on - but this the first time I've felt that Heroku is no longer a platform where I can "forget servers" and "focus 100% on the code". Setting up a different web server - okay fine, I can deal. I don't run a big app there (I pay under $50/month - most of that is for an SSL cert - but I do pay) but now I have to run something called a "clock process" to send a weekly digest email (with guarantees that it will actually send).

Not happy about this change.

Guess I'm glad I can run DelayedJob in a unicorn worker, but Heroku is no longer `git push` and go in my mind.


Unfortunately, I've noticed quite a few failures with it in our apps, so we are probably going to port to something else.

Kinda funny that the solution here is to pay for a dyno that will be sitting there doing nothing and then getting nuked fairly regularly. Seems like an opportunity for a startup: a reliable cron-like service for the cloud. Maybe web-hook based? A quick google didn't turn up any.

Aaaaaand go.

(Don't take this the wrong way, herokueans: I love you. Deeply.)


You can trivially make one with a secondary Heroku app that runs a single non-web dyno running the clock process of your choice, making http calls to your primary app.

edit: Please note that this could be against the Heroku terms of service.


Well, I'd pay, say, $10 a month for a service that was simple, offered some retry algorithms, logged responses, gave me a nice UI for the whole thing and worked reliably (unlike dynos on Heroku, which are nuked regularly.)

Not rocket science, to be sure, but I'd rather not build and maintain the infrastructure.

Or I'd rather build and maintain only that infrastructure.


Now you've got me thinking. If you're serious send me an email (in my profile) and let's talk.


This is essentially how App Engine does scheduled jobs. You define the schedule and give it an endpoint in your app to hit. The tricky part with this is that all the limits that come with web requests are imposed on your jobs which may be a problem.



Recently left Heroku, too many failures. The last week I had my app on Heroku availability was in the realm of ~60-80%.

Between that and the obscenely slow and overpriced Postgres...nope.

(Clojure user, I don't think Heroku's platform plays nice with things that take a bit to fire up. Or the JVM in general.)


It's interesting how the whole PaaS movement has begun to resemble a more traditional development and operational split, as devs who thought they were finally escaping from the tyranny of systems administration and design find themselves forced back into taking such things into consideration when building their apps.




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

Search: