Understanding Moodle Cron Email Notifications
(Why they happen and how to control them securely)
Introduction
Moodle relies heavily on cron jobs to function smoothly. From sending scheduled emails and processing background tasks to cleaning logs and syncing enrolments, cron is the quiet engine room of a Moodle site.
However, many administrators are surprised when their server starts sending cron email notifications after every run. This article explains why that happens, when itโs useful, and how to silence it safely, without exposing sensitive information.
What Is Moodle Cron?
Moodle cron is a scheduled task runner that executes background jobs at regular intervals. It can be triggered using:
- A web-based cron URL
- A command-line (CLI) cron script
On shared hosting environments, the web-based cron is commonly used.
Example (masked):
https://lms.example.org/admin/cron.php?password=********
Why Does Cron Send Email Notifications?
Cron itself is very simple in behavior:
If a cron command produces any output, cron emails that output to the system user.
This means:
- If Moodle prints text such as โCron completed successfullyโ
- Or outputs HTML or warnings
Cron captures it and sends it as an email.
This is normal behavior, not an error.
When Cron Emails Are Useful
Cron email notifications can be helpful when:
- You are testing cron for the first time
- You want confirmation that cron is running
- You are debugging failed tasks
In these cases, receiving emails gives visibility into what Moodle is doing behind the scenes.
Why Cron Emails Become a Problem
For a production Moodle site, cron usually runs:
- Every 1 minute
- 1,440 times per day
If output is not suppressed, this can result in:
- Inbox flooding
- Mail server overload
- Important system emails getting buried
This is why most administrators choose to silence cron output once everything is working.
How to Stop Cron from Sending Emails
The solution is simple: redirect all output to /dev/null.
Recommended (masked example):
curl -s "https://lms.example.org/admin/cron.php?password=********" > /dev/null 2>&1
What this does:
-sruns curl in silent mode> /dev/nulldiscards normal output2>&1discards error output
Cron runs normally
Moodle tasks execute
No emails are sent
How to Enable Cron Emails (If Needed)
If you ever want cron emails again, simply remove the output redirection:
curl -s "https://lms.example.org/admin/cron.php?password=********"
Cron will then email whatever Moodle outputs during execution.
Best Practice Recommendation
For stable Moodle sites:
Use silent cron in production
Monitor cron status inside Moodle Admin โ Scheduled tasks
Enable output or logging only when troubleshooting
For higher performance and security, consider migrating to CLI-based cron when server access allows.
Conclusion
Cron email notifications are not errors โ they are signals. Understanding how and when cron sends email allows administrators to strike the right balance between visibility and silence.
A well-configured Moodle cron should:
- Run frequently
- Stay quiet
- Alert you only when something goes wrong
Thatโs the mark of a healthy LMS system ticking along in the background ![]()
