Una incidencia en la infraestructura de Microsoft dejó sin servicio a Exchange Online y afectó a Outlook, Teams y otros productos de Microsoft 365. También quedaron inaccesibles herramientas que los administradores utilizan para gestionar los servicios, entre ellas Intune y el Centro de administración de aplicaciones de Microsoft 365. La interrupción comenzó el 12 de noviembre y, durante los primeros intentos de recuperación, algunos servidores volvieron a fallar al recibir tráfico.
La incidencia afectó al correo y a las herramientas de administración
El problema comenzó en torno a las 18:00 UTC del 12 de noviembre. Según la información publicada por The Register sobre la caída de Microsoft, entre los servicios afectados estaban Exchange Online, Teams, Copilot para Microsoft 365 y Defender para Office 365. La interrupción también alcanzó a Intune y al Centro de administración de aplicaciones, lo que dificultó a los equipos técnicos consultar y gestionar esos servicios mientras duraba el incidente.
El impacto del fallo no se limitó, por tanto, a abrir Outlook o enviar un mensaje. Cuando el correo corporativo depende de Exchange Online, los problemas de disponibilidad pueden interrumpir tanto la comunicación como los procesos de trabajo que utilizan el correo. A la vez, que fallen herramientas de administración complica el diagnóstico desde las propias consolas de Microsoft. La información disponible no detalla qué operaciones concretas pudieron realizar o no los usuarios en cada servicio.
Servidores que fallaban las comprobaciones de salud
Microsoft atribuyó el incidente a un problema que hacía que determinados servidores fallasen las comprobaciones automáticas de salud y quedasen fuera de servicio. Estas comprobaciones permiten a una plataforma detectar si un componente responde correctamente y decidir si debe seguir atendiendo solicitudes. En un servicio distribuido, retirar un servidor que no supera esos controles ayuda a evitar que siga recibiendo tráfico cuando no está en condiciones de procesarlo.
En este caso, según la investigación inicial comunicada por Microsoft, los fallos podían proceder de un componente específico encargado de procesar el estado de salud de los servidores. La compañía indicó que no había identificado cambios en sus sistemas que explicasen el inicio del problema. También evaluaba si revertir algunas actualizaciones recientes de configuración podía acelerar la recuperación; esa posibilidad no se presentó como una causa confirmada.
Microsoft comunicó además que un proceso central de los servidores afectados estaba quedándose sin capacidad de respuesta. Ese comportamiento contribuía a la pérdida de capacidad del servicio. La explicación ayuda a entender por qué recuperar servidores no era simplemente volver a encenderlos: había que comprobar que respondían de forma estable y que podían reincorporarse al servicio sin reproducir el fallo.
La recuperación requería validar los servidores con tráfico
En una actualización publicada alrededor de las 22:00 UTC, Microsoft dijo que había encontrado y validado un método alternativo para comprobar la salud del servicio. Con él, un subconjunto de servidores afectados pudo volver a estar disponible. La compañía continuó con el reinicio y la validación del resto de componentes, además de estudiar cómo acelerar el proceso sin comprometer la estabilidad.
La validación resultó especialmente relevante porque algunos servidores que parecían recuperados dejaban de responder cuando empezaban a recibir tráfico. En una actualización posterior, difundida a las 00:35 UTC del 13 de noviembre, Microsoft indicó que ciertos servidores habían vuelto a estar en línea y se mantenían inicialmente en buen estado, pero podían quedar otra vez sin respuesta al recibir solicitudes.
Ese comportamiento muestra una diferencia importante entre arrancar un servidor y comprobar que puede atender carga real. Una comprobación aislada puede confirmar que un proceso responde en un momento concreto; la reincorporación gradual permite observar qué ocurre cuando vuelven las solicitudes. En este incidente, Microsoft explicó que estaba aislando parte de la infraestructura, reiniciando componentes afectados y reintroduciendo tráfico para comprobar que los servicios se mantenían estables antes de extender el cambio.
Sin un plazo confirmado para la restauración completa
La recuperación fue progresiva y las medidas aplicadas hasta entonces no habían ofrecido el alivio esperado, según las actualizaciones recogidas por The Register. Microsoft señaló que analizaba datos de diagnóstico para determinar qué desencadenaba el comportamiento de los servidores. En la información publicada no figuraba un plazo para restaurar por completo todos los servicios.
Para las organizaciones afectadas, la caída puso en evidencia la dependencia entre aplicaciones de usuario y sistemas de administración: una misma incidencia puede dificultar tanto el trabajo diario como la capacidad del equipo de tecnologías de la información para investigar el problema desde las herramientas habituales. La noticia no identifica una causa raíz definitiva ni permite establecer cuánto duró la afectación para cada cliente; sí describe una recuperación condicionada por la dificultad de mantener estables los servidores al devolverles tráfico.
