Microsoft 365: apagón global por fallo interno, no ataque

Microsoft 365 supera los 450 millones de suscripciones comerciales pagas, según la estimación que la propia compañía hizo en enero. Este jueves al mediodía, buena parte de ellas dejó de funcionar: un apagón global que seguía activo el viernes por la mañana y que Microsoft atribuye a fallos en los chequeos automáticos de salud de sus servidores, no a un ataque informático.

Qué pasó con el apagón global de Microsoft 365

La interrupción arrancó el jueves al mediodía y afectó correo, servicios cloud y herramientas de IA. Microsoft documentó la lista completa de servicios impactados y, en la madrugada del viernes, extendió el tiempo de espera del correo a 48 horas para preservar los mensajes demorados. «Las acciones de recuperación están en curso», publicó la cuenta Microsoft 365 Status en X.

En su página de estado, la empresa fue explícita: «no tenemos evidencia de actividad maliciosa asociada a este incidente», y prometió publicar un informe completo post-incidente con la causa raíz y las acciones de defensa en profundidad. También dijo que estaba «persiguiendo agresivamente todas las vías para reducir el impacto».

¿Y esto cómo se aplica en tu negocio?

Dueños de negocio de Latinoamérica y España usan un agente de IA para ganar más y recuperar su tiempo. El Kit «tu mano derecha con IA» te muestra cómo en un video de 11 minutos, con una ficha para armar el tuyo. CAR está cerrada por ahora; al anotarte, te avisamos cuando abra.

👥 Quiero el Kit →

SecurityWeek documentó el detalle técnico: un número elevado de servidores dejó de responder a los chequeos automáticos de salud, lo que concentró la carga sobre los que seguían operativos. Microsoft probó un workaround que evita el componente encargado de procesar esos chequeos y detectó uso elevado de procesador en los servidores afectados. Además, comenzó a revertir un cambio de configuración de red que coincidió con el inicio de la interrupción. Los incidentes quedaron registrados como EX1550543 (Exchange Online) y MO1550821 (Microsoft 365).

Vale una aclaración para no mezclar causas: la caída llegó dos días después de las actualizaciones de Patch Tuesday de noviembre, que corrigieron 1.094 vulnerabilidades, incluida CVE-2026-124194, una falla de suplantación en Outlook que Microsoft dice que los atacantes ya explotaron. Los avisos de servicio de la compañía no vincularon esa vulnerabilidad con la caída de Exchange Online.

Por qué un chequeo de salud fallido puede tumbar servicios globales

El mecanismo es más incómodo de lo que parece. En una nube a gran escala, miles de servidores se reparten el tráfico y un sistema automático verifica cada pocos segundos si cada uno responde. Si no responde, se lo saca de la rotación. El problema aparece cuando ese chequeo falla en masa: los servidores que quedan deben absorber el tráfico de los caídos, se saturan y también dejan de responder. Es un círculo vicioso que se propaga servicio por servicio.

Microsoft lo describió así: el proceso que establece conexiones seguras dentro de los servidores afectados se sobrecargó, y eso hizo que dejaran de atender pedidos. Lo más difícil fue que reiniciar no alcanzaba. Servidores que volvían a estar sanos dejaban de responder otra vez apenas empezaban a recibir tráfico real. Por eso la recuperación no fue un interruptor, sino una secuencia de restricciones de tráfico, reversión de configuración y reconstrucción de servidores con la configuración anterior.

Bancos, hospitales y tribunales: el costo real del apagón

El alcance fue inusualmente amplio. En Japón afectó infraestructura de TI del gobierno, según el vicejefe de gabinete Masanao Ozaki. NBC News documentó que «pocos organismos públicos quedaron a salvo»: en algunos casos los médicos no pudieron enviar a sus pacientes avisos «importantes» sobre cambios de medicación o seguimiento. El sector financiero también sufrió, con personas bloqueadas para hacer transferencias bancarias porque no podían recibir los códigos de verificación. La Corte Suprema de Filipinas vio frenado su trabajo legal, y una oficina del sheriff en Colorado reportó dificultades para que la gente pagara la fianza y lograra la liberación inmediata de detenidos.

