Drupal automated cron for scheduled tasks
Drupal’s cron facility is often mistaken for a background daemon that wakes up by itself. In practice, Drupal cron is work initiated by a request: a browser visit, a command-line call, or an external scheduler can run the registered cron hooks. Automated Cron changes that initiation pattern for selected installations, but it does not make execution instantaneous, continuous, or immune to timeouts.
That distinction matters when a site must publish timed content, refresh remote data, send queued notifications, or rotate operational records. A useful setup treats each scheduled task as an idempotent operation, records its outcome, and provides a way to notice when the schedule has gone stale. This guide explains where Automated Cron fits, how to configure scheduled work, and what Australian site administrators should consider before relying on traffic-triggered execution in production.
What automated cron actually does
Automated Cron is a contributed module rather than a separate service bundled with every Drupal release. Once enabled, it observes eligible requests and starts Drupal’s cron processing when the configured interval has elapsed. This can keep routine maintenance current on a lightly used site without someone remembering to visit a protected endpoint. Its effectiveness still depends on people, crawlers, bots, health checks, or application traffic reaching the site.
Each run gives registered modules an opportunity to perform scheduled work through Drupal’s cron mechanism. A content scheduling module may publish or unpublish items, while another module might synchronise records, rebuild a search index, or dispatch a queue. The request does not stay alive forever: PHP execution limits, proxy timeouts, and the size of the workload can interrupt the run. A request reaching the site is an opportunity to work, not proof that every task finished.
The module should be viewed as an initiator, not the task itself. The operation still needs clear conditions, a time source, a completion marker, and sensible error handling. On a busy Drupal site, several workers can arrive during the same cron window, so the implementation must prevent duplicate side effects. On a quiet site, the first request after the interval may wait behind web-server or database configuration. These behaviours explain why an external scheduler is usually safer for a business-critical workflow.
Preparing reliable scheduled tasks
Install and enable the Automated Cron module, then use its configuration screen to set the run interval and decide which visitors or requests may trigger it. Keep the interval no shorter than necessary, especially if several operations run at once. A setting such as five minutes does not guarantee five-minute execution when the site receives no traffic or the previous run is still active.
Next, define the business outcome, such as publishing a campaign page at 09:00 AEST or sending a daily account summary. The Scheduler module covers many editorial publishing needs and is a practical choice when site editors need a date-and-time control. For a bespoke operation, a custom Drupal module can implement hook_cron() and call a service that performs the work. Keeping that service separate makes the operation testable without manufacturing a web request.
Scheduled content and background processing have different requirements. Publishing a node should update one record and record its transition, whereas sending every pending email may require a queue with controlled throughput. A module should select only due items, order them predictably, and stop cleanly when its time or item budget is reached. Remaining work can continue on the next cron run. This chunked approach reduces the chance of a long-running request exhausting memory.
Before deployment, write down what “done” means for the task. A row may need a processed timestamp, a status such as queued, sent, or failed, and an idempotency key identifying the source event. Duplicate calls should produce the same final state rather than a second invoice, email, or publication. Log important transitions with a correlation identifier so an administrator can connect a Drupal log entry to the job that caused it.
Planning schedules for Australian teams
Australian schedules need more care than a simple UTC offset. Sydney and Melbourne move between Australian Eastern Standard Time and Australian Eastern Daylight Time, while Brisbane stays on AEST and Adelaide observes a half-hour offset. Perth remains on Australian Western Standard Time without daylight saving. Store the intended event time with a time-zone identifier, convert it at execution, and test behaviour around daylight-saving transition dates. Displaying “2:30 am” without a zone is ambiguous, even on a site used by one team.
The local operating day also shapes expectations. A Canberra publisher may schedule an announcement before an early-morning national briefing, while a Perth team may not want routine cleanup to begin during its busiest trading period. Australian agencies often call a late-afternoon deployment an “arvo release”, but that conversational label should not replace precise timestamps in configuration. Support teams in Sydney, Melbourne, and Brisbane usually overlap for several hours, yet holidays and after-hours cover still need a named owner.
Many Australian Drupal projects are delivered by agencies or managed-hosting partners, making monitoring part of the service rather than an optional extra. A client may expect a clear last-run status from hosting dashboards, incident alerts, and a documented escalation path. When an internal team owns the server, it may prefer Drush or a platform scheduler because those options expose command output directly. When a managed provider owns it, confirm who can restart a stalled worker and how quickly they will respond.
Comparing ways to trigger cron
There is no single cron arrangement that suits every Drupal installation. The right choice depends on traffic, hosting access, required timing, and how costly a missed run would be. Compare these common triggering methods before changing site configuration:
| Trigger method | How it runs | Advantages | Constraints | Suitable use |
|---|---|---|---|---|
| Automated Cron module | An eligible request starts cron after the configured interval | Minimal setup; useful for routine maintenance | Depends on request traffic; can collide or time out | Low-traffic sites and development |
External request to cron.php |
A platform scheduler calls a protected endpoint | Predictable triggering on quiet or busy sites | Requires key management and monitoring | Production sites with strict schedules |
| Drush cron | A CLI job runs the command on the server | Direct logs, control, and exit status | Needs shell access and operational ownership | Agency or self-managed servers |
| Platform scheduler | The hosting control panel queues a command or HTTP request | Managed execution and provider alerts | Features and limits vary by platform | Cloud and managed Drupal hosting |
Automated Cron is convenient when the objective is best-effort maintenance and the site receives enough traffic. It is a poor foundation for a job that must run at 02:00 precisely, because a dormant site may receive no request at the required time. Bots can provide occasional requests, but treating crawler activity as a service-level guarantee creates false confidence. The module can still complement a scheduler as an internal safety net, provided duplicate execution is prevented.
An external HTTP scheduler gives the strongest control over a public Drupal site. A provider can call /cron.php every five or fifteen minutes, while a generated cron key in settings.php can protect the endpoint from casual invocation. For a self-managed VPS, a shell scheduler can run drush cron and capture its exit status. Neither approach should remain an untested control-panel click: alert on a stale run, rotate credentials, and document the recovery command for whoever is on duty.
Monitoring scheduled work
Observability turns a scheduler from a hopeful setting into an operable one. Record when cron began, when each major task completed, the number of records processed, and the reason for any failure. Drupal’s logging system can capture these events, while a small status entity or configuration value can hold the last successful run. Queue depth, oldest pending item age, and consecutive failure counts are usually more actionable than a generic “cron failed” message.
A lightweight administration view can bring those signals together for site editors. Drupalwoo’s walkthrough of a custom dashboard widget example shows how JavaScript and AJAX can present site information without a full page reload. The same design can display the last successful run, failed jobs, and queue depth, although colour should be reinforced with text so the result remains accessible to users with different visual needs.
Alerts should be tied to an expected maximum delay. If cron runs every fifteen minutes, an alert after two missed cycles may suit a non-critical task; a missed payment run may need immediate escalation. Australian support teams often use email, SMS, or collaboration tools such as Teams, and an after-hours alert must identify the runbook owner rather than merely say that an administrator should investigate. Test the notification path periodically, because an alert sent to a departed staff account is equivalent to no alert.
Hardening tasks and recovery
Production cron jobs need defensive design. Use a lock to prevent overlapping runs, set explicit time limits, and make every step safe to repeat. Network calls should have timeouts, retries should use backoff, and partial failures should leave a durable status that the next run can inspect. Avoid deleting all queue items before processing them; claim one item, complete it, then remove it. This preserves work if PHP, the database, or an external API fails midway.
Protect the trigger as carefully as the task. Serve the site over HTTPS, restrict access to the cron endpoint, and keep the generated cron key in settings.php or an environment-backed secret rather than in version control. External schedulers should send the key only to the intended URL, and access logs should reveal repeated failures without exposing the secret. During a busy Australian campaign launch, apply rate limits and watch provider quotas so routine maintenance does not compete with editorial traffic.
Enterprises often connect Drupal to Java services, message brokers, or transactional databases, which adds another failure boundary. The Oracle middleware overview provides useful background on the surrounding middleware landscape, but ownership still needs to be explicit: does middleware retry, what dead-letter queue exists, and which team confirms a message reached its destination? A runbook should link Drupal status with application logs and define the steps for replaying a safe job. With those controls in place, automated scheduling becomes a repeatable operating process rather than a fragile web-request trick.