If you're viewing this at https://github.com/collectiveidea/delayed_job, you're reading the documentation for the master branch. View documentation for the latest release (4.1.9).

Delayed Job encapsulates the common pattern of asynchronously executing longer tasks in the background. Examples of such tasks include:

• Sending emails
• Image resizing
• HTTP downloads
• Updating smart collections
• Updating Solr, our search server, after product changes
• Batch imports
• Spam checks

Delayed Job 4.x only supports Rails 3.0+.

Delayed Job supports multiple backends for storing the job queue. See the wiki for other backends.

To use with Active Record, add delayed_job_active_record to your Gemfile.

gem 'delayed_job_active_record'

To use with Mongoid, add delayed_job_mongoid to your Gemfile.

gem 'delayed_job_mongoid'

Run bundle install to install the backend and delayed_job gems.

The Active Record backend requires a jobs table. You can create that table by running the following command:

rails generate delayed_job:active_record
rake db:migrate

To use Delayed Job with Active Job (Rails 4.2+), set the queue_adapter in config/application.rb:

config.active_job.queue_adapter = :delayed_job

See the Rails Guide for more details.

When using the protected_attributes gem, it must appear before delayed_job in your Gemfile. Otherwise you will see this error:

ActiveRecord::StatementInvalid: PG::NotNullViolation: ERROR:  null value in column "handler" violates not-null constraint

Call .delay.method(params) on any object and it will be processed in the background.

# without delayed_job
@user.activate!(@device)

# with delayed_job
@user.delay.activate!(@device)

If a method should always be run in the background, you can call #handle_asynchronously after the method declaration:

class Device
  def deliver
    # long running method
  end
  handle_asynchronously :deliver
end

device = Device.new
device.deliver

#handle_asynchronously and #delay take these parameters:

• :priority (number): lower numbers run first; default is 0 but can be reconfigured (see below)
• :run_at (Time): run the job after this time (probably in the future)
• :queue (string): named queue to put this job in, an alternative to priorities (see below)

These params can be Proc objects, allowing call-time evaluation of the value.

For example:

class LongTasks
  def send_mailer
    # Some other code
  end
  handle_asynchronously :send_mailer, :priority => 20

  def in_the_future
    # Some other code
  end
  # 5.minutes.from_now will be evaluated when in_the_future is called
  handle_asynchronously :in_the_future, :run_at => Proc.new { 5.minutes.from_now }

  def self.when_to_run
    2.hours.from_now
  end

  class << self
    def call_a_class_method
      # Some other code
    end
    handle_asynchronously :call_a_class_method, :run_at => Proc.new { when_to_run }
  end

  attr_reader :how_important

  def call_an_instance_method
    # Some other code
  end
  handle_asynchronously :call_an_instance_method, :priority => Proc.new {|i| i.how_important }
end

To call a handle_asynchronously'd method without Delayed Job, add _without_delay to the method name. For instance, if your original method was foo, then call foo_without_delay.

Delayed Job uses special syntax for Rails Mailers. Do not call the .deliver method when using .delay.

# without delayed_job
Notifier.signup(@user).deliver

# with delayed_job
Notifier.delay.signup(@user)

# delayed_job running at a specific time
Notifier.delay(run_at: 5.minutes.from_now).signup(@user)

# when using parameters, the .with method must be called before the .delay method
Notifier.with(foo: 1, bar: 2).delay.signup(@user)

You may also wish to consider using Active Job with Action Mailer which provides convenient .deliver_later syntax that forwards to Delayed Job under-the-hood.

Delayed Job supports assigning jobs to named queues. Each queue may be worked by a separate pool of workers, which may then be scaled and controlled individually.

Jobs can be assigned to a queue by setting the :queue option:

object.delay(queue: 'tracking').method

Delayed::Job.enqueue job, queue: 'tracking'

handle_asynchronously :tweet_later, queue: 'tweets'

You may configure a default priority for each queue (lower number = higher priority):

Delayed::Worker.queue_attributes = {
  high_priority_queue: { priority: -10 },
  low_priority_queue: { priority: 10 }
}

To override the queue's default priority, pass :priority to the delay method:

object.delay(queue: 'high_priority_queue', priority: 0).method

You can start processes to only work certain queues with the queue and queues options (refer to "Running Jobs" section below.) Processes started without specifying a queue will run jobs from any queue. To effectively have a process that runs jobs where a queue is not specified, set a default queue name with Delayed::Worker.default_queue_name and have the processes run that queue.

script/delayed_job starts a background daemon process which will continually work jobs.

To install this script, add gem "daemons" to your Gemfile then run rails generate delayed_job.

Then run the start command:

# Run a single worker as a background process
RAILS_ENV=production script/delayed_job start

# Run 4 workers in separate background child processes
RAILS_ENV=production script/delayed_job -n4 start

Each worker will check the database at least every 5 seconds.

You may use stop and restart commands. These commands wait for each worker to finish its current job before proceeding.

# Shutdown all workers and exit
RAILS_ENV=production script/delayed_job stop

