๐Ÿ“Œ Understanding Moodle Cron Email Notifications


:pushpin: 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 :right_arrow: 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:

  • -s runs curl in silent mode
  • > /dev/null discards normal output
  • 2>&1 discards error output

:check_mark: Cron runs normally :check_mark: Moodle tasks execute :check_mark: 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:

  • :white_check_mark: Use silent cron in production
  • :white_check_mark: Monitor cron status inside Moodle Admin โ†’ Scheduled tasks
  • :white_check_mark: 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 :three_o_clock: