What to Monitor on a Moodle Server

Summary: This guide covers a practical Moodle server monitoring setup, including data center alerts, external uptime checks, heartbeat monitoring, Webmin service checks, load thresholds, and database visibility.

Moodle monitoring should tell you more than whether the server still answers pings. In practice you want coverage for infrastructure health, web and database service availability, cron execution, and basic application reachability.

Step 1: Check the provider or data center monitoring first

Many VPS providers expose basic CPU, RAM, disk, and uptime monitoring. Before building your own stack, confirm what already exists and whether it is actually configured to alert the right people.

The SOP’s rule of thumb is useful:

• CPU should not sustain above roughly 80%
• RAM should not sustain above roughly 80%
• Disk should stay below roughly 95%

If the built-in monitoring is too weak, treat it as supplemental only.

Step 2: Add an external uptime monitor

You should always have at least one external monitor that performs an HTTP request against the site from outside the infrastructure. This tells you about outages that internal service checks may miss.

The SOP uses Cronitor as an example. Any equivalent external monitoring service is fine as long as it checks frequently enough and sends alerts to the right people.

Step 3: Monitor cron separately with a heartbeat

For Moodle or Totara, front-end uptime is not enough. Cron can stop working while the site still loads. The SOP addresses this with a heartbeat-style plugin that tells the external monitor “I’m alive” whenever cron runs successfully.

The pattern is:

• cron runs
• the heartbeat hook emits a signal to the external monitor
• if no signal arrives on schedule, the monitor raises an alert
• when the signal resumes, the monitor sends a recovery notification

A practical cron pipeline from the SOP looks like this:

* * * * * php /path/to/moodle/admin/cli/cron.php | \
php /path/to/moodle/admin/tool/heartbeat/cli/cron.php > /dev/null

This is particularly useful because it detects “cron is dead” separately from “the homepage is down.”

Step 4: Make sure Webmin or an equivalent tool is available

The SOP assumes Webmin as the standard local server admin and monitoring console. If you use it, the relevant section is:

Webmin > Tools > System and Server Status

If you do not use Webmin, replicate the same checks with another monitoring system rather than skipping them.

Step 5: Add the core service monitors

The SOP’s default monitor set is:

• load average
• disk space
• Apache web server availability
• free memory
• MySQL database server availability

For each monitor, set a clear description, alert email target, and a failure threshold that reports quickly. The SOP uses Failures before reporting = 1 to avoid slow detection.

How to size the load average threshold

For load average, the SOP uses a practical 15-minute threshold derived from the number of CPU cores:

maximum load = number_of_cores * 0.8

Examples:

• 1 core: 0.8
• 4 cores: 3.2

You can confirm the core count with:

lscpu

or from the Webmin processor information panel.

Step 6: Add deeper performance visibility where needed

For servers that host larger or more performance-sensitive Moodle sites, the SOP adds:

• Munin node monitoring
• Apache server-status
• MySQL slow-query logging

These help when the site is “not down, but bad.” That class of problem is very common in Moodle operations.

Enable MySQL slow-query logging during investigations

A practical temporary setup is:

set global slow_query_log = 'ON';
set global slow_query_log_file = '/var/log/mysql/slow-query.log';
set global long_query_time = 30;
show variables like '%slow%';

This gives you evidence when the site is slow instead of relying on guesswork.

Step 7: Define incident response, not just alerts

Monitoring is only useful if someone reacts consistently. The SOP’s response flow is straightforward:

1. verify the alert
2. confirm user impact
3. fix the issue
4. take steps to prevent recurrence
5. communicate clearly if there was an outage

That is enough structure to prevent alerts from turning into unowned background noise.

---

Solin specializes in Moodle hosting, monitoring, and incident response. Need help? Contact us.