Cron is Drupal’s housekeeping: checking for updates, cleaning old logs, indexing search, sending queued mail. Out of the box, the Automated Cron module piggybacks that work onto visitor page loads — which means some unlucky visitor waits while your site sweeps the floor, and a quiet site never sweeps at all. A real server schedule fixes both. You’ll need drush and a crontab you can edit.

Check when cron last ran

Before changing anything, see where you stand:

drush core:requirements --filter="title~=Cron"

You can also see it at Reports → Status report. If the last run was weeks ago, you’ve found the reason search results are stale and update notices never arrive — the piggyback approach only works when someone’s riding by.

Turn off the built-in poor-man’s cron

Once a real schedule is coming, the page-load trigger is just dead weight. Uninstall the module:

drush pm:uninstall automated_cron -y

If your site exports configuration to git, export after this so the change travels with your code. Nothing breaks in the gap between this step and the next — cron work just waits patiently, like it always has.

Schedule the real thing on the server

Edit the crontab for the user your site runs as:

crontab -e

Add one line that runs cron via drush every fifteen minutes:

*/15 * * * * cd /var/www/example.com && ./vendor/bin/drush cron --quiet

Adjust the path to your project root. If you’re on managed hosting without crontab access, the platform usually has its own scheduler (Pantheon, Acquia, and most panels do) — point it at the cron URL from Configuration → System → Cron, key and all. Every fifteen minutes is a good default: frequent enough that queues drain, cheap enough nobody notices.

Watch a run and read what it did

Don’t wait for the schedule — trigger one now with the chatty flag:

drush cron -v

You’ll see each module take its turn. Then check the log for complaints:

drush watchdog:show --filter=cron --count=20

A clean run logs almost nothing. Errors here are worth reading — one module’s cron task failing loudly can hold up everyone behind it.

Add a check so silence gets noticed

The failure mode of scheduled cron is silence: the crontab line gets lost in a server move, and nobody notices for months. Give the silence an alarm. The status report already warns when cron hasn’t run recently, so the simplest watch is a weekly glance at Reports → Status report — or, if you’ve followed set up uptime monitoring, add a check on that page so a stale cron pings your phone instead of waiting for your memory.

To verify the whole setup: wait fifteen minutes past the next scheduled slot, then run the step-one command again. A “last run” timestamp inside the last fifteen minutes means the server is doing the sweeping now — and your visitors are just visiting.