Automatización en Moodle: cron, tareas adhoc y arquitectura backend

Hace un año, una universidad me contactó en agosto con un diagnóstico aparentemente claro: “Andrés, Moodle va lento durante las matrículas. ¿Puedes revisar el servidor?”. La primera hipótesis era la habitual: ampliar RAM, subir CPU y rezar para que septiembre no rompiera nada.

Pero el servidor no era el problema. Tenía capacidad de sobra. El cuello de botella estaba en otro sitio: cada matrícula lanzaba una sincronización síncrona contra el ERP académico. Si el ERP tardaba 10 segundos, el alumno esperaba 10 segundos. Si el ERP fallaba, Moodle quedaba en una situación incómoda: el usuario veía error y la matrícula podía quedar a medio camino.

Ese tipo de problema no se arregla solo comprando más infraestructura. Se arregla rediseñando la automatización en Moodle.

Y esta es la idea incómoda: muchos campus virtuales no tienen un problema de servidor. Tienen un problema de arquitectura backend.

En proyectos Moodle profesionales, institucionales o corporativos, automatizar no significa únicamente tener el cron activo. Significa diseñar procesos desacoplados, tolerantes a fallos, observables e idempotentes. El cron es el mecanismo. La arquitectura es la diferencia.

Automatización en Moodle: por qué tener cron activo no es suficiente

Durante años he visto a muchos equipos reducir la automatización en Moodle a una comprobación demasiado básica:

¿Está activo el cron?

Si la respuesta es sí, se da por hecho que todo está correctamente automatizado. Pero esa conclusión es incompleta. Yo mismo caí en esa trampa al principio de mi carrera.

El cron de Moodle es necesario. Permite ejecutar procesos en segundo plano, limpiar datos, procesar colas, enviar notificaciones, sincronizar información y mantener viva la plataforma. Pero la pregunta importante no es solo si el cron se ejecuta. La pregunta importante es qué procesos dependen de él, cómo están diseñados, cuánto tardan, qué pasa cuando fallan y quién se entera cuando algo se acumula.

La propia documentación de desarrollo de Moodle describe la Task API como el subsistema para programar y ejecutar tareas, incluyendo tareas periódicas y tareas ad hoc. Pero usar la API no garantiza automáticamente un buen diseño.

Por eso, cuando audito un Moodle, no me quedo en “el cron está activo”. Reviso el diseño completo de la automatización: tareas programadas, adhoc tasks, duración del cron, procesos bloqueantes, locks, colas pendientes, faildelay, integraciones externas y trazabilidad de errores.

Síntomas de mala automatización en Moodle

Una mala arquitectura de automatización no siempre aparece como una caída total. Muchas veces es más sutil. El campus “funciona”, pero se vuelve errático justo cuando más importa: aperturas de matrícula, cierres de evaluación, exámenes, importaciones masivas, generación de certificados o sincronizaciones con sistemas externos.

Ampliar CPU o memoria puede darte margen temporal. Pero si la arquitectura sigue acoplando procesos lentos al flujo del usuario, el problema volverá. Y normalmente vuelve en el peor momento: cuando hay más alumnos conectados, más presión del cliente y menos margen para intervenir.

Mi framework para diseñar automatización en Moodle

Cuando reviso un proyecto Moodle, uso un marco muy simple. No empieza por “qué tarea programada creamos”, sino por entender el recorrido completo del proceso.

Qué procesos no deberían ejecutarse dentro de la petición del usuario

Una regla básica en Moodle, y en cualquier aplicación web seria, es que la petición HTTP del usuario debe ser rápida. Cuando un alumno pulsa un botón, entrega una actividad, se matricula en un curso o solicita un certificado, la plataforma debería responder de forma ágil.

Si detrás de ese clic se ejecuta un proceso que tarda 10, 20 o 30 segundos, ese usuario está ocupando un worker de PHP-FPM durante demasiado tiempo. Si varios usuarios hacen lo mismo a la vez, el servidor empieza a quedarse sin capacidad para atender nuevas peticiones.

