The Moodle 'cron' process is a PHP script (part of the standard Moodle installation) that must be run regularly in the background. The Moodle cron script runs different tasks at differently scheduled intervals.

IMPORTANT: Do not skip setting up the cron process on your server for your Moodle. Your site will not work properly without it.

It is recommended that the cron is run every minute, as required for asynchronous activity deletion when using the recycle bin.

The cron program (that runs the Moodle script) is a core part of Unix based systems (including Linux and OSX) being used to run all manner of time-dependent services. On Windows the simplest solution is to create a task in the Windows Task Scheduler and set it to run at regular intervals. On shared hosting, you should find the documentation (or ask support) how cron is configured.

Essentially, the task involves adding a single command to the list of cron activities on your system. On Unix based systems this list is a file called a 'crontab' which all users have.

General discussion

See the later sections for your server type; this section contains some general background information.

There are essentially two steps to implementing cron:

identifying the correct command to run

finding the right place on your system to put the command

Working out the Moodle cron command

Moodle has two different ways to deploy cron which use different scripts within the Moodle install. These are as follows...

The CLI (command line interpreter) script. This will be at the path

/path/to/moodle/admin/cli/cron.php

If in doubt, this is the correct script to use. This needs to be run by a 'PHP CLI' program on your computer. So the final command may look something like

/usr/bin/php /path/to/moodle/admin/cli/cron.php

You can (and should) try this on your command line to see if it works. WARNING: Check your command-line PHP version is compatible with your chosen version of Moodle. The command-line PHP program is different to the one running your web site and is not always the same version.

If, for some reason, you cannot run the CLI script there is the web based script. Note that this is now deprecated and may be removed in future versions. This needs to be run from a web browser and will be accessed via a web url something like http://your.moodle.site/admin/cron.php. You can find command line based web browser (e.g. wget) so the final command may look like

/usr/bin/wget http://your.moodle.site/admin/cron.php

This has the advantage that it can be run from *anywhere*. If you can't get cron to work on your machine it can be run somewhere else.

The web based Moodle cron command

If you have a choice, do not use the web based cron. It is likely to be removed in a future Moodle version.

From Moodle 2.9 onwards, the cron job can no longer be run from web by default. You will get an error message:

!!! Sorry, internet access to this page has been disabled by the administrator. !!!

You can change this in ' Dashboard ► Site administration ► Security ► Site policies ' by deselecting 'Cron execution via command line only'.

You will be warned that 'Running the cron from a web browser can expose privileged information to anonymous users. Thus it is recommended to only run the cron from the command line or set a cron password for remote access.'

You can then write a 'Cron password for remote access'. If this field is left empty, no password is required.

This means that the cron.php script cannot be run from a web browser without supplying the password using the following form of URL:

Finding the right place to put the command

This really does depend on the system you are using and you should find and read the documentation for your platform or hosting. In most cases getting the Moodle cron to run consists of establishing the correct command (above) and then adding it, and the time to run the command, to some sort of file. This might be either through a specific user interface or by editing the file directly.

If using the CLI version you also need to make sure that the cron process is run as the correct user. This is not an issue with the web version.

Using third party cron service

EasyCron - A webcron service provider that eliminates the need of crontab or other task schedulers to set cron job.

Cron settings in Moodle

An admin can set cron execution via command line only or a cron password for remote access in Administration > Site administration > Security > Site policies.

Remote cron

Using the 'web based' version of cron it is perfectly ok to place the cron process on a different machine to the Moodle server. For example, the cron service on a Unix server can invoke the cron web 'page' on a Windows based Moodle server.

Scheduling tasks

Running cron for several Moodle servers

Tasks can run in parallel and processes use locking to prevent tasks from running at the same time which allows cron to be triggered from multiple web servers that serve the same Moodle instance.

If you are running different Moodle instances on the same server, then each Moodle instance needs a cron job. (Even a single Apache web server can run different Moodle instances on different domains by using its virtual hosts capability https://httpd.apache.org/docs/2.2/vhosts/index.html.)

Debugging Scheduled Tasks

Sometimes, a particular cron task may not be working correctly. In Moodle versions before 2.7 - any cron task that was throwing exceptions would prevent the rest of cron from running. The only way to monitor if cron was completing each time, was to add some automated checking of the output of running cron (e.g. searching for the string "Cron completed at ").

In Moodle 2.7 and later, a single failing scheduled task will not prevent the remaining tasks from completing. When any single scheduled task fails, it is marked as a failure, and scheduled to be reattempted. If the task keeps failing, the next scheduled time will be backed off until it is attempted at most once every 24 hours. But checking the Scheduled tasks admin page, you can see if any task is currently failing (it will have a non-zero fail delay - which is the number of seconds to wait before reattempting a failed task). A simple way to debug a failing task, is to run it immediately using the cli scheduled task runner and monitor the output.