# Shutdown all workers and start a single new worker process
RAILS_ENV=production script/delayed_job restart

# Shutdown all workers and start 4 new worker processes
RAILS_ENV=production script/delayed_job -n4 restart

You must pass the same arguments to restart that you used when calling start.

You may also send SIGTERM to stop Delayed Job.

# Set the --queues option to work from a particular queue
RAILS_ENV=production script/delayed_job --queues=mailers,tasks start

# Use the --pool option to specify a worker pool. You can use this option multiple
# times to start different numbers of workers for different queues.
# The following command will start 1 worker for the tracking queue,
# 2 workers for the mailers and tasks queues, and 2 workers for any jobs:
RAILS_ENV=production script/delayed_job --pool=tracking --pool=mailers,tasks:2 --pool=*:2 start

# Run as a daemon and exit after working all available jobs
RAILS_ENV=production script/delayed_job start --exit-on-complete

# or to run in the foreground
RAILS_ENV=production script/delayed_job run --exit-on-complete

The script/delayed_job process (described above) uses the Daemons gem which has several undesirable behaviors when running inside a container (Docker, etc.):

• The parent process spawns a background child process then exits immediately, which causes the container to shutdown.
• The worker processes are detached from the parent, which prevents logging to STDOUT.

The --fork option solves this by running workers in a foreground process tree. When using --fork the daemons gem is not required.

# Run as a foreground process with 4 worker child processes.
RAILS_ENV=production script/delayed_job --fork -n4 start

# Forking mode supports queues and pools.
RAILS_ENV=production script/delayed_job --fork --pool=mailers,tasks:2 --pool=*:2 start

When spawning two or more workers (-n2 or more), Delayed Job runs in "clustered" mode, which borrows its code and logic from the Puma webserver version 5+ ❤️. In summary:

• The parent process spawns a foreground child worker process ("worker 0").
• Subsequent workers are forked from worker 0, using copy-on-write forking.
• After a configurable timeout (default 1 hour), workers other than worker 0 are terminated and re-forked from worker 0, one-by-one. This "compacts"

Forking mode does not yet support the restart, stop, etc. script commands. This is planned to be introduced in the future. Use SIGTERM or SIGINT to allow workers to finish their current job then gracefully shutdown.

You may start a worker process using rake jobs:work. You can exit the rake task with CTRL-C.

To run all available jobs and exit, use rake jobs:workoff.

Set the QUEUES or POOLS environment variable to work specific queues.

# Start a worker listening to all jobs
rake jobs:work

# Run 4 worker processes and exit when all jobs are finished
NUM_WORKERS=4 rake jobs:workoff

# Work all jobs from the "mailers" and "tasks" queues, then exit
NUM_WORKERS=4 QUEUES=mailers,tasks rake jobs:workoff

# You may also specify POOLS pipe-delimited
POOLS=mailers,tasks:2|tweets:1|*:2 rake jobs:workoff

Rake uses Forking Mode (see above).

In development environment, Delayed Job will automatically reload your application code after each 100 jobs or when the queue finishes. You should not need to restart Delayed Job each time you update your code.

Jobs are simple ruby objects with a method called perform. Any object which responds to perform can be enqueued into the jobs table. Job objects are serialized to YAML so that they can later be marshalled by the job runner.

NewsletterJob = Struct.new(:text, :emails) do
  def perform
    emails.each { |e| NewsletterMailer.deliver_text_to_email(text, e) }
  end
end

Delayed::Job.enqueue NewsletterJob.new('lorem ipsum...', Customers.pluck(:email))

To override Delayed::Worker.max_attempts per-job, you can define a max_attempts instance method in the job class.

NewsletterJob = Struct.new(:text, :emails) do
  def perform
    emails.each { |e| NewsletterMailer.deliver_text_to_email(text, e) }
  end

  def max_attempts
    3
  end
end

To override Delayed::Worker.max_run_time per-job, you may define a max_run_time instance method in the job class.

NOTE: You may only set a max_run_time that is lower than Delayed::Worker.max_run_time. Otherwise the lock on the job would expire and a second worker would start working the same in-progress job.

NewsletterJob = Struct.new(:text, :emails) do
  def perform
    emails.each { |e| NewsletterMailer.deliver_text_to_email(text, e) }
  end

  def max_run_time
    120 # seconds
  end
end

To override Delayed::Worker.destroy_failed_jobs per-job, you may define a destroy_failed_jobs? instance method in the job class.

NewsletterJob = Struct.new(:text, :emails) do
  def perform
    emails.each { |e| NewsletterMailer.deliver_text_to_email(text, e) }
  end

  def destroy_failed_jobs?
    false
  end
end

To override Delayed::Worker.default_queue_name per-job, you may define a queue_name instance method in the job class.

NewsletterJob = Struct.new(:text, :emails) do
  def perform
    emails.each { |e| NewsletterMailer.deliver_text_to_email(text, e) }
  end

  def queue_name
    'newsletter_queue'
  end