• Sincronizaciones con ERP académico.
• Sincronizaciones con CRM.
• Altas o bajas masivas de usuarios.
• Generación de certificados PDF.
• Importaciones CSV pesadas.
• Recálculo masivo de calificaciones.
• Recálculo de progreso de curso.
• Envío masivo de correos.
• Creación de informes pesados.
• Procesamiento de ficheros grandes.
• Llamadas a APIs externas.
• Procesos de IA generativa o evaluación automática.
• Integraciones LTI que requieran validaciones externas lentas.
• Envío de datos a sistemas de analítica o business intelligence.

Scheduled tasks y adhoc tasks en Moodle: cuándo usar cada una

Moodle ofrece dos grandes mecanismos para trabajar con procesos en segundo plano: las scheduled tasks y las adhoc tasks. Ambas pertenecen a la Task API, pero no resuelven exactamente el mismo problema.

Las scheduled tasks encajan bien cuando el proceso debe ejecutarse cada cierto tiempo: cada hora, cada noche, cada semana o cada mes. Por ejemplo: limpiar registros antiguos, sincronizar cursos desde un sistema externo, revisar incidencias, actualizar estados de matrícula o enviar recordatorios programados.

Las adhoc tasks encajan cuando una acción concreta genera un trabajo que debe ejecutarse lo antes posible, pero no necesariamente dentro de la misma petición del usuario. Por ejemplo: un alumno solicita un certificado, un profesor lanza una importación, una integración externa requiere sincronizar un estado o un sistema de IA debe analizar una entrega.

La documentación oficial de Moodle sobre adhoc tasks las plantea precisamente para trabajos que se encolan y se ejecutan en segundo plano. En la práctica, muchos problemas de rendimiento aparecen porque se usa una petición web para hacer el trabajo que debería hacer una tarea ad hoc.

Arquitectura recomendada para automatización en Moodle

Una arquitectura más robusta para procesos pesados en Moodle debería seguir este patrón:

1. El usuario realiza una acción.
2. Moodle valida la petición y los permisos.
3. Se registra la intención de trabajo con un estado inicial.
4. Se encola una adhoc task o se programa una tarea adecuada.
5. La interfaz responde rápido con un mensaje claro.
6. Un worker o el cron procesa la tarea en segundo plano.
7. El resultado se registra con trazabilidad.
8. El usuario recibe feedback, notificación o estado actualizado.
9. Si falla, el sistema distingue entre error temporal y error funcional.

Este patrón evita que el usuario quede bloqueado esperando a que finalice una integración, un informe, una generación de PDF o una llamada a una API externa. También permite que el sistema sea más tolerante a fallos. Si el ERP está caído, Moodle no tiene por qué caerse con él. La tarea puede fallar, registrar el error y reintentarse más adelante.

Caso práctico de automatización en Moodle: matrículas y ERP académico

Imagina una universidad mediana española con 12.000 alumnos. Es 1 de septiembre. Abre la matrícula. En una arquitectura mal desacoplada, el flujo puede ser este:

1. El alumno hace clic en “Matricularme”.
2. Moodle guarda la matrícula en la base de datos local.
3. Moodle llama al ERP académico.
4. El ERP tarda 8 o 10 segundos en responder.
5. El alumno espera.
6. Si el ERP falla, la pantalla devuelve error y el estado puede quedar inconsistente.

El rediseño correcto sería este:

1. El alumno hace clic en “Matricularme”.
2. Moodle valida la operación y guarda la matrícula.
3. Moodle registra una operación pendiente de sincronización.
4. Moodle encola una adhoc task, por ejemplo sync_erp_enrollment.
5. El usuario recibe respuesta inmediata: “Matrícula confirmada”.
6. La tarea sincroniza con el ERP en segundo plano.
7. Si falla por un error temporal, se reintenta.
8. Si falla por un error funcional, se marca para revisión y se notifica al equipo responsable.

