Generally one runs defined cron jobs on a schedule set in advance. This allows you to queue up arbitrary methods to fire at arbitrary times, generally "a short while after this HTTP request has been dealt with."

This is an extraordinarily common pattern in web applications. My Rails apps do it hundreds of thousands of times per day, often to avoid hitting an external API during a request/response cycle. (I use Delayed::Job. This would not be my #1 recommendation for this pattern in 2014. Take a look at Sidekiq, Resque, or this new thing instead.)

Just to pile on to the answers. Cron is for scheduling work, delayed jobs are for out of band work.

For instance:

* Use cron to dump a database backup nightly

* Use some job system to send a user an email after they sign up

There's a lot of overlap, and if used cleverly (which may not be smart), they can both achieve the same goals.

To give an example let's say you have a mailing list with 1000 people and you want to send out notification. You push "notify " button, but you don't want to wait for your app to go through 1000 people and send them email until it responds again. You also don't want to wait until midnight for crontab to start processing all requests.

Background jobs takes that 1000 deliveries job and puts it into the background queue, then a worker starts sending those emails right away. Meanwhile your app returns from your request instantly so you can continue doing what you were doing while the job is executed in the background.

It just has nothing to do with cron.

Cron is a POSIX task scheduler, this is a Ruby normalized API for background job systems.

Another thing to bear in mind is that cron won't have access to your Rails environment per default. If for example you used cron to call a rake script which needed the Rails environment, you would be loading the Rails env every time, which is pretty heavy.