end

On error, the job is scheduled again in 5 seconds + N ** 4, where N is the number of attempts. You may define a reschedule_at instance method to override this default behavior.

NewsletterJob = Struct.new(:text, :emails) do
  def perform
    emails.each { |e| NewsletterMailer.deliver_text_to_email(text, e) }
  end

  def reschedule_at(current_time, attempts)
    current_time + (attempts * 60).seconds
  end
end

You can define hooks on your job that will be called at different stages in the process:

NOTE: If you are using Active Job these hooks are not available to your jobs. You will need to use Active Job's callbacks. See the Rails Guides for details.

class ParanoidNewsletterJob < NewsletterJob
  def enqueue(job)
    record_stat 'newsletter_job/enqueue'
  end

  def perform
    emails.each { |e| NewsletterMailer.deliver_text_to_email(text, e) }
  end

  def before(job)
    record_stat 'newsletter_job/start'
  end

  def after(job)
    record_stat 'newsletter_job/after'
  end

  def success(job)
    record_stat 'newsletter_job/success'
  end

  def error(job, exception)
    Airbrake.notify(exception)
  end

  def failure(job)
    page_sysadmin_in_the_middle_of_the_night
  end
end

The library revolves around a delayed_jobs table which looks as follows:

create_table :delayed_jobs, :force => true do |table|
  table.integer  :priority, :default => 0      # Allows some jobs to jump to the front of the queue
  table.integer  :attempts, :default => 0      # Provides for retries, but still fail eventually.
  table.text     :handler                      # YAML-encoded string of the object that will do work
  table.text     :last_error                   # reason for last failure (See Note below)
  table.datetime :run_at                       # When to run. Could be Time.zone.now for immediately, or sometime in the future.
  table.datetime :locked_at                    # Set when a client is working on this object
  table.datetime :failed_at                    # Set when all retries have failed (actually, by default, the record is deleted instead)
  table.string   :locked_by                    # Who is working on this object (if locked)
  table.string   :queue                        # The name of the queue this job is in
  table.timestamps
end

On error, the job is scheduled again in 5 seconds + N ** 4, where N is the number of attempts or using the job's defined reschedule_at instance method.

The default Delayed::Worker.max_attempts is 25. After this, the job is either deleted (default), or left in the database with "failed_at" set. With the default of 25 attempts, the last retry will be 20 days later, with the last interval being almost 100 hours.

The default Delayed::Worker.max_run_time is 4.hours. If your job takes longer than that, another computer could pick it up. It's up to you to make sure your job doesn't exceed this time. You should set this to the longest time you think the job could take.

By default, it will delete failed jobs (and it always deletes successful jobs). If you want to keep failed jobs, set Delayed::Worker.destroy_failed_jobs = false. The failed jobs will be marked with non-null failed_at.

By default all jobs are scheduled with priority = 0, which is top priority. You can change this by setting Delayed::Worker.default_priority to something else. Lower numbers have higher priority.

The default behavior is to read 5 jobs from the queue when finding an available job. You can configure this by setting Delayed::Worker.read_ahead.

By default all jobs will be queued without a named queue. A default named queue can be specified by using Delayed::Worker.default_queue_name.

If no jobs are found, the worker sleeps for the amount of time specified by the sleep delay option. Set Delayed::Worker.sleep_delay = 60 for a 60 second sleep time.

It is possible to disable delayed jobs for testing purposes. Set Delayed::Worker.delay_jobs = false to execute all jobs realtime.

Delayed::Worker.delay_jobs may also be a Proc that decides whether to execute jobs inline on a per-job basis:

Delayed::Worker.delay_jobs = ->(job) {
  job.queue != 'inline'
}

In Daemonized mode, Delayed::Worker.raise_signal_exceptions = :term will cause the worker to raise a SignalException causing the running job to abort and be unlocked, which makes the job available to other workers. The default for this option is false.

In Forking mode, Delayed::Worker.raise_signal_exceptions set to any truthy value will raise an exception only on SIGTERM. Exceptions are not raised on SIGINT.

Here is an example of changing job parameters in Rails:

# config/initializers/delayed_job_config.rb
Delayed::Worker.destroy_failed_jobs = false
Delayed::Worker.sleep_delay = 60
Delayed::Worker.max_attempts = 3
Delayed::Worker.max_run_time = 5.minutes
Delayed::Worker.read_ahead = 10
Delayed::Worker.default_queue_name = 'default'
Delayed::Worker.delay_jobs = !Rails.env.test?
Delayed::Worker.raise_signal_exceptions = :term
Delayed::Worker.logger = Logger.new(File.join(Rails.root, 'log', 'delayed_job.log'))

You can invoke rake jobs:clear to delete all jobs in the queue.

Good places to get help are:

• Google Groups where you can join our mailing list.
• StackOverflow

Delayed Job is licensed under the MIT License.

Delayed Job was originally extracted from Shopify.

Code related to worker clustering is lovingly ❤️ borrowed from the Puma webserver