# Un fallo hace caer a todo Microsoft 365 y arrastra su página de estado > Outlook y Microsoft 365 sufren una degradación con la página de estado también caída. No hay causa publicada y el Patch Tuesday no tiene relación. > Por José Maldonado · Tecnología · 2026-11-13 Outlook dejó de entregar correo el 12 de noviembre de 2026 hacia las 18:20 UTC y, con él, se cayó también la página que debía explicar qué estaba pasando. El [panel de estado de Microsoft Cloud](https://status.cloud.microsoft/) es la referencia oficial para saber qué servicio está roto y desde cuándo, y durante las primeras horas no sirvió para eso: varios administradores comprobaron que la web no cargaba el detalle y se apoyaron en el canal RSS para seguir las actualizaciones de la compañía. Ocho horas después del primer aviso, el equipo seguía reiniciando máquinas sin haber publicado una causa raíz. Lo que sí circuló fue el relato de quien estaba delante de la pantalla. El [hilo abierto en Hacker News](https://news.ycombinator.com/item?id=50471731) acumulaba 548 puntos y 501 comentarios en la madrugada del 13 de noviembre, con administradores de sistemas de Europa, Australia, Japón y Brasil describiendo el mismo síntoma: buzones inaccesibles en Outlook web y de escritorio, y empresas con miles de empleados sin correo entrante desde hacía más de cinco horas. Nadie discutía la magnitud del fallo, se discutía qué hacer mientras el proveedor no decía nada. Un correo corporativo caído se mide por lo que no se puede hacer durante dos horas, no por la disponibilidad de un trimestre. Aquí el instrumento que convierte la caída en información falló junto al servicio. ## Un chequeo de salud que se lleva por delante los servidores La secuencia que la compañía publicó en su canal de incidencias describe un fallo en cascada con un culpable terrenal. Los servidores afectados empezaron a fallar los chequeos automáticos de salud, el sistema los retiró de rotación y la carga que atendían se desplazó al resto de la infraestructura, que se saturó. Es el patrón de la estampida: un chequeo agresivo saca de servicio una máquina sana y los reintentos de los clientes amplifican el problema. A las 19:30 UTC, Microsoft confirmó en un aviso que la carga elevada no venía de un aumento real de tráfico, sino de una cantidad grande de máquinas que se habían vuelto indisponibles sin avisar. A las 20:52 reconoció que muchas de ellas se habían quedado sin responder, lo que impedía verificar si el cambio que probaban servía de algo. Veinte minutos antes había identificado que los chequeos fallidos podían originarse en un componente concreto y aplicaba una configuración alternativa en un subconjunto. La investigación se movió por prueba y error durante horas, y los propios avisos lo dejan ver. Primero aislaron servidores, después los reiniciaron, luego probaron un método de chequeo distinto que recuperó parte de la capacidad, y a la 01:06 UTC del 13 de noviembre situaron el origen en un proceso que gestiona conexiones seguras y anunciaron que revertían un cambio de configuración de red coincidente con el inicio del impacto. Ninguna de esas notas afirma haber encontrado la causa raíz. La diferencia entre una avería y una avería bien contada está en los tiempos. Sin ese canal RSS, la cronología se habría perdido y el incidente se juzgaría solo por sus ocho horas de correo caído. ## El panel de estado se cae con el servicio que vigila La página de estado de Microsoft Cloud es una aplicación que se dibuja en el navegador y consulta datos por su cuenta, igual que el resto de la suite. Cuando la infraestructura que la alimenta se degrada, la página no muestra una señal de avería: se queda en blanco, tarda o enseña datos viejos. En este incidente pasó lo segundo, y el hueco lo llenó el canal RSS, que siguió publicando avisos con marca de tiempo mientras la web no respondía. Un administrador los recopiló y los compartió en el hilo público, y esa recopilación es hoy la mejor cronología disponible. Los hitos que la compañía llegó a publicar, con su hora UTC y lo que implicaban para quien intentaba trabajar, caben en seis filas que van del primer diagnóstico a la reversión del cambio de red. Hora (UTC) Mensaje del panel Lectura 19:30 Carga elevada por servidores que dejan de responder No es un pico de tráfico 19:52 Fallo en el componente que procesa los chequeos Primer sospechoso técnico 20:52 Máquinas que no responden y no permiten validar El cambio no se puede medir 21:02 Chequeo alternativo válido en un subconjunto Recuperación parcial 22:11 Un proceso central se satura y tumba el servidor El diagnóstico se estrecha 01:06 Reversión de un cambio de red previo Sin causa raíz confirmada Una página de estado alojada en la misma infraestructura que vigila es un patrón viejo y mal resuelto. La información sobre la caída viaja por el mismo camino que la caída, así que el cliente pierde las dos cosas a la vez y se queda sin saber si el problema es suyo, del proveedor o de su conexión. Para un departamento de sistemas, esa media hora de duda cuesta más que la caída misma, porque multiplica las llamadas internas y las pruebas a ciegas contra servicios que ya estaban sanos. ## Correo, centro de administración y Copilot en la misma lista La lista de servicios afectados creció con las horas y terminó siendo un mapa de las dependencias internas de la suite. Exchange Online fue el epicentro, y con él cayeron las funciones de Outlook web, escritorio, Exchange ActiveSync y las conexiones REST, además del envío de correo con retraso. El centro de administración dejó de cargar páginas y los usuarios de Microsoft 365 Apps no podían ver sus archivos recientes. El resto de la lista muestra hasta qué punto la suite comparte cimientos. Copilot Chat se quedó sin respuestas y Microsoft Graph devolvía tiempos de espera en las peticiones de correo. Purview perdió etiquetas y prevención de pérdida de datos, mientras Defender for Office 365 no podía verificar enlaces. La misma ola alcanzó a Intune, Planner, To Do y Power BI con fallos parciales, y Teams mantuvo la mensajería y las reuniones, pero perdió el calendario cuando este dependía de Exchange. Ese reparto tiene una consecuencia práctica para quien haya centralizado su correo en la nube. El [repaso de qué montar en un servidor propio](https://observatorioblockchain.com/tecnologia/autohospedaje-2026-que-montar/) recuerda que el autohospedaje cubre correo, calendario y archivos a cambio de mantenimiento y guardias. ## El boletín de 1.094 fallos que llegó el mismo día Doce horas antes de la caída, este sitio publicó el resumen del Patch Tuesday de noviembre de 2026, con 1.094 vulnerabilidades corregidas por Microsoft y un cero día en Outlook que filtra el hash NTLMv2 de la víctima con solo abrir un archivo de mensaje manipulado. El [desglose de los 1.094 parches](https://observatorioblockchain.com/ciberseguridad/patch-tuesday-noviembre-2026-outlook-cero-dia/) reparte 726 fallos en Windows y 174 en Office, y señala el CVE-2026-124194 como el único explotado de forma activa. Conviene separar los dos episodios con precisión, porque la coincidencia invita a mezclarlos. Las actualizaciones se publicaron el 10 de noviembre, el boletín apareció el 12 a las 08:00 y la degradación empezó diez horas después. Ninguna nota oficial vincula el incidente con las actualizaciones, y la investigación descrita apunta a chequeos de salud, saturación de procesos y un cambio de configuración de red, no a un parche defectuoso. La compañía tiene precedentes de corregir a toda prisa cuando un parche rompe algo, y en octubre recurrió a una actualización fuera de banda para arreglar un fallo de Brotli en .NET, como detalla la [corrección urgente de .NET](https://observatorioblockchain.com/ciberseguridad/dotnet-parche-fuera-de-banda-brotli/). Si el origen hubiera sido una actualización, el calendario lo habría dejado por escrito. No es el caso: el [blog de Microsoft 365](https://www.microsoft.com/en-us/microsoft-365/blog/) seguía sin ninguna entrada sobre el incidente en la mañana del 13 de noviembre, y su última nota publicada era del 5 de noviembre. La coincidencia de fechas es eso, una coincidencia, y quien la use para explicar la caída necesitará algo más que un calendario. ## Lo que dos horas de correo caído enseñan sobre la confianza La lección operativa es aburrida y por eso se repite cada año. El correo corporativo se ha convertido en la capa donde se apoyan la identidad, la gestión de dispositivos y los permisos, así que su caída arrastra mucho más que la bandeja de entrada, y un proveedor que no puede contar lo que pasa en su propia web deja a sus clientes sin el dato mínimo para decidir si activan el plan de contingencia. Queda una pregunta que Microsoft no ha respondido y que un informe posterior debería cerrar: por qué el sistema de chequeos retiró de servicio máquinas que estaban sanas, y qué cambió en la configuración de red para que un proceso de conexiones seguras se saturase con carga normal. Sin esa respuesta, la próxima caída tendrá la misma forma y el mismo silencio en la página que debería explicarla.