La caída de Microsoft 365 se alarga más de 16 horas con Exchange Online aún en recuperación

La actualización de las 11:04 UTC del viernes 13 dejó claro que la crisis no había terminado. Microsoft había completado acciones de recuperación en parte de la infraestructura de Asia-Pacífico, el tráfico volvía a fluir de forma gradual y mejoraban el acceso a los buzones y el procesamiento del correo retrasado, pero algunos usuarios seguirían viendo fallos intermitentes y el trabajo continuaba en otras regiones. La interrupción había comenzado el jueves 12 a las 13:26 ET (18:26 UTC), según el aviso MO1550821 del centro de administración, y ya superaba las 16 horas.

El alcance es amplio porque Exchange Online es la pieza de la que dependen muchos otros servicios. Microsoft sostiene que las funciones que no interactúan con Exchange siguen operativas, pero la lista de afectados incluye Outlook, Teams, Copilot, SharePoint, Defender, Intune, Purview, Microsoft Graph, Planner, Power BI, To Do, Universal Print, Windows 365 y el propio centro de administración. No es la caída de una sola aplicación: es un problema de infraestructura compartida que se propaga por la cadena.

De una carga elevada a servidores que desaparecen

La primera explicación de Microsoft fue una carga elevada de infraestructura en varias regiones. Horas después, la compañía corrigió el diagnóstico: el aumento no venía de un pico de tráfico, sino de un número de servidores que se habían vuelto inesperadamente no disponibles y estaban sobrecargando al resto. Para reducir la presión, Microsoft pausó los despliegues, redistribuyó las conexiones entre su infraestructura mundial y empezó a reiniciar los equipos afectados.

Ese plan tampoco dio el resultado esperado. En una actualización posterior, la empresa explicó que un proceso central de los servidores afectados se estaba saturando y provocando una pérdida de capacidad. Mientras continuaba las labores de recuperación, estudiaba si revertir un pequeño número de cambios de configuración recientes podía acelerar la vuelta al servicio.

No era el único problema de la jornada. Microsoft había resuelto por la mañana una incidencia separada de Teams, registrada como TM1550488, que afectó a usuarios de América del Norte y del Sur entre las 9:45 y las 10:53 ET y provocó retrasos al enviar mensajes y errores al crear conversaciones. La compañía atribuyó aquel episodio a una contención de recursos y no ha confirmado si ambos incidentes están relacionados.

La secuencia recuerda que una caída de este tipo no siempre se arregla reiniciando. Si el problema está en un proceso que coordina el arranque, la autenticación o el enrutamiento del correo, devolver máquinas al servicio sin control puede volver a saturar el sistema. Microsoft describió precisamente un enfoque medido: reparar, comprobar que el cambio se aplicó y verificar que el servidor responde antes de sumarlo al tráfico.

Qué servicios están afectados

El aviso oficial agrupa el impacto por dependencias. Exchange Online es el núcleo: los usuarios pueden no acceder al buzón desde Outlook en la web, Outlook de escritorio mediante MAPI, Exchange ActiveSync o conexiones REST, y el correo puede llegar con retraso. A partir de ahí, la lista se extiende:

• Microsoft 365 Copilot no carga el chat o no recibe respuestas, y sus experiencias no pueden leer correo, calendario ni archivos de trabajo.
• Teams mantiene las llamadas, las reuniones y los chats de grupo, pero fallan el calendario, las invitaciones, la creación de eventos en directo y los canales privados o compartidos.
• SharePoint conserva el acceso a los archivos, aunque puede fallar el uso compartido externo y todo lo que depende de Exchange.
• Microsoft Graph puede agotar el tiempo de espera en peticiones de correo, calendario y contactos, lo que afecta a aplicaciones y automatizaciones propias.
• Intune puede fallar en el alta de dispositivos, el registro periódico y las políticas de cumplimiento.
• Purview, Defender for Office 365 y Defender XDR pueden retrasar la evaluación de políticas, las etiquetas de sensibilidad y el acceso a sus portales.
• Planner, Power BI, Power Apps, To Do, Universal Print, Windows 365 y Microsoft Fabric presentan fallos parciales en funciones concretas.
• El centro de administración de Microsoft 365 y el de aplicaciones también pueden no cargar algunas páginas.

