Es el escenario que más ansiedad genera a cualquier administrador de Moodle: un examen en marcha, decenas de alumnos conectados a la vez, y de repente el sitio deja de responder. Lo que separa un incidente bien gestionado de un desastre de confianza no es evitar que esto ocurra alguna vez (ningún sistema es infalible al 100%) sino tener un protocolo claro para actuar en los primeros minutos, en vez de improvisar bajo presión.
En esta guía vas a ver qué hacer en el momento del incidente, cómo comunicarlo, y cómo decidir sobre plazos y evaluación de forma justa para todos los alumnos.
Los primeros cinco minutos: diagnóstico rápido
Antes de tocar nada, responde a una pregunta: ¿el problema es de la plataforma, de la red del alumno, o de un pico de carga? Los tres se sienten igual desde el otro lado, “no me carga el examen”: pero cada uno se arregla de forma distinta, y actuar sobre el diagnóstico equivocado te hace perder los minutos que más valen.
- Confirma que el problema es real y generalizado, no un fallo puntual de conexión de un alumno concreto. Intenta acceder tú mismo desde una conexión distinta (datos móviles, otra red) y mira tu panel de monitorización.
- Identifica el alcance: ¿afecta a todo el sitio, o solo a una función concreta (por ejemplo, el envío del cuestionario)? Un sitio que carga pero falla justo al enviar respuestas apunta a saturación, no a una caída total.
- Revisa si hay una causa evidente e inmediata (servidor caído por completo, error de base de datos en pantalla) frente a algo que requiere investigación más profunda.
Esta tabla resume las tres pistas que puedes leer en segundos, sin abrir un solo log:
| Qué observas | Origen más probable | Cómo confirmarlo en segundos |
|---|---|---|
| Un alumno reporta fallo, el resto sigue enviando | Red o dispositivo de ese alumno | Que recargue o cambie de red; comprueba si hay más quejas |
| Nadie carga el sitio desde varias conexiones | Plataforma caída (servidor o base de datos) | Accede tú desde otra red; mira el panel de uptime |
| El sitio va lento y falla al enviar respuestas | Pico de carga / concurrencia | Revisa CPU y número de usuarios conectados a la vez |
| Error de base de datos visible en pantalla | Conexiones a la BD agotadas o BD caída | Suele coincidir con el arranque simultáneo del examen |
Si el origen es la red de un alumno aislado, no hay incidente que gestionar a nivel de plataforma: se resuelve con ese alumno. Si es la plataforma o un pico, activas el protocolo completo que sigue.
Comunicación inmediata: no esperes a tener la solución
El error más común es esperar a resolver el problema antes de comunicar nada, dejando a los alumnos sin información durante minutos que se sienten eternos en mitad de un examen. La comunicación inmediata, aunque sea breve (“Somos conscientes del problema, estamos trabajando en ello, mantened la calma”), reduce significativamente la ansiedad y el volumen de consultas simultáneas que puedes recibir por otros canales mientras intentas resolver el incidente técnico.
Canales a tener preparados de antemano:
- Un aviso en la propia plataforma (si sigue parcialmente accesible) o en una página de estado alternativa.
- Un correo o mensaje masivo a los participantes del examen concreto.
- Un canal de comunicación directa con el profesor o responsable del examen, para que pueda informar verbalmente si hay alumnos presenciales.
Un detalle que importa: el mensaje debe ser el mismo para todos y salir una sola vez. Si a unos les dices “esperad” y a otros “seguid en cuanto podáis”, estás sembrando el trato desigual antes incluso de decidir sobre los plazos. Ten redactada una plantilla neutra del tipo: “Estamos al tanto de un problema con la plataforma que afecta al examen en curso. No cerréis la ventana del intento. Os avisaremos en cuanto se restablezca y ajustaremos el tiempo para que nadie salga perjudicado.” Nótese lo que hace ese texto: pide no cerrar la pestaña (para no perder el intento) y adelanta que habrá compensación de tiempo, que es justo lo que reduce el pánico.
Las herramientas del cuestionario que amortiguan la caída
Moodle no te deja indefenso ante una caída a mitad de examen. El módulo de cuestionario incluye varios mecanismos que, bien configurados de antemano, convierten un incidente grave en una molestia menor. Estos son los que de verdad marcan la diferencia:
Guardado automático de respuestas. Mientras un alumno responde, Moodle guarda sus respuestas de forma periódica sin que pulse “Enviar”. Si su navegador se cierra o pierde la conexión, al volver a entrar recupera el intento con lo que llevaba hasta el último guardado. El periodo de autoguardado es configurable desde la administración del cuestionario; acortarlo antes de un examen crítico reduce cuánto trabajo puede perder un alumno en una caída, a cambio de algo más de carga en el servidor.
Excepciones de usuario y de grupo (overrides). Dentro de cada cuestionario, en “Excepciones de usuario” y “Excepciones de grupo”, puedes cambiar (solo para alumnos o grupos concretos, sin tocar el examen del resto) la fecha de apertura y cierre, el tiempo límite y el número de intentos permitidos. Es la herramienta central para reparar el daño: si un grupo perdió veinte minutos, les amplías el cierre veinte minutos; si alguien se quedó fuera, le subes un intento para que pueda volver a entrar.
Margen de gracia al enviar (graceperiod). En los ajustes del cuestionario, la opción “Cuando el tiempo expira” permite activar un margen de gracia: al agotarse el tiempo, el alumno ya no responde más preguntas, pero dispone de unos minutos extra para enviar lo que tenga. En un pico de latencia justo al final (el momento más frágil, cuando decenas de intentos se envían a la vez) ese margen evita que respuestas completas se queden sin registrar.
Reabrir y ampliar en caliente. Combinando lo anterior, durante el incidente puedes reabrir el acceso a quien quedó fuera (subiendo intentos por excepción) y ampliar el plazo a todos por igual (moviendo la fecha de cierre). Hazlo siempre desde las excepciones, no cambiando el examen base, para no alterar la configuración de quienes ya habían terminado.
El matiz que casi nadie tiene en cuenta: la mayoría de esto hay que decidirlo antes. Un cuestionario con autoguardado corto, margen de gracia activado y fechas holgadas absorbe una caída de varios minutos casi sin secuelas. El mismo examen sin nada de eso convierte cualquier microcorte en respuestas perdidas y reclamaciones. Configurarlo bien es, en la práctica, tu mejor seguro contra el incidente que aún no ha pasado.
Decisiones sobre el examen en curso
Una vez confirmado el incidente, hay que decidir qué pasa con los alumnos que estaban en mitad de la prueba. Hay tres caminos, y elegir bien depende de dos variables: cuánto duró la interrupción y si afectó a todos por igual o solo a una parte.
| Opción | Cuándo encaja | Riesgo a vigilar |
|---|---|---|
| Ampliar el plazo a todos | Interrupción corta y pareja; el examen sigue siendo válido | Que alguien haya cerrado ya el intento y no aproveche la ampliación |
| Reabrir intento a los afectados | Alumnos concretos perdieron el intento o quedaron fuera | Trato desigual si no documentas por qué a unos sí y a otros no |
| Anular y repetir el examen | Interrupción larga o desigual; los datos del intento no son fiables | Malestar de quien ya lo había terminado bien y tiene que rehacerlo |
En la práctica, ampliar el plazo cubre la mayoría de microcortes: se hace con una excepción de grupo moviendo la fecha de cierre y nadie se entera del susto. Reabrir intento es para los que se quedaron literalmente fuera. Y anular y repetir es el último recurso: solo cuando la interrupción fue tan larga o tan desigual que ningún ajuste de tiempo devuelve la equidad.
Sea cual sea la decisión, la regla no se negocia: el mismo criterio para todos los afectados. Documenta la decisión y su justificación (a qué hora, cuánto se amplió, sobre qué grupo) por si surge una reclamación después. Un correo interno de dos líneas hoy te ahorra una discusión de una semana dentro de un mes.
Verificación técnica antes de reanudar
Antes de anunciar que el problema está resuelto y que los alumnos pueden continuar, confirma explícitamente:
- Que el sitio responde con normalidad desde varias conexiones distintas, no solo la tuya.
- Que la función específica afectada (por ejemplo, el envío de respuestas de cuestionario) funciona correctamente, no solo la carga general de la página.
- Que no hay riesgo inmediato de que el mismo problema se repita en los próximos minutos.
Después del incidente: documentar y prevenir
Una vez resuelto, el trabajo no termina ahí. Documenta:
- Qué ocurrió exactamente y a qué hora.
- Cuánto duró la interrupción y a cuántos alumnos afectó.
- Qué decisión se tomó sobre plazos o repetición de intentos, y por qué.
- La causa raíz del incidente, si se pudo determinar.
- Qué medida concreta se va a aplicar para reducir el riesgo de que se repita.
Este último punto es el que realmente evita que el mismo incidente vuelva a pasar. Un problema de capacidad de servidor durante picos de concurrencia, por ejemplo, apunta a revisar el dimensionamiento (tratado en requisitos de servidor para Moodle) mientras que un fallo relacionado con falta de vigilancia apunta a reforzar la monitorización, cubierta en monitorización de uptime para aulas virtuales.
Cómo reducir la probabilidad de que vuelva a pasar
- No programes todos los exámenes en la misma franja horaria. El error de capacidad más común no es tener un servidor pequeño, sino concentrar cientos de alumnos en el mismo minuto de las 9:00. Escalonar los cuestionarios por franjas o por grupos reparte el pico y a veces resuelve el problema sin tocar el hardware. Cuando el escalonado no basta y el volumen es real, la vía es dimensionar la plataforma para el pico: lo detallamos en cómo escalar Moodle para picos de alumnos.
- Haz una prueba de carga antes de exámenes con mucha concurrencia esperada, simulando el acceso simultáneo real, no un usuario de prueba abriendo la página con calma.
- Ten un protocolo de comunicación ya redactado, no improvisado en el momento, para no perder tiempo decidiendo cómo avisar mientras el problema sigue activo.
- Asigna una persona con autoridad para decidir sobre extensión de plazos o reprogramación durante el incidente, evitando que la decisión se demore por falta de claridad sobre quién puede tomarla.
- Refuerza la monitorización activa específicamente en las ventanas de examen: no basta con una comprobación cada cinco minutos si el examen dura veinte. Una monitorización que te avisa en el primer minuto, tratada en monitorización de uptime para aulas virtuales, es la diferencia entre enterarte tú antes que los alumnos, o al revés.
El protocolo en una tabla
Si tuvieras que pegar algo en la pared junto al ordenador, sería esto:
| Momento | Acción | Objetivo |
|---|---|---|
| Minuto 0-2 | Confirma el alcance desde otra conexión | Saber si es la plataforma, la red del alumno o un pico |
| Minuto 2-3 | Un aviso breve e idéntico a todos los afectados | Cortar la ansiedad y el aluvión de consultas paralelas |
| Minuto 3-10 | Trabaja la causa mientras decides sobre los plazos | No dejar el examen en el aire ni la decisión para el final |
| Al resolver | Verifica el envío de respuestas desde varias conexiones | No reanudar sobre un fallo latente |
| Después | Amplía plazo o reabre por excepciones + documenta | Trato justo y uniforme, con rastro escrito |
Preguntas frecuentes
¿Debo comunicar el problema antes de saber la causa? Sí, un aviso breve confirmando que el problema es conocido y se está trabajando en ello reduce la ansiedad y las consultas simultáneas, aunque todavía no tengas la solución.
¿Debo extender el plazo solo para quien se queja, o para todos? Para todos los participantes afectados por igual, documentando el criterio aplicado, para evitar un trato desigual que pueda generar reclamaciones posteriores.
¿Cómo confirmo que el problema está realmente resuelto antes de reanudar? Verificando la función específica afectada (no solo la carga general del sitio) desde varias conexiones distintas, y confirmando que no hay riesgo inmediato de repetición.
¿Qué debo documentar después del incidente? Qué ocurrió, cuándo, a quién afectó, qué decisión se tomó sobre plazos, la causa raíz si se identificó, y qué medida concreta se aplicará para prevenir que se repita.
¿Cómo puedo anticiparme a este tipo de incidente antes de un examen? Con una prueba de carga que simule la concurrencia real esperada, y reforzando la monitorización y disponibilidad del equipo de reacción durante la ventana del examen.
¿Quién debería tener autoridad para decidir sobre extensión de plazos durante el incidente? Debería estar definido de antemano, no decidirse sobre la marcha, la falta de claridad sobre quién puede tomar esa decisión es, en sí misma, una causa de retraso en la respuesta.
¿El guardado automático de Moodle salva las respuestas si se cae la conexión de un alumno? Sí. Moodle va guardando el intento de forma periódica, así que al volver a entrar el alumno recupera lo que había contestado hasta el último autoguardado. Por eso conviene acortar el periodo de autoguardado antes de un examen crítico: cuanto más corto, menos se pierde en un corte.
¿Cómo amplío el tiempo solo a los alumnos afectados sin tocar el examen del resto? Con las excepciones de usuario o de grupo del propio cuestionario. Ahí puedes cambiar fecha de cierre, tiempo límite e intentos permitidos para personas o grupos concretos, dejando intacta la configuración de quienes ya habían terminado.
¿Qué es el margen de gracia y por qué activarlo antes de un examen grande? Es la opción “Cuando el tiempo expira” del cuestionario que da unos minutos extra solo para enviar (no para seguir respondiendo) cuando se agota el tiempo. Activado de antemano, evita que en el pico de envíos del último minuto se pierdan intentos completos por un segundo de latencia.
Conclusión
Ningún sistema es infalible al 100%, pero la diferencia entre un incidente bien gestionado y uno que erosiona la confianza de tus alumnos está en tener un protocolo claro antes de que ocurra: comunicación inmediata, criterio uniforme sobre plazos, verificación real antes de reanudar, y documentación que alimente la prevención del siguiente incidente.
Si prefieres tener este protocolo ya definido y una monitorización que reduzca la probabilidad de que esto pase, 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
- Monitorización de uptime para aulas virtuales
- Requisitos de servidor para Moodle (CPU, RAM, disco)
- Safe Exam Browser y anti-fraude en exámenes online
¿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.
