La diferencia entre un incidente resuelto en cinco minutos y uno que arruina una tarde de exámenes casi nunca está en la gravedad técnica del fallo, está en cuánto tiempo tarda alguien en enterarse de que algo va mal. Una monitorización de uptime bien configurada reduce ese tiempo de detección de horas a segundos, y es una de las piezas de infraestructura más baratas de montar en relación al problema que evita.
En esta guía vas a ver qué comprobar exactamente, con qué frecuencia, y cómo montar un sistema de avisos que te entere antes que tus alumnos.
Qué significa monitorización real (y qué no lo es)
Revisar manualmente si el sitio carga bien “de vez en cuando” no es monitorización, es una comprobación puntual con enormes huecos de tiempo sin vigilancia entre una revisión y la siguiente. La monitorización real es un proceso automatizado y continuo que comprueba el estado del servicio a intervalos regulares (minutos, no horas) y dispara una alerta inmediata en cuanto detecta una anomalía, sin depender de que una persona se acuerde de mirar.
Aquí es donde casi todas las monitorizaciones caseras fallan: se quedan en el chequeo superficial. “¿Responde el puerto 80?” es una pregunta de red, no de aplicación. Un curl al dominio puede devolver un 200 OK perfecto mientras Moodle está roto por dentro: la base de datos ha dejado de responder y la home muestra un error genérico de conexión con estado 200, el cron lleva horas parado y las tareas se acumulan, o la sesión de login rebota en bucle porque una tabla de sesiones se quedó bloqueada. El servidor “está arriba” para el monitor y “está caído” para el alumno.
El chequeo real entra un nivel más adentro: no pregunta si el puerto contesta, pregunta si la página de login carga de verdad y se puede autenticar. Comprueba que el HTML devuelto contiene el formulario esperado (y no una pantalla de error de PHP o de la base de datos), que el certificado sigue siendo válido, que el cron corrió hace minutos y que el backup de anoche existe y pesa lo que debe. La diferencia entre los dos enfoques es exactamente la diferencia entre enterarte tú a las 8:00 o enterarte por un correo de un alumno a las 9:15, en mitad del examen. Si quieres el contexto operativo completo de cómo encaja esto en el mantenimiento de una plataforma, lo desarrollamos en la guía de soporte y monitorización de Moodle.
Los siete puntos que de verdad hay que vigilar
Estos son los siete controles que separan una monitorización de escaparate de una que evita incidentes reales. Para cada uno importa tanto cómo se comprueba como qué umbral dispara la alerta: un check sin umbral definido acaba ignorándose.
1. Disponibilidad HTTP (código 200). Se comprueba pidiendo la home o, mejor, la página de login y leyendo el código de estado: curl -so /dev/null -w "%{http_code}" https://tuaula.com/login/index.php. El umbral de alerta es cualquier código distinto de 200 (o 302 si hay una redirección legítima) durante dos o más comprobaciones consecutivas, un fallo aislado suele ser un microcorte de red, no una caída real. Refuerza el check comprobando que el cuerpo contiene una cadena esperada (por ejemplo el texto del botón de acceso), porque un 200 con una página de error de PHP es una caída disfrazada.
2. Tiempo de respuesta. El mismo curl te lo da con -w "%{time_total}". No hay un número mágico universal, así que se mide contra la línea base del propio sitio: si normalmente responde en 400-800 ms, un salto sostenido a más de 2-3 segundos es degradación y más de 5 segundos es prácticamente inservible. Una subida progresiva del tiempo de respuesta casi siempre precede a la caída total, es la señal más temprana que tienes.
3. Validez del certificado SSL. No basta con que el HTTPS “funcione hoy”: hay que vigilar la fecha de caducidad antes de que llegue. Se lee así:
echo | openssl s_client -connect tuaula.com:443 -servername tuaula.com 2>/dev/null \
| openssl x509 -noout -enddateEl umbral de alerta es 14-30 días antes de la caducidad. Con Let’s Encrypt (certificados de 90 días que renuevan a los 60) el aviso a 14 días te da margen de sobra para investigar por qué la renovación automática no se disparó. Un certificado caducado no degrada: bloquea el acceso con un “sitio no seguro” a pantalla completa.
4. Espacio en disco. Se mira con df -h sobre la partición donde viven moodledata y la base de datos (que a menudo no es la raíz). El umbral habitual es aviso al 80-85% y crítico al 90%. moodledata crece de forma silenciosa (archivos de curso, caché, sesiones, backups temporales) y un disco lleno provoca fallos difíciles de diagnosticar: subidas que fallan a medias, sesiones que no se guardan, backups que se cortan.
5. Ejecución del cron. El cron es el corazón de Moodle: sin él no salen las notificaciones, no se procesan las colas, no corren los backups programados ni los informes. Y lo peligroso es que un cron parado no genera ningún error visible en la web. Se comprueba mirando cuándo corrió por última vez, en la interfaz, en Administración del sitio → Servidor → Tareas → Tareas programadas, o de forma automatizada con la API de comprobaciones que Moodle incluye desde la 3.9 (php admin/cli/checks.php), . El umbral: alerta si el cron no se ha ejecutado en más de una hora, dado que lo normal es que corra cada minuto. Profundizamos en por qué es tan crítico en el cron de Moodle.
6. Backups recientes. Que los backups estén “configurados” no significa que se estén generando. Se verifica comprobando la fecha de modificación y el tamaño del último fichero en el destino de copias: un backup con mtime de hace tres días, o que de repente pesa una décima parte de lo habitual, es una copia que no te va a salvar. El umbral: alerta si no hay copia en las últimas 24-48 horas o si el tamaño cae bruscamente frente a la serie anterior. Comprobar que existen no es suficiente; que restauren es otra historia que tratamos en verificar backups de Moodle.
7. Login funcional (chequeo sintético). Es el control que corona todos los demás, porque el login es la función más crítica y la que más “cosas por debajo” ejerce a la vez (BD, sesiones, PHP, plantilla). Un chequeo sintético reproduce el flujo real: pide /login/index.php, extrae el logintoken del formulario, envía un POST con unas credenciales de prueba y confirma que llega al panel autenticado (/my/) y no de vuelta a la pantalla de login con un error. Si ese recorrido se rompe, el sitio está roto para el usuario aunque devuelva 200 en la home. Umbral: alerta al primer fallo confirmado del recorrido completo.
| Qué se comprueba | Cómo se comprueba | Umbral de alerta | Por qué importa |
|---|---|---|---|
| Disponibilidad HTTP | curl -w "%{http_code}" sobre /login + verificar cadena esperada | ≠ 200/302 en 2+ checks seguidos | Un puerto que responde no garantiza una app viva |
| Tiempo de respuesta | curl -w "%{time_total}", comparado con la línea base | > 2-3 s degradado, > 5 s crítico | La degradación precede a la caída total |
| Certificado SSL | openssl s_client → -enddate | 14-30 días antes de caducar | Un certificado caducado bloquea el acceso entero |
| Espacio en disco | df -h en la partición de moodledata y BD | 80-85% aviso, 90% crítico | El disco lleno provoca fallos silenciosos y difusos |
| Ejecución del cron | Tareas programadas / admin/cli/checks.php | Sin correr > 1 h (se espera cada minuto) | Un cron parado no da error visible pero acumula daño |
| Backups recientes | mtime y tamaño del último fichero de copia | Sin copia en 24-48 h o tamaño anómalo | ”Configurado” no es lo mismo que “se está generando” |
| Login funcional | Chequeo sintético: POST con logintoken → /my/ | Fallo del recorrido completo | Es la función crítica; el 200 no la garantiza |
Con qué frecuencia comprobar
Para la disponibilidad básica, intervalos de 1 a 5 minutos son razonables, cuanto más corto el intervalo, antes se detecta un problema, aunque también aumenta ligeramente la carga sobre el servidor monitorizado (poco significativa en comparación con el beneficio). Para comprobaciones más pesadas (backups, espacio en disco), una frecuencia diaria suele ser suficiente.
Herramientas y enfoques para montarlo
No hace falta una plataforma cara. Los tres enfoques se combinan por capas, de fuera hacia dentro:
Monitor externo desde otra red. La primera capa vigila desde fuera: un servicio tipo UptimeRobot, Better Stack o Pingdom pide tu URL cada minuto desde servidores ajenos a tu infraestructura. Su gran ventaja es que si tu servidor entero cae (o cae su conexión) el monitor lo ve, cosa que un script alojado en el propio servidor no puede hacer (si el servidor se cae, el vigilante se cae con él). Configúralo para que valide el código 200 y una palabra clave en la respuesta, no solo que “algo conteste”.
Endpoint de healthcheck en el propio Moodle. La segunda capa mira hacia dentro. Moodle incluye desde la 3.9 una API de comprobaciones (Check API) y un informe de estado en Administración del sitio → Informes → Estado del sistema, además del comando php admin/cli/checks.php, que agrega el estado de cron, seguridad, entorno y más. Puedes exponer un endpoint propio muy ligero (un pequeño script que devuelva OK o un JSON con el estado del cron, la conexión a BD y el disco) y hacer que el monitor externo lo consulte: así una sola petición te dice si las tripas están sanas, no solo si la puerta abre.
Chequeo sintético de login. La tercera capa es la que de verdad reproduce a un usuario: un script programado que ejecuta el flujo de autenticación completo (el punto 7 de la tabla) y avisa si no llega al panel. Es más pesado, así que se corre con menos frecuencia (cada 5-15 minutos), pero es el único que detecta que el login está roto aunque todo lo demás parezca verde.
Cómo deben llegar los avisos
Un sistema de monitorización que solo registra el problema en un panel que nadie revisa activamente no es mejor que no tener monitorización. Los avisos deben llegar por un canal que realmente se vea de inmediato: notificación push a un teléfono, SMS, o una llamada automatizada para incidentes críticos fuera de horario, el correo electrónico solo, sin más, es insuficiente si nadie lo revisa constantemente.
Evitar falsas alarmas sin perder sensibilidad real
Un sistema que avisa por cualquier fluctuación mínima de tiempo de respuesta genera fatiga de alertas, con el tiempo, las notificaciones dejan de tomarse en serio, precisamente cuando llega la que sí importa. El equilibrio correcto es definir umbrales razonables (por ejemplo, varios fallos consecutivos antes de disparar una alerta, no un único fallo puntual que podría ser una anomalía de red momentánea) sin llegar al extremo de ignorar degradaciones reales.
Monitorización especialmente crítica antes de un examen
Antes de cualquier evento con plazo cerrado (un examen síncrono, una convocatoria con fecha límite), conviene reforzar la vigilancia: verificar manualmente que todos los sistemas de aviso están activos, confirmar que hay alguien disponible para reaccionar durante la ventana crítica, y hacer una comprobación explícita de que el cron, el certificado SSL y el espacio en disco están en orden, no confiar únicamente en que “la monitorización ya se encarga” sin una revisión activa previa al evento. Y si a pesar de todo el sitio se cae en el peor momento, tener claro el protocolo de reacción marca la diferencia: lo detallamos en qué hacer cuando Moodle se cae durante un examen.
Qué hacer con los datos históricos de monitorización
Más allá de la alerta puntual, el histórico de tiempos de respuesta y disponibilidad te permite detectar patrones de degradación progresiva (por ejemplo, un tiempo de carga que va empeorando semana a semana) antes de que se convierta en una caída total. Revisar este histórico periódicamente, no solo reaccionar a alertas puntuales, es parte de una monitorización realmente proactiva.
Errores comunes al montar la monitorización
- Quedarse en el chequeo superficial: vigilar solo que “algo responde” en el puerto y no que la app funciona por dentro (login, cron, BD).
- Alojar el vigilante en el propio servidor: cuando cae entero, el monitor cae con él y nunca avisa.
- Recibir avisos solo por correo, sin un canal que garantice que se ven de inmediato.
- No definir umbrales: un check sin umbral claro acaba ignorándose, y otro demasiado sensible genera fatiga de alertas.
Preguntas frecuentes
¿Con qué frecuencia debería comprobarse la disponibilidad de mi Moodle? Cada 1 a 5 minutos es una frecuencia razonable para detectar caídas con rapidez, sin generar una carga significativa sobre el servidor.
¿El correo electrónico es suficiente para recibir avisos de caída? No es lo más fiable por sí solo, especialmente fuera de horario laboral. Un canal más inmediato (notificación push, SMS, llamada automatizada para incidentes críticos) reduce el tiempo real de reacción.
¿Qué pasa si mi sistema de monitorización genera demasiadas falsas alarmas? Con el tiempo, las alertas dejan de tomarse en serio, justo cuando llega la que sí importa. Ajustar los umbrales (varios fallos consecutivos antes de alertar) reduce este riesgo sin perder sensibilidad real ante problemas genuinos.
¿Necesito monitorizar el cron además de la disponibilidad general? Sí, un cron detenido no genera ningún error visible en el sitio, pero acumula un problema silencioso que solo se detecta si se vigila específicamente.
¿Debo reforzar la monitorización antes de un examen? Sí, es recomendable una comprobación explícita previa (certificado SSL, espacio en disco, cron, disponibilidad del equipo de reacción) en vez de confiar únicamente en la vigilancia automática de fondo.
¿Cómo detecto una degradación progresiva de rendimiento antes de que se convierta en una caída? Revisando el histórico de tiempos de respuesta con regularidad, no solo reaccionando a alertas puntuales de caída total.
Mi Moodle devuelve 200 pero los alumnos no pueden entrar. ¿Cómo es posible? Porque el código 200 solo dice que el servidor web contestó, no que la aplicación funcione. La base de datos puede estar caída, el cron parado o la tabla de sesiones bloqueada, y aun así la home devuelve una página (de error) con estado 200. Por eso hace falta un chequeo real que valide el contenido de la respuesta y, mejor aún, un chequeo sintético que complete el login de verdad.
¿Puedo montar la monitorización en el mismo servidor que aloja el Moodle? Puedes para las comprobaciones internas (cron, disco, backups), pero no para la disponibilidad externa: si el servidor se cae entero, el vigilante que vive dentro se cae con él y nunca te avisa. Por eso la capa de disponibilidad debe correr desde una red externa, ajena a tu infraestructura.
¿Cada cuánto debo comprobar el certificado SSL? Basta con una comprobación diaria de la fecha de caducidad; no cambia de un minuto a otro. Lo importante es que la alerta salte con 14-30 días de margen, tiempo suficiente para investigar por qué falló la renovación automática antes de que el certificado bloquee el acceso.
¿Qué diferencia hay entre un healthcheck y un chequeo sintético de login? El healthcheck es un endpoint ligero que te informa del estado interno (BD, cron, disco) en una sola petición barata que puedes lanzar cada minuto. El chequeo sintético reproduce el flujo completo de un usuario que se autentica: es más pesado y se corre con menos frecuencia, pero es el único que confirma que el login funciona de punta a punta.
Conclusión
Montar una monitorización de uptime real no es complicado técnicamente, lo que marca la diferencia es la disciplina de revisarla, ajustar sus umbrales, y reforzarla antes de los momentos que de verdad importan. La inversión de tiempo es mínima comparada con el coste de enterarte de un problema porque un alumno te lo dice en mitad de un examen.
Si prefieres que alguien vigile esto por ti de forma continua, en Avantys lo incluimos como parte del mantenimiento de cada Moodle que gestionamos. Puedes pedir una auditoría gratuita en Moodle Gestionado.
Artículos relacionados
- Mantenimiento y hosting Moodle: guía completa
- Qué hacer cuando Moodle se cae durante un examen
- El cron de Moodle: por qué es crítico
- Backups de Moodle: cómo verificar que restauran de verdad
¿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.
