El cron de Moodle es, probablemente, la pieza más importante de la plataforma que menos atención recibe, precisamente porque, cuando falla, nada se rompe de forma visible. El sitio sigue cargando, los alumnos siguen accediendo a sus cursos con normalidad, y mientras tanto, notificaciones, informes y tareas de limpieza se van acumulando sin procesar, en silencio.
En esta guía vas a ver qué hace exactamente el cron, por qué su frecuencia importa tanto, y cómo verificar que realmente se está ejecutando como debería, no solo que está “configurado”.
Qué procesa exactamente el cron de Moodle
El cron es el mecanismo que ejecuta las tareas programadas de fondo de Moodle: notificaciones de foro y calificaciones, generación de informes, limpieza de sesiones caducadas, procesamiento de matriculaciones automáticas, copias de seguridad programadas, y buena parte de la lógica de “tareas ad hoc” y “tareas programadas” que Moodle gestiona internamente.
Nada de esto ocurre en tiempo real como respuesta directa a una acción del usuario, todo depende de que el cron se ejecute con la frecuencia adecuada para procesarlo.
Cómo se configura bien: cron del sistema, cada minuto
La recomendación estándar de Moodle es que el cron lo dispare el cron del sistema operativo, cada minuto, mediante línea de comandos. En un servidor Linux la entrada del crontab se ve así:
* * * * * /usr/bin/php /var/www/moodle/admin/cli/cron.php >/dev/null 2>&1Vale la pena entender cada parte, porque casi todos los fallos que vemos entrar por soporte están en esta línea:
- Los cinco asteriscos (
* * * * *) significan “minuto, hora, día del mes, mes y día de la semana”; con todo en asterisco, la orden se lanza cada minuto de cada día. /usr/bin/phpes la ruta al binario de PHP de línea de comandos (CLI). No tiene por qué coincidir con la versión de PHP que sirve la web: si el servidor tiene varias versiones, apuntar aquí a la incorrecta es un clásico./var/www/moodle/admin/cli/cron.phpes la ruta absoluta al script de cron dentro de tu instalación. Cámbiala por la real de tu servidor.>/dev/null 2>&1descarta la salida para que el sistema no te llene el buzón de correo con la salida de cada ejecución. Si estás diagnosticando un problema, puedes redirigir temporalmente a un fichero de log en lugar de a/dev/null.
En hostings con panel (cPanel, Plesk) no editas el crontab a mano: añades exactamente esta orden en la sección de “Cron Jobs” / “Tareas programadas” del panel, con frecuencia “cada minuto”. El error más común ahí es dejar la frecuencia por defecto del panel (cada 15 minutos o cada hora) sin cambiarla.
Ejecutarlo con menor frecuencia (cada 5, 15 o 60 minutos) retrasa directamente la entrega de notificaciones y el procesamiento de tareas: un alumno puede tardar ese intervalo entero en recibir el aviso de una calificación o un mensaje de foro, simplemente porque el cron aún no ha corrido desde que ocurrió la acción. No es una optimización; es introducir latencia en toda la plataforma a cambio de un ahorro de recursos casi inapreciable.
Por qué el cron por línea de comandos, y no el “cron web”
Existe una alternativa: llamar a cron.php a través de una petición HTTP (un servicio externo de “cron web” que carga la URL cada X minutos). Es posible, pero es la peor opción para producción por un motivo concreto: una petición web está sujeta al mismo límite de tiempo de ejecución (max_execution_time) que cualquier otra página. Si en una ejecución el cron arrastra mucho trabajo acumulado, el timeout puede cortar el proceso a mitad de camino y dejar tareas a medio procesar, que quedarán en un estado inconsistente hasta la siguiente vuelta.
La ejecución por CLI no arrastra ese límite de la misma forma y es la vía recomendada. De hecho, Moodle permite blindarlo: en Administración del sitio > Servidor > Tareas > Procesamiento de tareas puedes activar “Ejecución de cron solo por línea de comandos” (cronclionly), que deshabilita por completo el disparo por navegador. Con esa opción activada, si alguien intenta forzar el cron desde una URL, Moodle lo rechaza, te obliga a hacer las cosas bien.
Las tareas programadas: cada una tiene su propio ritmo
Es importante entender que el cron no es una sola cosa que “corre o no corre”. El cron es el motor que, cada minuto, revisa un listado de tareas programadas y ejecuta las que toca en ese momento. Cada tarea tiene su propia frecuencia: la limpieza de sesiones no necesita correr con la misma cadencia que el envío de notificaciones de foro o la generación de copias de seguridad automáticas.
En Administración del sitio > Servidor > Tareas > Tareas programadas tienes el listado completo, con la frecuencia de cada una expresada en formato crontab (minuto, hora, día…) y editable. Puedes ajustar la frecuencia de una tarea concreta, deshabilitarla, o forzar su ejecución inmediata desde línea de comandos sin esperar al siguiente ciclo:
php admin/cli/scheduled_task.php --execute='\core\task\automated_backup_task'Dos matices que ahorran diagnósticos a ciegas:
- El “retraso por fallo” (fail delay). Cuando una tarea falla, Moodle no la reintenta de inmediato: aplica un retraso que se va duplicando en cada fallo consecutivo (backoff exponencial). En el listado verás ese retraso acumulado. Una tarea con un fail delay alto lleva fallando un buen rato, es una señal, no un dato cosmético. Una vez arreglada la causa, puedes resetear ese retraso para que vuelva a intentarse ya.
- El bloqueo (lock) de tareas colgadas. Para que la misma tarea no se ejecute dos veces a la vez, Moodle toma un bloqueo mientras la procesa. Si el proceso muere de forma abrupta (un timeout, un
kill, una caída del servidor a mitad de tarea), ese bloqueo puede quedarse “colgado” e impedir que la tarea vuelva a lanzarse hasta que caduque o se libere. Es una de las causas menos obvias de “una tarea concreta dejó de correr aunque el cron general funciona”.
El síntoma de un cron mal configurado
A diferencia de un servidor caído, un cron que ha dejado de ejecutarse no genera ningún error visible para los usuarios, el sitio sigue cargando con normalidad. Todas las señales son indirectas, y ese es justo el peligro: cuando alguien las nota, el problema lleva días acumulándose. Desarrolladas, con el porqué de cada una:
- Notificaciones que llegan tarde o no llegan. Los avisos de foro, los mensajes y los correos de Moodle no se envían en el instante en que ocurren: se encolan y los despacha una tarea de cron. Si el cron no corre, esa cola no se vacía. El alumno cree que “no le avisan”, cuando en realidad el aviso está esperando en cola a que alguien procese la tarea.
- Informes y estadísticas congelados. Las estadísticas de uso y varios informes se recalculan en tareas de fondo. Sin cron, muestran los últimos datos que alcanzó a procesar, y parecen actualizados aunque estén desfasados, porque no dan error.
- Sesiones y temporales que no se limpian. Moodle purga periódicamente las sesiones caducadas y los archivos temporales mediante tareas de cron. Si no corren, la tabla de sesiones y el directorio temporal (
moodledata/temp) crecen sin freno: más peso de base de datos y de disco, y con el tiempo, degradación del rendimiento. - Copias de seguridad automáticas que no aparecen. La copia de seguridad automática programada es, ella misma, una tarea de cron. Si el cron está parado, la fecha de backup pasa y no se genera nada. El fallo más caro posible de esta lista: te enteras el día que necesitas restaurar y descubres que hace semanas que no hay copias.
Puesto en tabla, cada síntoma apunta a una tarea concreta, lo que convierte el diagnóstico en algo mucho más rápido:
| Síntoma visible | Tarea programada implicada |
|---|---|
| Avisos y notificaciones de foro que llegan tarde o no llegan | Tarea de foro (\mod_forum\task\cron_task) |
| Correos y mensajes de la plataforma encolados sin salir | Tareas de envío de mensajería/notificaciones |
| La copia de seguridad automática no se genera | Copia automática (\core\task\automated_backup_task) |
| La tabla de sesiones crece sin parar | Limpieza de sesiones (\core\task\session_cleanup_task) |
moodledata/temp se llena de archivos | Limpieza de temporales |
| Matriculaciones por método externo que no se sincronizan | Tareas de sincronización de matriculación (según el método) |
| Insignias, certificados o estadísticas que no se actualizan | Tareas de cada plugin correspondiente |
Cómo verificar que el cron está funcionando de verdad
Tener la línea del crontab escrita no demuestra que el cron esté corriendo bien; demuestra que existe. Para comprobar lo segundo, dentro de Moodle:
- Administración del sitio > Servidor > Tareas > Tareas programadas. Aquí está el corazón de la verificación. Cada fila muestra la última ejecución y la próxima ejecución de esa tarea. Si el cron corre cada minuto como debe, las últimas ejecuciones serán recientes y coherentes con la frecuencia de cada tarea. La señal de alarma es una tarea cuya “próxima ejecución” ya está en el pasado: significa que debería haber corrido y no lo ha hecho, el cron va por detrás o está parado. Si además esa fila arrastra un fail delay alto, ya sabes que lleva fallando un rato.
- Administración del sitio > Servidor > Tareas > Vista general de tareas (los registros de tareas) te da el histórico: qué se ejecutó, cuándo, cuánto tardó y si terminó con éxito o con error. Es donde se ve si una tarea concreta está tardando cada vez más o fallando de forma repetida.
- Comprueba el crontab del servidor (
crontab -ldel usuario correcto, o la sección de tareas del panel) para confirmar que la entrada sigue ahí y no se eliminó en una migración o una actualización del servidor. - Verifica que la ejecución se completa sin timeouts, revisando el log de salida si redirigiste la salida a un fichero en lugar de a
/dev/null.
Si todo esto te parece demasiado para revisarlo a mano cada semana, es exactamente el tipo de comprobación que se automatiza con soporte y monitorización de Moodle: una alerta que salta el día que el cron se retrasa, en lugar de enterarte tú semanas después.
Qué pasa si el cron se satura de trabajo acumulado
Si el cron deja de ejecutarse durante un tiempo prolongado y luego se reactiva, puede encontrarse con una cantidad de tareas pendientes mucho mayor de lo normal, lo que puede alargar significativamente la duración de esa ejecución concreta y competir por recursos con el tráfico normal de usuarios en ese momento. Es importante vigilar que la duración de la ejecución del cron no empiece a solaparse regularmente con la siguiente ejecución programada, lo que indicaría que el volumen de tareas ha superado la capacidad de procesamiento en el intervalo asignado.
Ese solapamiento, además, es una de las causas de lentitud que más despistan: la web va a tirones a ciertas horas sin motivo aparente, y en realidad es el cron peleando por CPU y base de datos con los usuarios. Si estás persiguiendo un problema de rendimiento, el cron es uno de los sospechosos a descartar antes de culpar al hosting, lo tratamos junto al resto de causas en por qué mi Moodle va lento.
Después de una migración de servidor: revisa el cron
Es habitual que, al migrar Moodle a un nuevo servidor, el cron simplemente no se reconfigure en el destino, el sitio parece funcionar con normalidad, y el fallo solo se hace evidente días después, cuando alguien nota que las notificaciones no llegan o los informes están desactualizados. Verificar el cron es un paso que debería formar parte de cualquier checklist de migración, no un detalle opcional.
Preguntas frecuentes
¿Con qué frecuencia debe ejecutarse el cron de Moodle? Cada minuto es la recomendación estándar, para minimizar el retraso en notificaciones y procesamiento de tareas.
¿Puedo ejecutar el cron mediante una URL HTTP en vez de línea de comandos? Es técnicamente posible, pero expone el proceso a los mismos límites de timeout que cualquier petición web, con riesgo de cortar tareas a mitad de ejecución. La línea de comandos es la vía recomendada.
¿Cómo sé si el cron de mi Moodle está funcionando correctamente? Revisando Site administration > Server > Scheduled tasks, donde se muestra la última ejecución de cada tarea individual, no solo si el proceso general existe.
¿Qué pasa si el cron deja de ejecutarse durante varios días? Las tareas se acumulan sin procesar (notificaciones retrasadas, informes desactualizados, backups programados sin generar) sin que el sitio muestre ningún error visible mientras tanto.
¿El cron afecta al rendimiento general del sitio? Sí, si se acumula demasiado trabajo pendiente, una ejecución del cron puede alargarse y competir por recursos con el tráfico normal de usuarios en ese momento.
¿Debo revisar el cron después de migrar de servidor? Sí, es uno de los elementos que con más frecuencia se olvida reconfigurar en una migración, y su fallo no se nota de inmediato precisamente porque no genera errores visibles.
¿Qué pasa si ejecuto el cron con menor frecuencia para ahorrar recursos? Retrasa directamente la entrega de notificaciones y el procesamiento de tareas, no es una optimización recomendable, ya que el impacto en la experiencia de usuario suele superar el ahorro de recursos obtenido.
Una tarea concreta no corre aunque el cron general sí funciona, ¿por qué? Suele ser una de dos cosas: la tarea acumuló fallos y está en “retraso por fallo” (Moodle espera antes de reintentarla, con un retraso que se duplica en cada fallo), o quedó un bloqueo (lock) colgado de una ejecución que murió a mitad. Revísala en Administración del sitio > Servidor > Tareas > Tareas programadas: si arrastra fail delay, arregla la causa y resetéalo; si sospechas un lock colgado, forzar la tarea por CLI ayuda a confirmarlo.
¿Puedo forzar la ejecución de una tarea sin esperar al cron?
Sí, por línea de comandos con admin/cli/scheduled_task.php --execute='\ruta\de\la\tarea'. Es útil para probar que una tarea concreta funciona tras arreglar un problema, sin esperar a su próxima ejecución programada.
¿Cómo diferencio un cron que no corre de uno que corre pero va saturado? Mirando la última y la próxima ejecución de las tareas: si las últimas ejecuciones son antiguas y las próximas están en el pasado, el cron no corre. Si las tareas sí se ejecutan pero cada vuelta tarda mucho y empieza a solaparse con la siguiente, el cron corre pero está saturado, es otro problema (capacidad), no un cron parado.
¿Necesito desactivar el “cron web” a mano?
Si ya disparas el cron por línea de comandos, activar “Ejecución de cron solo por línea de comandos” (cronclionly) en el procesamiento de tareas cierra la puerta a que nadie lo lance por navegador por error. No es obligatorio, pero es una buena práctica en producción.
Conclusión
El cron de Moodle es una de esas piezas de infraestructura que solo se nota cuando falla, y para entonces el problema ya lleva tiempo acumulándose en silencio. Verificar su ejecución real (no solo su configuración teórica) debería formar parte de cualquier revisión de mantenimiento periódica, y muy especialmente de cualquier checklist tras migrar de servidor.
Si prefieres que alguien vigile esto de forma continua, en Avantys lo incluimos como parte de la monitorización de cada Moodle que gestionamos. Puedes pedir una auditoría gratuita en Moodle Gestionado.
Artículos relacionados
- Mantenimiento y hosting Moodle: guía completa
- Por qué mi Moodle va lento: causas más comunes
- Migrar Moodle a un nuevo servidor sin perder cursos
- Requisitos de servidor para Moodle (CPU, RAM, disco)
¿Y si tu Moodle lo lleváramos nosotros?
Actualizaciones, backups verificados, rendimiento y trazabilidad FUNDAE, gestionado de forma continua por una persona que responde. Auditoría gratuita de tu plataforma actual.
