Need help with whenever?
Click the “chat” button below for chat support from the developer who created it, or find similar developers for support.

About the developer

8.5K Stars 707 Forks MIT License 535 Commits 86 Opened issues


Cron jobs in Ruby

Services available


Need anything else?

Contributors list

Whenever is a Ruby gem that provides a clear syntax for writing and deploying cron jobs.


$ gem install whenever

Or with Bundler in your Gemfile.

gem 'whenever', require: false

Getting started

$ cd /apps/my-great-project
$ bundle exec wheneverize .

This will create an initial

file for you (as long as the config folder is already present in your project).



command will simply show you your
file converted to cron syntax. It does not read or write your crontab file.
$ cd /apps/my-great-project
$ bundle exec whenever

To write your crontab file for your jobs, execute this command:

$ whenever --update-crontab

Other commonly used options include:

$ whenever --user app # set a user as which to install the crontab
$ whenever --load-file config/my_schedule.rb # set the schedule file
$ whenever --crontab-command 'sudo crontab' # override the crontab command

Note: If you run the whenever --update-crontab without passing the --user attribute, cron will be generated by the current user. This mean tasks that needs other user permission will fail.

You can list installed cron jobs using

crontab -l


whenever --help
for a complete list of options for selecting the schedule to use, setting variables in the schedule, etc.

Example schedule.rb file

every 3.hours do # 1.minute 1.week 1.month 1.year is also supported
  # the following tasks are run in parallel (not in sequence)
  runner "MyModel.some_process"
  rake "my:rake:task"
  command "/usr/bin/my_great_command"

every, at: '4:30 am' do runner "MyModel.task_to_run_at_four_thirty_in_the_morning" end

every, at: ['4:30 am', '6:00 pm'] do runner "Mymodel.task_to_run_in_two_times_every_day" end

every :hour do # Many shortcuts available: :hour, :day, :month, :year, :reboot runner "SomeModel.ladeeda" end

every :sunday, at: '12pm' do # Use any day of the week or :weekend, :weekday runner "Task.do_something_great" end

every '0 0 27-31 * *' do command "echo 'you can use raw cron syntax too'" end

run this task only on servers with the :app role in Capistrano

see Capistrano roles section below

every :day, at: '12:20am', roles: [:app] do rake "app_server:task" end

Define your own job types

Whenever ships with three pre-defined job types: command, runner, and rake. You can define your own with


For example:

job_type :awesome, '/usr/local/bin/awesome :task :fun_level'

every 2.hours do awesome "party", fun_level: "extreme" end

Would run

/usr/local/bin/awesome party extreme
every two hours.
is always replaced with the first argument, and any additional
are replaced with the options passed in or by variables that have been defined with

The default job types that ship with Whenever are defined like so:

job_type :command, ":task :output"
job_type :rake,    "cd :path && :environment_variable=:environment bundle exec rake :task --silent :output"
job_type :runner,  "cd :path && bin/rails runner -e :environment ':task' :output"
job_type :script,  "cd :path && :environment_variable=:environment bundle exec script/:task :output"

Pre-Rails 3 apps and apps that don't use Bundler will redefine the

jobs respectively to function correctly.

If a

is not set it will default to the directory in which
was executed.
will default to 'RAILS_ENV'.
will default to 'production'.
will be replaced with your output redirection settings which you can read more about here:

All jobs are by default run with

bash -l -c 'command...'
. Among other things, this allows your cron jobs to play nice with RVM by loading the entire environment instead of cron's somewhat limited environment. Read more:

You can change this by setting your own

set :job_template, "bash -l -c ':job'"

Or set the job_template to nil to have your jobs execute normally.

set :job_template, nil

Parsing dates and times

Whenever uses the Chronic gem to parse the specified dates and times.

You can set your custom Chronic configuration if the defaults don't fit you.

For example, to assume a 24 hour clock instead of the default 12 hour clock:

set :chronic_options, hours24: true

By default this would run the job every day at 3am

every, at: '3:00' do runner "MyModel.nightly_archive_job" end

You can see a list of all available options here:

Customize email recipient with the
environment variable

Output from the jobs is sent to the email address configured in the

environment variable.

There are many ways to further configure the recipient.

Example: A global configuration, overriding the environment's value:

env 'MAILTO', '[email protected]'

every 3.hours do command "/usr/bin/my_great_command" end

Example: A