Ciaran Martin, exdirector del Centro Nacional de Ciberseguridad del Reino Unido, dijo a NBC News que se trata de «uno de los mayores apagones de todos los tiempos» y sugirió que podría ser incluso «peor» que los de AWS y CrowdStrike.

2026: el año en que falla la automatización, no el hardware

No es un episodio aislado. En enero de 2026, Microsoft 365 ya había sufrido un apagón de más de nueve horas que tumbó Outlook, Exchange Online, SharePoint, OneDrive y Teams. La compañía lo atribuyó a una carga elevada por capacidad reducida durante tareas de mantenimiento, según CRN. Downdetector registró entonces 12.380 reportes por Outlook y 15.745 por la suite de Microsoft 365.

El 23 de julio de 2026, otro incidente dejó cinco horas sin servicio a Teams, SharePoint, OneDrive y Copilot Chat: un bug en el sistema automatizado que traduce pedidos de mantenimiento en instrucciones eliminó rutas IP de más dispositivos de los previstos y aisló un datacenter de Azure en West US, según el informe preliminar que recogió TechTimes. Ese mismo medio reportó que Microsoft 365 entregó solo 99,526% de uptime en el primer trimestre de 2026, la cifra trimestral más baja desde que hay registros, y que al menos 19 servicios SaaS de terceros que corren sobre Azure se vieron arrastrados por la caída.

El patrón se repite: no falla el hardware, falla la capa de automatización que debería protegerlo. Y contra la intuición, los datos de Uptime Institute que cita CRN muestran que los apagones son cada vez menos frecuentes: el 53% de los operadores de datacenters reportó uno en los últimos tres años, contra el 60% de 2022, el 69% de 2021 y el 78% de 2020.

¿Qué significa esto para tu startup?

Si tu operación vive dentro de Microsoft 365 —correo, calendario, archivos, reuniones— este apagón es una prueba de estrés gratuita. Tres cosas concretas para hacer esta semana:

Define canales fuera de banda. Antes del próximo apagón, ten un canal alternativo que no dependa del proveedor caído: un grupo de mensajería, una línea telefónica, SMS o un correo en otro dominio. Microsoft mismo recomendó revisar los planes de continuidad y recuperación durante el incidente de julio, y las organizaciones que tenían canales de respaldo documentados sufrieron menos, según TechTimes.
Mapea tus dependencias en cadena. El SLA del 99,9% de los servicios core de Microsoft 365 promete disponibilidad, no protección de datos, y el crédito por incumplimiento equivale al 25% de la cuota mensual, según TechTimes: una fracción del costo real de una caída larga. Peor aún, tus herramientas de terceros —automatizaciones, conectores, seguridad— tienen sus propias cadenas de dependencia y sus propios tiempos de recuperación que ningún SLA cubre.
Diseña para fallar por región, no para cambiar de proveedor. La recomendación de Microsoft es desplegar en múltiples regiones para que un evento en una sola no te deje sin servicio. Y la analista de Gartner Lydia Leong advirtió que perseguir resiliencia multicloud «puede costar más de lo que ahorra», porque agrega complejidad técnica sin eliminar el riesgo sistémico. Para la mayoría de las startups, la respuesta no es migrar: es arquitectura y plan de contingencia.

Conclusión

Un apagón de esta escala no se previene desde el lado del cliente. Lo que sí se controla es la respuesta: saber qué se cae, en qué orden, quién avisa a los clientes y cómo se sigue operando cuando el correo no llega. Microsoft prometió un informe post-incidente completo con la causa raíz; hasta que llegue, la lección práctica ya está clara: la disponibilidad de tu stack es probabilística, no garantizada, y conviene tratarla así.