Caída de Microsoft 365: por qué “esperar a Microsoft” no funciona

Maurice Manning, Principal Cloud Architect, Wursta. 13 de noviembre de 2026.

Escrito el viernes 13 de noviembre y revisado por última vez a las 09:45 GMT. En ese momento, Microsoft todavía no había dado el incidente por resuelto ni había publicado la causa raíz, así que parte de lo que sigue podría cambiar.

En resumen

El 12 de noviembre, Microsoft 365 se cayó a nivel mundial. Empezó con Exchange Online y se extendió a los calendarios de Teams, SharePoint, Copilot y más. Más de quince horas después, seguía sin solucionarse. Microsoft dice que no fue un ataque, y sus propios servidores reparados volvían a caerse en cuanto recibían tráfico otra vez. Si tu plan de continuidad es esperar a Microsoft, tu tiempo de recuperación será el que Microsoft termine teniendo. Un entorno de respaldo ensayado en una plataforma distinta, como Google Workspace, te da voz en esa decisión. Los agentes y las automatizaciones también tienen que estar en ese plan.

A las 16:17 GMT del jueves, Microsoft abrió el incidente EX1550543: los usuarios en América no podían entrar a sus buzones de Exchange Online. Al caer la tarde, ya había confirmado que el problema “puede afectar la conectividad del servicio de Microsoft 365 para usuarios en cualquier región”. Cuando la mayor parte de Europa empezó su jornada esta mañana, el incidente llevaba más de quince horas, y la actualización de Microsoft de las 07:25 GMT seguía mostrando Exchange Online y el incidente general de Microsoft 365 (MO1550821) como degradados.

Es la segunda gran caída de Microsoft sobre la que escribo en poco más de un año. La vez anterior fue un error de configuración en Azure Front Door que arrastró consigo al servicio de identidad. Esta es diferente en su mecánica e idéntica en su lección.

Outlook acaparó los titulares. Los reportes en Downdetector alcanzaron un pico de casi 140,000 alrededor de las 18:00 GMT, según la BBC, citada por CX Today. Pero la lista de servicios afectados siguió creciendo durante la noche: calendarios y programación de reuniones en Teams, SharePoint Online, Microsoft 365 Copilot, Defender XDR, flujos de Power Platform que dependen de Microsoft Graph y Dynamics 365 Contact Center. El Departamento de Gestión de Emergencias de la Ciudad de Nueva York advirtió sobre retrasos en el correo de las agencias municipales y pidió a los residentes llamar al 311 o al 911 si era necesario (ABC News). En Australia, Service NSW perdió parte de las transacciones de sus centros de servicio y de atención telefónica.

Qué salió mal, hasta ahora

Leer las actualizaciones de Microsoft en orden es revelador (blog en vivo de Tom’s Guide, SecurityWeek, CX Today):

• Primero, “una parte de la infraestructura está experimentando una carga elevada en varias regiones”.
• Luego, una corrección: la carga “no se debe a un aumento del tráfico, sino a que varios servidores no están disponibles de forma inesperada”.
• Después, servidores que no pasaban las comprobaciones automáticas de estado, con un uso elevado de procesador, posiblemente originado en “un componente específico”.
• A las 20:23 GMT: “No hemos identificado ningún cambio reciente que coincida con el inicio del impacto”.
• Durante la noche: un proceso “responsable de establecer conexiones seguras se satura”, y Microsoft empezó a revertir “un cambio reciente en la configuración de red que coincide con el inicio del impacto”.

A las 07:25 GMT, Microsoft dijo que “no tiene conocimiento de ninguna actividad maliciosa que esté causando este incidente”. Así que no fue un ataque.

No estoy criticando a los ingenieros. Cualquiera que haya gestionado un incidente grave sabe que la primera hipótesis suele ser equivocada y que la historia cambia a medida que llegan los datos. Mi punto es otro. Durante más de quince horas, toda organización cuyo plan de continuidad era “esperar a Microsoft” tuvo su tiempo de recuperación definido por el diagnóstico de Microsoft. Su RTO fue el que terminó teniendo Microsoft.

La solución que seguía fallando

La frase que más se me quedó grabada fue esta: los servidores restaurados “pueden dejar de responder otra vez en cuanto reciben tráfico”. Microsoft pausó los despliegues, desvió el tráfico de la infraestructura afectada y reinició servidores, y luego dijo que esas medidas no habían dado “el alivio esperado”. Aplicar parches y reiniciar solo había tenido un “éxito marginal” a las 06:56 GMT (CX Today).

Así suelen comportarse las caídas grandes. La recuperación no es un interruptor que vuelve a su posición. Si tu planificación asume un par de horas de interrupción seguidas de una restauración limpia, lo de anoche es el contraejemplo. Un objetivo de tiempo de recuperación sobre el que no tienes ninguna influencia no es un objetivo. Es una esperanza.

Tres cosas que nos enseña esta caída

