Automatización en Moodle con tareas programadas: guía práctica 2026 para cron, adhoc tasks y arquitectura backend

Hace un año, una universidad me contactó en agosto. «Andrés, Moodle va lento durante las matrículas. ¿Puedes revisar el servidor?» Mi previsión inicial: ampliar a 32GB de RAM.

Revisé. El servidor tenía capacidad de sobra. El problema era otro.

Resulta que cada vez que alguien se matriculaba, Moodle intentaba sincronizar con el ERP académico de forma síncrona. Si el ERP tardaba 10 segundos, el usuario esperaba 10 segundos. Si el ERP fallaba, la matrícula quedaba en estado inconsistente.

Eso no se resuelve amplificando infraestructura. Se resuelve rediseñando cómo funciona la automatización.

Puede que tengas un problema de arquitectura backend.

En la mayoría de proyectos Moodle que audito, el primer diagnóstico suele ser siempre el mismo: «necesitamos más CPU», «la base de datos va lenta», «el servidor se queda corto». Y a veces, efectivamente, hay margen de mejora. Pero en la mayoría de casos el problema real está en otro sitio: procesos pesados que se ejecutan en el momento equivocado, en el lugar equivocado, dentro del flujo de navegación del usuario. He escrito sobre automatización avanzada en Moodle específicamente para esto.

La automatización en Moodle no consiste únicamente en tener el cron configurado. Eso es solo el punto de partida. Automatizar bien significa diseñar procesos robustos, desacoplados, observables y preparados para fallar sin comprometer la experiencia del usuario.

Y esto, en 2026, ya no es un detalle técnico menor. Es una cuestión de estabilidad, escalabilidad y continuidad operativa.

¿Cuándo el cron activo no es suficiente? El falso mito de la automatización

Durante años he visto a muchos equipos reducir la automatización en Moodle a una comprobación muy 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, y yo mismo he caído en esa trampa al principio de mi carrera.

El cron de Moodle es necesario, pero no suficiente. Es el mecanismo que permite ejecutar tareas en segundo plano, limpiar datos, procesar colas, enviar notificaciones, sincronizar información y mantener viva la plataforma. Sin embargo, lo importante no es solo que el cron se ejecute, sino qué procesos dependen de él, cómo están diseñados y qué ocurre cuando fallan.

Un Moodle puede tener el cron activo cada minuto y, aun así, sufrir problemas graves de rendimiento si:

• Los plugins personalizados ejecutan procesos pesados dentro de la petición web.
• Las integraciones con ERP o CRM se realizan de forma síncrona.
• Las tareas adhoc se acumulan sin monitorización.
• No existen mecanismos de bloqueo para evitar duplicados.
• Las llamadas a APIs externas no tienen timeout ni reintentos controlados.
• La generación de certificados, informes o contenidos se hace mientras el usuario espera.

En otras palabras: tener cron activo no garantiza una arquitectura sana.

Garantiza, como mucho, que Moodle tiene un mecanismo disponible para ejecutar procesos en segundo plano. Pero la calidad de esa automatización depende del diseño técnico que hay detrás.

Síntomas de una mala automatización: dónde falla Moodle en realidad

En mis auditorías, una mala arquitectura de automatización no siempre se manifiesta como una caída total del sistema. Muchas veces aparece de forma más sutil.

El campus virtual «funciona», pero empieza a comportarse de manera errática justo en los momentos importantes: aperturas de matrícula, exámenes, cierres de evaluación, importaciones masivas, generación de certificados o sincronizaciones con sistemas externos.

Estos son algunos síntomas que encuentro habitualmente:

Este tipo de síntomas no se resuelven solo ampliando servidor. Puedes ganar tiempo añadiendo CPU o memoria, pero si la arquitectura sigue acoplando procesos lentos al flujo del usuario, el problema volverá dentro de 6 meses.

Lo sé porque lo he visto suceder.

Qué procesos no deberían ejecutarse nunca 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.

Y cuando varios usuarios hacen lo mismo a la vez, el servidor se queda sin capacidad para atender nuevas peticiones.

En Moodle, recomiendo evitar ejecutar de forma síncrona estos procesos:

• Sincronizaciones con ERP académico.
• Sincronizaciones con CRM.
• Altas o bajas masivas de usuarios.
• Generación de certificados PDF.
• Importaciones CSV pesadas.
• Recalculo masivo de calificaciones.
• Recalculo 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.

Estos procesos no son malos. De hecho, muchos son imprescindibles. El problema aparece cuando se ejecutan en el momento incorrecto.

La pregunta clave no es:

¿Puede Moodle hacer esto?

La pregunta correcta es:

¿Debe hacerlo mientras el usuario espera delante de la pantalla?

En muchos casos, la respuesta será no.

Scheduled tasks vs. adhoc tasks: cuándo usar cada una

Moodle ofrece dos grandes mecanismos para trabajar con tareas en segundo plano: las scheduled tasks y las adhoc tasks.

Ambas forman parte de la Task API de Moodle, pero no resuelven exactamente el mismo problema.

Las scheduled tasks son adecuadas para procesos que deben 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 tickets o incidencias.
• Actualizar estados de matriculación.
• Enviar recordatorios programados.
• Archivar datos temporales.

Las adhoc tasks, en cambio, son ideales 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 usuario se matricula y hay que comunicarlo al ERP.
• Un alumno solicita un certificado y hay que generar un PDF.
• Un profesor lanza una importación de datos.
• Una integración externa requiere sincronizar un estado.
• Una actividad genera un evento que debe procesarse después.
• Un sistema de IA debe analizar una entrega o generar feedback.

