Editorial illustration; the schedule and terminal are representative, not a live Drupal installation.
A Drupal site can look healthy while scheduled maintenance has quietly stopped. New content may publish, but search indexing falls behind, update checks become stale, temporary files accumulate or queued work waits indefinitely. Because cron runs in the background, visitors often notice the symptoms before the site owner notices the cause.
Drupal cron is not one task. It is the mechanism that lets modules perform periodic work. The right setup depends on traffic, hosting access and how much delay your site can tolerate, but every site needs a way to run cron and a way to verify the result.
Quick Answer
Check the last cron run and the tasks your site needs. Drupal’s Automated Cron can trigger work from site requests and is convenient for many small installations. A server scheduler or hosting scheduler gives more predictable timing, especially for low-traffic sites and busy sites where maintenance should not be added to a visitor’s request. Whichever method you choose, monitor failures and test after configuration changes.
What Drupal cron does
Drupal’s documentation describes periodic tasks such as indexing content for search, checking for available updates, cleaning temporary data and processing work provided by modules. The exact work depends on the modules and configuration installed on your site.
That means “cron is working” is not the same as “every business process is healthy.” A successful request may only prove that the scheduler reached Drupal. A queue can still fail, an external service can reject a request or a task can take longer than the available time. Treat the run time as an important signal, not a complete health report.
Choose the trigger that fits the site
Automated Cron
Drupal includes an Automated Cron option. It checks during requests whether cron is due, then runs maintenance as part of a request. This is easy to operate and often sufficient for a small site with regular traffic.
Its trade-off is timing. A site with very little traffic may not run tasks when you expect. The request that triggers cron may also experience extra work. That can be acceptable for a modest site, but it should be a conscious choice.
External scheduler
A server cron job, hosting control panel, or another scheduler can call Drupal’s cron endpoint or use the supported command-line workflow for the installation. This separates the trigger from visitor traffic and gives you a predictable schedule.
Protect the cron URL or command as Drupal documents it. Do not paste a site-specific cron key into a public issue, repository or chat. Use the exact endpoint shown by the site’s status information, and confirm that the scheduler can reach it from the server or service where it runs.
A practical setup workflow
- Inspect the current state. Open the Status report and Cron configuration page. Note the last run, configured interval and any warning.
- List the work that matters. Identify search indexing, update checks, queues, email processing and module-specific maintenance that the site relies on.
- Choose one primary trigger. Decide whether Automated Cron, a hosting scheduler, server cron or a supported command-line method fits the traffic and access you have.
- Run cron manually once. Use the Drupal administration page or documented command and observe whether it completes without an error.
- Schedule it conservatively. Start with an interval appropriate for the site’s workload. More frequent is not automatically better if each run is expensive.
- Verify after the first scheduled run. Check the last-run time, logs and any queue or search status that should have changed.
- Record ownership. Note where the schedule lives, which account runs it and how to disable it during an incident.
Troubleshoot by separating the layers
When cron appears stuck, check the layers in order.
The trigger layer
Did the scheduler run? Look at the hosting panel, server log or job history. A typo in the command, a disabled task or an incorrect working directory can prevent Drupal from being reached at all.
The request layer
Did the request reach the correct site and environment? A staging domain, redirect, firewall rule or expired certificate can send the scheduler somewhere unexpected. Confirm the hostname, protocol and endpoint without exposing the cron key.
The Drupal layer
Did Drupal accept the request and start cron? Check the status report and relevant logs. Review recent configuration changes, module updates, PHP errors and resource limits. A timeout may mean that the trigger works but the work cannot finish within the available window.
The task layer
Which operation is failing? Search indexing, a queue worker and an update check may have different symptoms. Do not respond by deleting caches or running every task repeatedly. Identify the failing operation, take a backup when appropriate and check the module’s documentation.
Logging without making the problem worse
Detailed logging can help during diagnosis, but it can also create large volumes of log data. Enable extra detail for a bounded test, reproduce the issue once, inspect the result and then return to a sensible logging level. Store scheduler output where someone will actually review it, and avoid printing secrets or the full cron URL into shared logs.
After a successful run, verify a user-visible consequence where possible. For example, check that a new piece of content is searchable or that a queue item moved forward. The last-run timestamp alone does not prove every task completed correctly.
Mistakes to avoid
Do not assume a high-traffic site is automatically running cron reliably. Do not configure several independent triggers without understanding whether they can overlap. Do not expose the cron key in source control. Do not disable Automated Cron during an incident and forget to replace it with an external schedule. Do not increase frequency to hide a failing task; that can increase load while leaving the root cause untouched.
My Take
Cron is operational plumbing, so it deserves a small runbook. Write down the trigger, expected interval, last successful check, important tasks and first troubleshooting steps. The most reliable setup is the one another person can understand when the original site builder is unavailable.
Bottom Line
Drupal cron keeps periodic maintenance moving, but it is only useful when its trigger and results are observable. Choose Automated Cron or an external scheduler deliberately, run a manual test, check the scheduled result and troubleshoot the trigger, request and task layers separately.