Las fallas parciales son más difíciles de gestionar que las totales. Microsoft dijo que las llamadas, los chats y las reuniones de Teams siguieron funcionando en su mayoría, mientras que el calendario y la programación no. La gente podía unirse a una reunión que no podía encontrar. Los usuarios no saben en qué herramientas confiar, y la mesa de ayuda se llena de “¿solo me pasa a mí?”. La decisión más importante es justo la que la mayoría de los planes deja en el aire: ¿en qué momento dejamos de esperar y cambiamos de plataforma, y quién toma esa decisión?

Tu respaldo no puede compartir la falla. SecurityWeek reportó que algunos usuarios de Google Workspace tuvieron problemas para acceder a su correo desde los clientes de Outlook para escritorio y móvil durante el incidente. Me gustaría saber por qué antes de sacar conclusiones firmes, pero el principio se mantiene de cualquier forma. Si a tu entorno de respaldo se accede con el mismo cliente, el mismo proveedor de identidad o la misma ruta de red que al principal, no es independiente. Es una segunda puerta al mismo cuarto.

Los agentes fallan junto con la plataforma de la que leen. Copilot no podía cargar el correo, el calendario ni los archivos. Los flujos de Power Platform fallaron porque Microsoft Graph, del que dependen, estaba fallando. OpenAI y Anthropic reportaron problemas con sus conectores de Microsoft 365; Anthropic lo atribuyó a “un incidente del servicio de Microsoft 365” (CX Today). A medida que más trabajo pasa por agentes y automatizaciones, estos heredan todas las dependencias de los sistemas que tocan. Si un agente redacta respuestas a clientes desde un buzón compartido, se detiene cuando se detiene el buzón. Los planes de continuidad ahora tienen que cubrir tanto a las automatizaciones como a las personas.

Cómo se ve estar “listo”

Para que quede claro: Microsoft 365 es una buena plataforma, y la mayoría de las organizaciones la mantendrá como su plataforma principal, y está bien que así sea. La pregunta no es si dejarla. Es qué haces en la tercera hora de una caída.

En Wursta respondemos a esa pregunta con un entorno de respaldo en Google Workspace que funciona en paralelo a Microsoft 365, al que llamamos Always-Ready Resilience. Google convirtió esto en un producto con licencia en octubre de 2025 con dos ediciones de Business Continuity: un respaldo en frío con sincronización de directorio, utilizable hasta 21 días al año, y Business Continuity Plus, un respaldo en caliente que sincroniza correo, calendario, Drive, chat y más, utilizable hasta 60 días al año. El respaldo en frío sirve cuando “la gente necesita enviar correos y reunirse”. El respaldo en caliente sirve cuando “necesitan el correo de ayer y la agenda de hoy”.

Las licencias son la parte fácil. Lo que hace que un respaldo sea utilizable a las cinco de la tarde de un jueves es todo lo que las rodea:

• Un proceso de declaración acordado: quién puede declarar un desastre, con qué detonante y qué tan rápido responde el soporte una vez que se declara.
• Decisiones sobre el flujo de correo y el DNS tomadas con anticipación, no improvisadas durante el incidente.
• Usuarios que ya iniciaron sesión, configuraron MFA y saben a dónde ir.
• Un cambio de plataforma que ya se ensayó y que se vuelve a probar al menos una vez al año.

Un plan de continuidad sin ensayar es una suposición. Nuestro enfoque empieza con una breve etapa de descubrimiento para fijar por escrito los objetivos de RTO y RPO, sigue con una implementación de cuatro a seis semanas y continúa con pruebas y mantenimiento gestionados.

Antes de que llegue la revisión posterior al incidente

Cuando Microsoft publique su revisión, léela. Pero no la esperes para actuar. Estas son las preguntas que le haría hoy a mi propio equipo:

1. ¿Cuánto tiempo estuvimos realmente sin servicio, servicio por servicio, y cuánto nos costó?
2. ¿Quién decidió qué, y cuándo? ¿Hubo un momento en que alguien pudo haber dicho “cambiemos”?
3. ¿Qué hizo la gente en su lugar? Lo que sea que hayan usado es tu plan de continuidad actual, lo hayas aprobado o no.
4. ¿Qué automatizaciones y agentes se detuvieron, y alguien se dio cuenta?
5. Si esto hubiera durado tres días en lugar de uno, ¿qué se habría roto primero?

Si la respuesta honesta a la segunda pregunta es “esperamos a Microsoft”, esa es la brecha que vale la pena cerrar antes de la próxima.

Fuentes:

• ABC News: Microsoft Outlook outage stretches on for hours
• SecurityWeek: Microsoft 365 outage disrupts Outlook, Exchange Online and Teams
• Tom’s Guide: live updates on the Microsoft 365 outage
• CX Today: Microsoft outage cut agents off from the contact center
• Cyber Security News: fixes fail as restored servers keep going unresponsive
• Google Workspace Updates: Introducing Business Continuity editions
• Wursta: Always-Ready Resilience