Moodle Cron and Scheduled Tasks: A Practical Reliability and Performance Guide

Moodle cron should be launched from the command line at least once per minute, then monitored as a queue-processing service rather than treated as a daily housekeeping job. A healthy cron system starts reliably, lets due work progress, exposes failures and keeps long tasks from delaying learner-facing operations.

The short answer is: run the CLI cron every minute, confirm one invocation can complete safely, inspect scheduled and ad hoc task health, investigate repeated failures before changing schedules, and monitor delay as well as server load. A green “cron ran” message proves that a process started; it does not prove that email, completion, enrolment, backups and plugin work finished on time.

What Moodle Cron Actually Does

Cron is the regular launcher for Moodle's background task system. It does not mean that every task runs every minute. Each scheduled task has its own timetable, while ad hoc tasks are queued when Moodle or a plugin needs one-off background work. The runner finds eligible work, obtains the required locks and processes tasks within the site's configuration and available resources.

That distinction matters during diagnosis. If the system cron never starts, nothing in the queue can progress. If cron starts but a particular task fails, the fault may sit in a plugin, an external service, data or configuration. If valid work waits too long, the problem may be capacity, concurrency, locks or one task monopolising the available workers.

Moodle's official Task API documentation and scheduled tasks documentation, reviewed on 14 October 2026, recommend running cron at least once per minute. They also distinguish regular scheduled tasks from queued ad hoc tasks and explain that failed tasks are retried with increasing delay, from one minute up to 24 hours after repeated failures. Check the documentation for your supported release and the behaviour of installed plugins before changing production settings.

Swift Learn's judgement is that cron is reliable only when three layers are evidenced separately:

• the operating system launches the intended PHP CLI command;
• Moodle accepts and processes eligible work; and
• important business outcomes arrive within an agreed time.

A successful first layer cannot substitute for the other two.

Establish a Safe One-Minute Baseline

Use the PHP command-line binary to call Moodle's admin/cli/cron.php every minute under the correct service account. The working directory, PHP version, configuration file, environment and filesystem permissions must match the supported deployment design. Do not assume the web server and shell use the same PHP binary or php.ini.

Capture output and the exit status somewhere your monitoring can inspect. Avoid putting secrets in the crontab or command line. If the platform uses containers or multiple application nodes, define which component owns the launcher and how deployments preserve that ownership.

Running the launcher every minute is normally safer than trying to reproduce each task's timetable in the system crontab. Moodle remains responsible for deciding what is due. The frequent launcher also reduces the waiting time for ad hoc work and allows short tasks to begin promptly.

There is an important trade-off: frequent starts expose a weak locking or worker design sooner. That is not a reason to fall back to hourly cron. It is a reason to validate the site's lock factory, shared storage, database connectivity and concurrency controls, especially on a cluster. Adding launchers to every web node without that design can produce contention rather than capacity.

Audit the Task System in Layers

1. Prove the Launcher

Run the CLI command interactively in a controlled maintenance window or on staging using the same account and PHP binary as automation. Confirm that it loads the correct Moodle instance, exits normally and records useful output. Then check the scheduler or service history rather than assuming a saved crontab is active.

Record:

• host or container that owns the launcher;
• service account and PHP CLI path;
• exact Moodle release and deployment path;
• launch frequency, timeout and overlap policy;
• destination for standard output, errors and exit status; and
• alert owner when a launch is missed or fails.

This inventory prevents a familiar incident: cron “works” when an administrator runs it manually, but automation uses another PHP version, lacks a mounted directory or calls an old release path after deployment.

2. Inspect Scheduled Tasks

In Site administration, review Server > Tasks > Scheduled tasks. Look for tasks that are disabled, repeatedly late, unusually long-running or carrying a failure delay. Compare customised schedules with plugin defaults and identify who approved each change.

Do not make every slow task less frequent. A task can be slow because it has accumulated a backlog, contacts an unavailable integration or processes too much work per run. Reducing frequency may lower immediate load while increasing the amount handled next time. Conversely, an expensive report or cleanup task may legitimately belong outside the busiest learning window. Decide from its purpose, duration and downstream deadline.

3. Inspect Ad Hoc Work and Running Tasks

Ad hoc tasks often carry work that users expect soon: forum email, course copies, backups, data processing and plugin-specific jobs. A scheduled-task screen alone can therefore look healthy while the ad hoc queue grows.

Review task reports available in your supported Moodle release, application logs and database-backed monitoring. Measure the age of the oldest eligible task, not only the queue count. Ten new jobs waiting for seconds may be healthy; one job eligible since yesterday is not.

For long-running work, distinguish active progress from a stale lock or terminated process. Moodle 5.1's Task API supports stored progress for suitably implemented tasks, but plugins must adopt it. Absence of a progress bar is not proof that nothing is happening; corroborate it with process, log and lock evidence.

4. Verify the Business Outcome

Select a small set of sentinel journeys and time them end to end. Suitable examples include a forum post reaching email, an enrolment feed updating access, a completion change appearing in its downstream report, or an automated backup becoming available.

These checks reveal failures that infrastructure metrics miss. Cron may finish with exit code zero while an optional integration quietly returns incomplete data, or a task may succeed technically after the operational deadline has passed.