La diferencia para el usuario es enorme. En el primer caso, percibe lentitud o error. En el segundo, Moodle responde rápido y el sistema sigue trabajando por detrás.

Ejemplo simplificado de una adhoc task para sincronización con ERP:

namespace local_mi_plugin\task;

class sync_erp_enrollment extends \core\task\adhoc_task {

    public function execute() {
        $data = $this->get_custom_data();

        $client = new \GuzzleHttp\Client([
            'timeout' => 10,
            'connect_timeout' => 5,
        ]);

        try {
            $response = $client->post('https://erp.example.com/api/enrollment', [
                'json' => [
                    'userid' => $data->userid,
                    'courseid' => $data->courseid,
                    'operationid' => $data->operationid,
                    'timestamp' => time(),
                ],
            ]);

            mtrace('Sincronización completada para la operación ' . $data->operationid);

        } catch (\Throwable $e) {
            mtrace('Error al sincronizar con ERP: ' . $e->getMessage());
            throw $e; // Moodle podrá reintentar según el comportamiento de la tarea.
        }
    }
}

namespace local_mi_plugin\task;

class sync_erp_enrollment extends \core\task\adhoc_task {

    public function execute() {
        $data = $this->get_custom_data();

        $client = new \GuzzleHttp\Client([
            'timeout' => 10,
            'connect_timeout' => 5,
        ]);

        try {
            $response = $client->post('https://erp.example.com/api/enrollment', [
                'json' => [
                    'userid' => $data->userid,
                    'courseid' => $data->courseid,
                    'operationid' => $data->operationid,
                    'timestamp' => time(),
                ],
            ]);

            mtrace('Sincronización completada para la operación ' . $data->operationid);

        } catch (\Throwable $e) {
            mtrace('Error al sincronizar con ERP: ' . $e->getMessage());
            throw $e; // Moodle podrá reintentar según el comportamiento de la tarea.
        }
    }
}

Y el encolado desde el plugin:

$task = new \local_mi_plugin\task\sync_erp_enrollment();

$task->set_custom_data([
    'userid' => $USER->id,
    'courseid' => $courseid,
    'operationid' => $operationid,
]);

\core\task\manager::queue_adhoc_task($task);

$task = new \local_mi_plugin\task\sync_erp_enrollment();

$task->set_custom_data([
    'userid' => $USER->id,
    'courseid' => $courseid,
    'operationid' => $operationid,
]);

\core\task\manager::queue_adhoc_task($task);

Errores habituales en la automatización en Moodle

Una parte importante de los problemas de rendimiento en Moodle no viene del core, sino de plugins personalizados o integraciones desarrolladas sin una arquitectura clara. Estos son los errores que veo más frecuentemente.

La Lock API de Moodle existe precisamente para evitar que varios procesos accedan al mismo recurso crítico al mismo tiempo. Es especialmente importante en operaciones batch, cierres de curso, generación de documentos o sincronizaciones críticas.

Ejemplo simplificado de uso de Lock API:

$factory = \core\lock\lock_config::get_lock_factory('local_mi_plugin');
$lock = $factory->get_lock('batch_processing_lock', 120);

if (!$lock) {
    mtrace('Otra instancia ya está procesando estos datos.');
    return;
}

try {
    self::process_batch();
} finally {
    $lock->release();
}

$factory = \core\lock\lock_config::get_lock_factory('local_mi_plugin');
$lock = $factory->get_lock('batch_processing_lock', 120);

if (!$lock) {
    mtrace('Otra instancia ya está procesando estos datos.');
    return;
}

try {
    self::process_batch();
} finally {
    $lock->release();
}

Query SQL para diagnosticar adhoc tasks en Moodle