La distinción entre «servicio caído» y «función degradada» importa. Un equipo puede seguir leyendo archivos de SharePoint y, al mismo tiempo, no poder enviar una invitación de calendario. Para una empresa, eso significa que la evaluación de daños no puede limitarse a preguntar si Outlook abre: hay que revisar los flujos que cruzan servicios.

La recuperación avanza por regiones

En la actualización de las 11:04 UTC del 13 de noviembre, Microsoft informó de que había completado acciones de recuperación en parte de la infraestructura de Asia-Pacífico. El tráfico se estaba restaurando de forma gradual y la compañía observaba mejoras en el acceso a los buzones y en el procesamiento del correo retrasado. El siguiente paso era extender esas acciones a otras regiones y añadir capacidad para estabilizar el servicio.

El correo acumulado sigue siendo un problema aparte. Microsoft mantiene una ventana de 48 horas para los mensajes retrasados, una medida que evita que los envíos caduquen mientras se vacían las colas. La compañía también avisó de que la recuperación sería gradual a medida que las aplicaciones vuelvan a conectarse: no es lo mismo restablecer el servicio que recuperar de golpe miles de clientes, sesiones y flujos de trabajo.

¿Fue un ciberataque?

Microsoft no ha presentado el incidente como un ataque. En su última actualización afirma que no tiene pruebas de actividad maliciosa asociada y que seguirá tratando el problema con urgencia hasta la mitigación completa. La formulación es deliberadamente prudente: «no hay indicios» no es lo mismo que «está descartado», y la compañía ha prometido un informe post-incidente con la causa raíz y las medidas de defensa en profundidad cuando termine la recuperación.

Ese informe será la pieza que permita distinguir entre un fallo de capacidad, un error de configuración y un incidente de seguridad. Hasta entonces, cualquier atribución es una hipótesis. La ausencia de pruebas públicas de un ataque no impide que las empresas revisen sus propios registros, sobre todo si notaron accesos anómalos durante la ventana de mayor desorden.

Qué pueden hacer los administradores

La primera recomendación es no improvisar reinicios masivos ni recrear perfiles de Outlook. Si el problema está en la infraestructura de Microsoft, esas acciones no arreglan nada y pueden añadir trabajo cuando el servicio vuelva. Conviene seguir el estado oficial, suscribirse al feed de actualizaciones y comprobar si el incidente afecta a la región y al plan contratados.

Durante la interrupción, Outlook en la web puede ser una alternativa si el cliente de escritorio no conecta, aunque también depende de Exchange Online. Para el correo crítico, algunas organizaciones pueden usar un dominio o un proveedor secundario, pero esa decisión debe estar prevista antes del incidente: montarla en caliente rara vez sale bien.

También merece la pena revisar los flujos que no son correo. Una política de Intune que no se aplica, una tarea de Purview que no evalúa etiquetas o una aplicación que consulta Graph pueden estar fallando sin que nadie lo relacione con la caída. Los equipos de soporte deberían registrar qué funciones siguen degradadas y evitar cerrar incidencias por «servicio restaurado» antes de probar los casos de uso reales.

Cuando el servicio vuelva, hay que vigilar las colas de correo, los reintentos de aplicaciones y los procesos que se quedaron a medias. No conviene borrar mensajes en cola ni purgar buzones para «limpiar»: la ventana de 48 horas existe precisamente para dar margen. Si la organización tuvo que activar un plan de continuidad, conviene documentar qué se desvió, qué se perdió y cuánto tardó la vuelta a la normalidad.

Lo que todavía no se sabe

Falta la causa raíz, la duración total y el detalle de las acciones que funcionaron. Microsoft no ha publicado el informe post-incidente y tampoco ha confirmado si el problema quedó limitado a determinadas regiones o si afectó de forma distinta a los planes empresariales. Tampoco hay una cifra oficial de usuarios o organizaciones afectadas: los datos de terceros miden reportes, no clientes.

La lección provisional es la de siempre en los servicios en la nube: la disponibilidad del proveedor no sustituye un plan propio. Tener identificados los procesos críticos, una vía de comunicación alternativa y una idea de qué hacer cuando Exchange no responde sigue siendo más útil que confiar en que la nube no falla. Esta vez falló durante más de 16 horas; la próxima puede ser más corta, pero la preparación se decide antes.