Diagnose Common Failure Patterns

Cron Has Not Run Recently

Check the system scheduler first, then the service account, CLI PHP path, deployment path and permissions. A hosting control panel may show a job definition without proving recent execution. On container platforms, verify that the scheduling component survives releases and is not scaled to zero.

Treat a long gap as a queue recovery exercise. Restoring the launcher can release a large volume of overdue email, backups, completion calculations and synchronisation work at once. Observe load and outcomes rather than repeatedly starting extra runners in panic.

One Task Keeps Failing

Read the first useful exception, not merely the latest retry message. Establish whether the failure is deterministic, data-specific or dependent on an external system. Repeated failures can increase the interval before Moodle retries, so a repaired dependency may not produce an immediate recovery without an intentional, controlled test.

Do not disable a failing task until you understand what obligation it fulfils. Disabling noise can conceal unprocessed enrolments, retention work or messages. If temporary suspension is necessary, record the owner, impact, recovery plan and the queue or data that must later be reconciled.

Cron Runs for Too Long

Separate normal productive work from a blockage. Identify which task consumes the time, how its duration changes with volume, and whether it is safe to run concurrently. Check database waits, remote calls, storage throughput, PHP memory pressure and task-specific batching.

This belongs inside the wider approach to Moodle performance at scale: optimise the bottleneck demonstrated by evidence. More workers help only when work can run safely in parallel and the database, cache, storage and integrations have capacity. Otherwise concurrency can turn a long queue into widespread contention.

Work Completes, but Too Late

Measure queue wait separately from execution time. A five-second task that waits 45 minutes has a latency problem, not a slow-code problem. Review launcher gaps, worker limits, long blocking tasks, retry delays and demand peaks.

Agree service expectations by outcome. Password-related messages may need near-immediate handling; a nightly cleanup can tolerate hours. Connect those expectations to the response and restoration commitments in the Moodle hosting SLA guide, rather than using one generic “cron is up” target.

Tune Schedules and Concurrency Deliberately

Start with defaults unless an observed requirement justifies a change. Plugin authors understand dependencies that are not always obvious from a task name. When a schedule is customised, record the original value, reason, approver, expected benefit and review date.

Use four questions before increasing concurrency:

1. Can separate instances of this work run safely at the same time?
2. Does the configured lock mechanism work across every node?
3. Can the database, cache, storage and external services absorb the added demand?
4. Will monitoring distinguish greater throughput from greater failure volume?

The same discipline applies to moving work into quiet hours. There may be no truly quiet period on an international learning platform, and concentrating backups, reports and synchronisation into one window can create a larger peak. Stagger heavy tasks, then validate learner-facing latency and completion time.

After a plugin or core update, repeat representative task tests. Names, defaults, dependencies and workload can change. Include this regression work in a governed Moodle upgrade services plan rather than discovering it from delayed messages after release.

Build Monitoring That Leads to Action

A useful dashboard combines launcher, queue, execution and outcome signals:

Set thresholds from observed baselines and business deadlines. A universal queue-count alarm creates noise because demand varies by site and time. Alert on sustained delay, missed launches, repeated exceptions and breached outcomes. Every alert needs an owner and a first diagnostic action.

Retain enough history to compare incidents with deployments, enrolment peaks, assessment deadlines and backup windows. Avoid logging task payloads or personal data unnecessarily; operational evidence still needs proportionate access and retention controls.

A Practical Moodle Cron Checklist

Before launch:

• configure the supported PHP CLI cron command every minute;
• validate the service account, paths, permissions and lock design;
• document ownership on single-node, clustered or container platforms;
• capture output, exit status and missed-launch alerts; and
• test scheduled, ad hoc and business-outcome examples on staging.

During operation:

• monitor launch recency, oldest eligible work, failures and duration;
• inspect scheduled and ad hoc task reports together;
• investigate repeated exceptions before suppressing or rescheduling them;
• compare capacity with learning, integration and backup peaks; and
• reconcile important outcomes such as email, enrolment and completion.

After change:

• retest cron after deployments, PHP changes and plugin upgrades;
• review customised schedules and concurrency assumptions;
• confirm overdue work has drained without duplicate or missed outcomes; and
• record the incident, correction and prevention evidence.

The Swift Learn Verdict

Reliable Moodle cron is not “set it and forget it”. It is a small background-processing platform with a launcher, queues, locks, workers, dependencies and service outcomes. Run the launcher every minute, but judge health by how promptly valid work completes and whether failures are visible.

Keep default task schedules until evidence supports a change. Add concurrency only after validating locks and downstream capacity. Monitor the oldest work and end-to-end outcomes, not just process starts. Above all, treat a growing queue as diagnostic evidence: slowing the schedule may hide the symptom while increasing the eventual workload.

Where cron ownership, plugin failures and hosting boundaries are unclear, a structured review within managed Moodle support can turn intermittent background problems into an evidenced operating model.

Need a Moodle Cron and Task Health Review?

Bring us your deployment architecture, recent task logs, queue symptoms and one or two delayed learner journeys. Swift Learn will trace the launcher, task system and dependencies, then provide a prioritised reliability and performance plan.