Una de las cosas que echo de menos en muchos Moodle es visibilidad sobre qué está pasando en segundo plano. Esta query SQL sirve como punto de partida para saber el estado real de las adhoc tasks:

SELECT 
    component,
    classname,
    COUNT(*) AS total_tasks,
    MIN(nextruntime) AS oldest_task_time,
    MAX(nextruntime) AS newest_task_time,
    COUNT(CASE WHEN faildelay > 0 THEN 1 END) AS tasks_with_faildelay,
    COUNT(CASE WHEN nextruntime < UNIX_TIMESTAMP() THEN 1 END) AS overdue_tasks
FROM mdl_task_adhoc
GROUP BY component, classname
ORDER BY total_tasks DESC, oldest_task_time ASC;

SELECT 
    component,
    classname,
    COUNT(*) AS total_tasks,
    MIN(nextruntime) AS oldest_task_time,
    MAX(nextruntime) AS newest_task_time,
    COUNT(CASE WHEN faildelay > 0 THEN 1 END) AS tasks_with_faildelay,
    COUNT(CASE WHEN nextruntime < UNIX_TIMESTAMP() THEN 1 END) AS overdue_tasks
FROM mdl_task_adhoc
GROUP BY component, classname
ORDER BY total_tasks DESC, oldest_task_time ASC;

Esta query te ayuda a detectar:

• total_tasks: cuántas tareas hay pendientes de cada tipo.
• oldest_task_time: cuándo se encoló la tarea más antigua.
• tasks_with_faildelay: cuántas tareas están en reintento por fallo.
• overdue_tasks: cuántas tareas deberían haberse procesado ya.

Si aparecen centenares de tareas con faildelay, o tareas que llevan días esperando, no estás viendo un “detalle técnico”. Estás viendo una señal de riesgo operativo.

Faildelay, reintentos y tolerancia a fallos

Uno de los puntos fuertes de las tareas en segundo plano es que permiten gestionar mejor los fallos. Cuando una adhoc task falla y lanza una excepción, Moodle puede aplicar un retraso antes de volver a intentarla. Este mecanismo evita perder trabajo pendiente por un fallo temporal.

Esto es especialmente útil en integraciones con sistemas externos:

• El ERP no responde.
• El CRM devuelve un error temporal.
• Una API está en mantenimiento.
• Un servicio de IA tarda más de lo esperado.
• Un sistema de videoconferencia no acepta la petición.
• Un proveedor externo limita temporalmente las llamadas.

En una arquitectura síncrona, cualquiera de estos fallos puede afectar directamente al usuario. En una arquitectura asíncrona, el usuario puede continuar y el sistema puede reintentarlo después.

Observabilidad en la automatización en Moodle

Una buena automatización en Moodle necesita métricas. No puedes mejorar lo que no ves. Y en automatización backend, lo peligroso es que los problemas no siempre se ven desde la interfaz.

IA y automatización en Moodle: el patrón obligatorio

La incorporación de IA en Moodle hace todavía más importante este enfoque. Cada vez es más habitual encontrar casos como generación automática de feedback, evaluación asistida de respuestas abiertas, clasificación de evidencias, resumen de foros, creación de preguntas, extracción de información documental o recomendaciones personalizadas.

El error sería llamar directamente a un modelo de IA desde la petición principal del usuario y dejar la página esperando hasta que el modelo responda. Esto puede ser especialmente problemático si el modelo está autoalojado, la inferencia tarda varios segundos, hay picos de demanda, se procesan documentos grandes, existen límites de rate limit o la respuesta requiere validación posterior.

En estos casos, la arquitectura correcta suele ser asíncrona:

1. El usuario solicita la acción.
2. Moodle registra la petición.
3. Se encola una tarea.
4. El sistema procesa la IA en segundo plano.
5. El resultado queda disponible más tarde.
6. El usuario recibe una notificación o ve el estado actualizado.

Checklist de auditoría de automatización en Moodle