configured for all the jobs in an interval block:
every 3.hours, mailto: '[email protected]'  do
  command "/usr/bin/my_super_command"

Example: A

configured for a single job:
every 3.hours do
  command "/usr/bin/my_super_command", mailto: '[email protected]'

Capistrano integration

Use the built-in Capistrano recipe for easy crontab updates with deploys. For Capistrano V3, see the next section.

In your "config/deploy.rb" file:

require "whenever/capistrano"

Take a look at the recipe for options you can set. For example, if you're using bundler do this:

set :whenever_command, "bundle exec whenever"
require "whenever/capistrano"

If you are using different environments (such as staging, production), then you may want to do this:

set :whenever_environment, defer { stage }
require "whenever/capistrano"

The capistrano variable

should be the one holding your environment name. This will make the correct
available in your

If both your environments are on the same server you'll want to namespace them, or they'll overwrite each other when you deploy:

set :whenever_environment, defer { stage }
set :whenever_identifier, defer { "#{application}_#{stage}" }
require "whenever/capistrano"

If you use a schedule at an alternative path, you may configure it like so:

set :whenever_load_file, defer { "#{release_path}/somewhere/else/schedule.rb" }
require "whenever/capistrano"

Capistrano V3 Integration

In your "Capfile" file:

require "whenever/capistrano"

Take a look at the load:defaults task (bottom of file) for options you can set. For example, to namespace the crontab entries by application and stage do this in your "config/deploy.rb" file:

set :whenever_identifier, ->{ "#{fetch(:application)}_#{fetch(:stage)}" }

The Capistrano integration by default expects the

variable to be set in order to scope jobs in the crontab.

Capistrano roles

The first thing to know about the new roles support is that it is entirely optional and backwards-compatible. If you don't need different jobs running on different servers in your capistrano deployment, then you can safely stop reading now and everything should just work the same way it always has.

When you define a job in your schedule.rb file, by default it will be deployed to all servers in the whenever_roles list (which defaults to


However, if you want to restrict certain jobs to only run on subset of servers, you can add a

roles: [...]
argument to their definitions. Make sure to add that role to the whenever_roles list in your deploy.rb.

When you run

cap deploy
, jobs with a :roles list specified will only be added to the crontabs on servers with one or more of the roles in that list.

Jobs with no :roles argument will be deployed to all servers in the whenever_roles list. This is to maintain backward compatibility with previous releases of whenever.

So, for example, with the default whenever_roles of

, a job like this would be deployed to all servers with the
every :day, at: '12:20am' do
  rake 'foo:bar'

If we set whenever_roles to

[:db, :app]
in deploy.rb, and have the following jobs in schedule.rb:
every :day, at: '1:37pm', roles: [:app] do
  rake 'app:task' # will only be added to crontabs of :app servers

every :hour, roles: [:db] do rake 'db:task' # will only be added to crontabs of :db servers end

every :day, at: '12:02am' do command "run_this_everywhere" # will be deployed to :db and :app servers end

Here are the basic rules:

  1. If a server's role isn't listed in whenever_roles, it will never have jobs added to its crontab.
  2. If a server's role is listed in the whenever_roles, then it will have all jobs added to its crontab that either list that role in their :roles arg or that don't have a :roles arg.
  3. If a job has a :roles arg but that role isn't in the whenever_roles list, that job will not be deployed to any server.

RVM Integration

If your production environment uses RVM (Ruby Version Manager) you will run into a gotcha that causes your cron jobs to hang. This is not directly related to Whenever, and can be tricky to debug. Your .rvmrc files must be trusted or else the cron jobs will hang waiting for the file to be trusted. A solution is to disable the prompt by adding this line to your user rvm file in



This tells rvm to trust all rvmrc files.


No. Heroku does not support cron, instead providing Heroku Scheduler. If you deploy to Heroku, you should use that rather than Whenever.


whenever-test is an extension to Whenever for testing a Whenever schedule.


Whenever was created for use at Inkling ( Their take on it:

Thanks to all the contributors who have made it even better:

Discussion / Feedback / Issues / Bugs

For general discussion and questions, please use the google group:

If you've found a genuine bug or issue, please use the Issues section on github:

Ryan Bates created a great Railscast about Whenever: It's a little bit dated now, but remains a good introduction.

Build Status

Copyright © 2017 Javan Makhmali

We use cookies. If you continue to browse the site, you agree to the use of cookies. For more information on our use of cookies please see our Privacy Policy.