La diferencia es importante porque muchos problemas de rendimiento en Moodle aparecen cuando se usa una petición web para hacer el trabajo que debería hacer una adhoc task.

Arquitectura recomendada para procesos pesados en Moodle

Una arquitectura más robusta para Moodle debería seguir este patrón (es el que recomiendo en mis auditorías):

1. El usuario realiza una acción.
2. Moodle valida la petición.
3. Se registra la intención de trabajo.
4. Se encola una adhoc task.
5. La interfaz responde rápidamente.
6. Un worker o el cron procesa la tarea en segundo plano.
7. El resultado se registra.
8. El usuario recibe feedback, notificación o estado actualizado.

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.

Este cambio de enfoque es clave: Moodle deja de depender de que todo funcione exactamente en el momento del clic y pasa a operar con una arquitectura más resiliente.

Caso práctico: universidades españolas durante la matrícula de septiembre

Déjame darte un caso real que me encontré hace poco. Una universidad mediana española con 12.000 alumnos. Es 1 de septiembre. Abre la matrícula.

En una arquitectura mal desacoplada (como estaba aquella institución):

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 (Universitas XXI, SAP, etc.).
4. El ERP tarda 8 segundos en responder (o falla).
5. El alumno espera.
6. Si el ERP falla, la pantalla devuelve error y la matrícula queda en estado inconsistente.

Después de mi revisión y recomendaciones, lo implementamos así:

1. El alumno hace clic en «Matricularme».
2. Moodle guarda la matrícula.
3. Moodle encola una adhoc task llamada «sync_erp_enrollment».
4. El usuario recibe respuesta inmediata: «Matrícula confirmada».
5. La tarea sincroniza con el ERP en segundo plano (en el siguiente cron o en un worker dedicado).
6. Si falla, Moodle reintenta automáticamente.
7. Si el error persiste después de varios reintentos, queda registrado en logs para revisión manual.

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,
                    'timestamp' => time(),
                ],
            ]);

            mtrace('Sincronización completada para el usuario ' . $data->userid);

        } catch (\Throwable $e) {
            mtrace('Error al sincronizar con ERP: ' . $e->getMessage());
            throw $e; // Moodle reintenta
        }
    }
}

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,
                    'timestamp' => time(),
                ],
            ]);

            mtrace('Sincronización completada para el usuario ' . $data->userid);

        } catch (\Throwable $e) {
            mtrace('Error al sincronizar con ERP: ' . $e->getMessage());
            throw $e; // Moodle reintenta
        }
    }
}

Y el encolado desde el plugin:

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

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

\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,
]);

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

Este código no pretende ser una implementación final de producción, pero ilustra el patrón: la acción del usuario no debe cargar con todo el proceso.

Errores habituales que encuentro en auditorías

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:

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();
}

Monitorizar la cola de adhoc tasks: query SQL para diagnóstico

Una de las cosas que echo de menos en muchos Moodle es visibilidad sobre qué está pasando en segundo plano. Aquí te doy la query SQL que uso en mis auditorías. Puedes ejecutarla directamente contra tu base de datos Moodle 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 devuelve:

• total_tasks: cuántas tareas hay pendientes de este tipo.
• oldest_task_time: cuándo se encoló la tarea más antigua (si es muy vieja, hay un problema).
• tasks_with_faildelay: cuántas tareas están en reintento por fallo.
• overdue_tasks: cuántas tareas deberían haberse procesado ya pero aún están pendientes.

Si ves que hay centenares de tareas con faildelay, o tareas que llevan días esperando, tienes un problema de automatización que necesita atención.

Faildelay y reintentos: cuando fallan los sistemas externos

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 el trabajo pendiente por un fallo temporal.

Esto es especialmente útil en integraciones con sistemas externos:

• El ERP no responde.
• El CRM devuelve 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.

Ahora bien, los reintentos no sustituyen a un buen diseño. Una tarea que falla siempre por un error de datos no debería reintentarse eternamente. Hay que distinguir entre fallo temporal y fallo permanente.

Observabilidad: lo que deberías medir en producción

Una buena automatización en Moodle necesita métricas, y esa es una de las cosas que más falta veo en las instalaciones que audito.

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.

Como mínimo, deberías revisar estas métricas:

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

La incorporación de IA en Moodle hace todavía más importante este enfoque. Es una de las tendencias que más estoy viendo en las instituciones que me contactan.

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.
• Generación de contenidos.
• Extracción de información de documentos.
• Creación de preguntas.
• Análisis de participación.
• 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 cuando:

• El modelo está autoalojado.
• La inferencia tarda varios segundos.
• Hay picos de demanda.
• Se procesan documentos grandes.
• Se depende de APIs externas.
• Hay límites de rate limit.
• 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 para tu Moodle

Si quieres saber si tu Moodle tiene una automatización sana, usa este checklist. Son las preguntas que yo hago en cada auditoría.

Si varias respuestas son negativas, tu Moodle probablemente no necesita solo «más servidor».

Cuándo merece la pena auditar tu automatización

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 o sistemas externos.
• Cuando hay problemas recurrentes de timeouts.
• Cuando el cron tarda demasiado.
• Cuando se acumulan tareas adhoc.
• Cuando hay duplicados en procesos críticos.
• Cuando el campus virtual se vuelve lento en momentos de alta demanda.
• Cuando el equipo técnico no tiene visibilidad clara de qué 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.

Conclusión: automatizar Moodle no es ejecutar cron, 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. Yo lo veo constantemente en mis auditorías.

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.
• Y todo 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.