Running Drupal cron reliably, and why the default can fail

Cron problems in Drupal rarely look like cron problems. They look like search results missing last week's news, a newsletter that never went out, scheduled content that did not publish at 9 a.m., or a queue of thousands of items nobody knew existed. Everything appears normal on the surface because the site itself works fine. The maintenance underneath it has quietly stopped.

What cron does in Drupal

Drupal uses cron to run recurring background work. Core and contributed modules hook into it to:

• Update search indexes with new and changed content
• Process queues, such as outgoing email, notifications, and imports
• Publish and unpublish scheduled content
• Clear expired cache entries and temporary files
• Check for available updates and security releases
• Fetch feeds and run integration syncs

Why the default is unreliable

Out of the box, Drupal's Automated Cron module runs cron at the end of a visitor's page request once enough time has passed. That is convenient for a new site and wrong for production:

• It depends on traffic. Quiet sites, and intranets overnight, may go hours without a run.
• It borrows a visitor's request. A long cron run ties up a web server process that should be serving pages.
• It is subject to web limits. PHP time limits and memory limits meant for page requests can cut long jobs short.
• It fails silently. Nobody is watching the request that happened to trigger it.

Production sites should uninstall Automated Cron and run cron from a scheduler instead.

Checking when cron last ran

The Status report (Administration, Reports, Status report) shows when cron last ran. From the command line:

drush php:eval "echo date('c', \Drupal::state()->get('system.cron_last'));"

If that time is hours or days old on a busy site, cron is not running. The Recent log messages report shows cron entries and any errors.

Symptoms that point to cron

Running cron properly

1. Use a scheduler. Run drush cron on a fixed schedule from a system scheduler or a scheduled task in your hosting platform, typically every few minutes to hourly depending on what the site needs.
2. Run it in one place. On a site with several web servers, only one should run cron, or runs will collide.
3. Separate heavy queues. Large imports or mass email should run as their own jobs with drush queue:run, so one slow task does not block routine maintenance. drush queue:list shows how many items each queue holds.
4. Give background jobs appropriate limits, separate from the limits used for page requests.
5. Monitor it. A heartbeat check that alerts when cron has not completed within its expected interval turns a silent failure into a visible one.

When a cron run gets stuck

Drupal uses a lock so two cron runs do not overlap. If a run is killed partway through, the lock normally expires on its own. If cron keeps reporting that it is already running, find the task that is hanging: check the logs for the last hook that ran, and look for a queue with a very large backlog or a feed pointing at an unreachable service. Fixing that task is the real cure.

A final tip: when you add a module, check whether it defines cron tasks or queues of its own. Modules that import data, send mail, or sync with other systems often do, and they can change how long cron takes. Knowing that up front makes the schedule easier to tune.

How eWay runs scheduled jobs

eWay disables visitor-triggered cron on production and drives drush cron from a reliable scheduler on a single node, on a cadence set for your site. Resource-heavy work runs as separate scheduled jobs or queue workers so it does not collide with routine maintenance. Cron and queues are monitored as availability signals: a missed run, a failed job, or a growing queue raises an alert even when every page still loads.

What to include in a support ticket

• The severity you would assign, P1 to P4 (see severity levels and response times)
• What is not happening, such as search, email, or scheduled publishing, and since when
• The last cron run time from the Status report
• Any recent module installs or new integrations

eWay customers can open a ticket in the support portal or email support@ewaycorp.com at any time. See how to request support for all the options. Related reading: using Drush safely and enterprise search and content scale on Drupal. Learn more on our Drupal page.