Si quieres saber si tu Moodle tiene una automatización sana, empieza con estas preguntas. Son las que uso como base cuando reviso cron, tareas, plugins personalizados e integraciones.

Cuándo merece la pena auditar la automatización en Moodle

No todos los Moodle necesitan una auditoría compleja. Pero hay momentos en los que revisar la automatización es especialmente recomendable:

• Antes de una migración importante de versión.
• Antes de abrir un periodo de matrículas masivas.
• Antes de incorporar IA en procesos docentes.
• Cuando se han desarrollado varios plugins personalizados.
• Cuando Moodle se integra con ERP, CRM, LTI, BI o sistemas externos.
• Cuando hay problemas recurrentes de timeouts.
• Cuando el cron tarda demasiado.
• Cuando se acumulan adhoc tasks.
• Cuando aparecen duplicados en procesos críticos.
• Cuando el campus se vuelve lento en momentos de alta demanda.
• Cuando el equipo técnico no tiene visibilidad clara de lo que ocurre en segundo plano.

Una auditoría de automatización no consiste solo en mirar si el cron está activo. Debe revisar cómo se ejecutan los procesos críticos, qué dependencias externas existen, qué plugins generan carga y qué mecanismos de control hay implementados.

Preguntas frecuentes sobre automatización en Moodle

¿Cada cuánto debería ejecutarse el cron de Moodle?

En instalaciones profesionales, lo habitual es que el cron se ejecute cada minuto. Pero esa frecuencia solo resuelve una parte del problema. También hay que revisar cuánto tarda, qué tareas procesa y si la cola crece más rápido de lo que puede vaciarse.

¿Cuándo conviene usar una adhoc task?

Conviene usar una adhoc task cuando una acción concreta genera trabajo que debe hacerse pronto, pero no dentro de la petición web. Por ejemplo, generar un certificado, sincronizar una matrícula, enviar datos a un CRM o procesar una entrega con IA.

¿Cuándo conviene usar una scheduled task?

Conviene usar una scheduled task para procesos periódicos y previsibles: limpiezas, sincronizaciones nocturnas, revisión de estados, recordatorios o mantenimiento programado.

¿Por qué es peligrosa una integración síncrona con ERP o CRM?

Porque Moodle queda ligado a la velocidad y disponibilidad del sistema externo. Si el ERP tarda, el usuario espera. Si el ERP falla, Moodle aparenta fallar. En procesos críticos, normalmente es mejor registrar la operación y sincronizar en segundo plano.

¿La IA debe ejecutarse dentro de Moodle?

Depende del caso. Moodle puede iniciar el proceso y mostrar el resultado, pero el procesamiento pesado de IA debería ejecutarse de forma asíncrona, especialmente si tarda varios segundos, usa documentos grandes o depende de APIs externas.

¿Ampliar servidor soluciona estos problemas?

A veces ayuda, pero no corrige el problema de fondo si los procesos siguen mal desacoplados. Puedes ganar margen de tiempo, pero si la arquitectura mantiene llamadas lentas dentro de la petición web, el cuello de botella volverá.

Conclusión: automatizar Moodle es diseñar arquitectura

La automatización en Moodle no debería entenderse como una tarea menor de administración. Bien diseñada, permite que el campus virtual sea más rápido, más estable y más resistente a fallos. Mal diseñada, puede convertirse en una de las principales causas de lentitud, errores intermitentes y problemas difíciles de diagnosticar.

La diferencia está en cómo se separan los procesos:

• Lo inmediato debe responder rápido.
• Lo pesado debe ejecutarse en segundo plano.
• Lo crítico debe ser idempotente.
• Lo concurrente debe protegerse con locks.
• Lo externo debe tener timeouts y reintentos.
• Lo importante debe monitorizarse.

Ese es el salto que diferencia un Moodle que simplemente “funciona” de un Moodle preparado para operar con garantías en entornos profesionales, institucionales o corporativos.