Cron
Cron runs Drupal's scheduled jobs. The Automated Cron module starts it every three hours by default; a server job or Drush can start it instead.
Cron is the mechanism that runs Drupal's periodic background jobs. On each run, Drupal calls hook_cron in every module that implements it and then works through queued tasks. Core uses it to update the search index, check for new releases of Drupal and its modules, and remove old log entries.
How cron works in Drupal 11
The name comes from the Unix scheduler that starts a command at set times. In Drupal there are two parts: something has to trigger cron, and Drupal then does the work.
Triggering cron
- Automated Cron. A core module that the Standard install profile enables. At the end of a page request it checks whether cron is due and runs it if so. It needs nothing from the server, but it only runs when a visitor arrives and it adds load to that request. Its default interval is about three hours.
- An external scheduler. A job on the server (for example crontab), or a hosting control panel, requests the site's cron URL, a path of the form
/cron/{key}that contains a secret key. The exact URL is shown on the Cron settings page. Drupal's documentation calls this more reliable than Automated Cron. - Drush. The command
drush core:cron, also writtendrush cron, runs the same cron cycle from the command line, which suits server schedulers.
What a run does
The work is done by the Drupal\Core\Cron class. It takes a lock named cron, calls each module's hook_cron implementation, and then processes the queues that have a cron setting. If one module's code throws an exception, Drupal logs it and the other modules still run. Afterward it stores the time of the run.
The settings page is at /admin/config/system/cron. It sets the interval for Automated Cron and has a button to run cron now. The Status report shows when cron last ran.
Example
A module that has to fetch data on a schedule should keep the cron hook short and put the real work in a queue. This class adds one item to a queue at every cron run. A queue worker plugin with the same ID, declared with the #[QueueWorker] attribute and a cron time, then processes the items during cron.
<?php
namespace Drupal\my_module\Hook;
use Drupal\Core\Hook\Attribute\Hook;
use Drupal\Core\Queue\QueueFactory;
class CronHooks {
public function __construct(
protected QueueFactory $queueFactory,
) {}
#[Hook('cron')]
public function cron(): void {
$this->queueFactory->get('my_module.feeds')->createItem(['feed_id' => 5]);
}
}To run it on a schedule from the server, point the scheduler at drush core:cron. Once a server job owns the schedule, uninstall Automated Cron; the module's help calls that the recommended way to disable it.
Common mistakes
- Relying on Automated Cron for a quiet site. It only fires on a page request. If few people visit, jobs such as indexing and update checks wait.
- Doing long jobs inside
hook_cron. Drupal's guidance is to keep the hook for short tasks and move long or timeout-prone work to a queue handled by a queue worker. - Leaving detailed cron logging on. It is useful for a short test, but the log entries can fill the database if you leave it on.
- Running both an external trigger and Automated Cron. Once a scheduler is in place, switch Automated Cron off so there is one clear owner of the schedule.
- Never checking the last run. The Status report shows when cron last ran. A stale time means jobs are not running.
For marketing and content teams
Cron is why some things on a Drupal site are not instant. New or changed content reaches the core Search module's index when cron runs, so a page can exist for a while before search finds it. If your team publishes on a schedule and expects search results or other jobs to update promptly, ask your developers how often cron runs and who watches it. The Status report is the place to check, and a developer can raise the frequency with an external trigger. See hooks for how modules add their own cron tasks, and Drush for the command line tool.