El miércoles 23, a las 16:44 hora peninsular, Microsoft 365 empezó a fallar: Teams sin cargar chats, SharePoint devolviendo errores, OneDrive a ratos, y el centro de administración — el sitio donde irías a mirar qué pasa — cargando a trompicones. La causa, según Microsoft: un cambio de configuración de red suyo. Si en tu empresa no se notó, no fue mérito de tu arquitectura: el impacto se concentró en rutas de red de Norteamérica, y esta vez la geografía jugó a tu favor. Por eso este post no va de Microsoft. Va de una pregunta que casi nadie tiene respondida: ¿qué hace tu empresa las horas en que la oficina entera vive en la nube de otro, y la nube de otro no está?
Qué pasó, con datos
Microsoft lo registró como el incidente MO1437424 (con un incidente hermano en Azure, ZJV6-SGG). Empezó a las 14:44 UTC y afectó, en distinto grado, a Teams, SharePoint Online, OneDrive, Power Automate, Copilot, Loop, Purview, Power BI y el propio centro de administración de Microsoft 365. En Downdetector los reportes pasaron de una línea base de 29 a más de 2.400 en menos de media hora. La mitigación fue la clásica de esta categoría de incidente: revertir el cambio de red y redirigir tráfico por rutas alternativas. El grueso del impacto duró unas cuatro horas; el cierre formal llegó por la noche.
Léelo otra vez desde el punto de vista de una empresa: durante una tarde laborable, el chat, la telefonía de quien la tiene en Teams, los ficheros, los flujos automatizados y el panel desde el que se administra todo eso fallaban a la vez. No por un ataque, no por un datacenter en llamas: por un cambio de configuración rutinario en casa del proveedor. Es el tercer gran incidente de Microsoft en nueve meses con esa misma forma, y el patrón no es exclusivo suyo.
No es un rayo: es el clima
- →29 de octubre de 2025: un cambio de configuración involuntario en Azure Front Door tumbó durante más de ocho horas servicios de Microsoft 365, el portal de Azure, Xbox y miles de webs de clientes.
- →18 de noviembre de 2025: la caída global de Cloudflare, que dejó media Internet devolviendo errores durante horas.
- →22 de enero de 2026: Exchange Online y Teams estuvieron degradados unas diez horas por un problema de carga durante un mantenimiento. El detalle que más nos gusta contar: un cambio de balanceo aplicado para acelerar la recuperación la alargó, y el incidente no se cerró hasta casi 24 horas después.
- →16 de julio de 2026: la caída de AWS CloudFront, de la que escribimos la semana pasada. Una semana después, le tocaba a Microsoft.
Tres proveedores, cinco incidentes y ni un solo ataque: en todos, el fallo nació en casa del proveedor — un cambio o una operación suya que salió mal. Ni hardware roto, ni hackers, ni rayos. A esta escala, la mayor amenaza para la nube es la mano que la administra — y contra eso no hay parche que tú puedas aplicar ni firewall que puedas comprar. Quien te venda lo contrario, te está vendiendo otra cosa.
De un SaaS no se hace disaster recovery
Cuando se te cae un ERP en tu propia infraestructura, tienes runbook: réplica que promover, backup que restaurar, hipervisor al que entrar. Es el mundo del disaster recovery clásico, y ahí sí hay mucho que diseñar. Cuando se cae Teams, no hay nada de eso: no existe la réplica de Teams que tú puedas arrancar, no hay servidor al que hacer failover, y tu escalado consiste en abrir un ticket que hace cola con los de otros cientos de miles de organizaciones. Todo el DR presupone una cosa: que la infraestructura es tuya, o que al menos puedes levantar otra. En el SaaS no se cumple ninguna de las dos.
¿Y el SLA? La mayoría de servicios de Microsoft 365 tienen un SLA del 99,9% con respaldo económico: si se incumple, puedes reclamar créditos de servicio — un porcentaje de descuento en la factura de ese mes. Es un contrato sobre dinero, no sobre tu continuidad. Nadie te devuelve la tarde de trabajo, los pedidos que no entraron ni las llamadas que no sonaron. El SLA compensa; no continúa.
Esto cambia el papel de tu equipo de IT (o del nuestro, cuando somos nosotros) durante la caída: no está para resolver el incidente, porque no puede. Está para otra cosa: saber qué pasa, contarlo hacia dentro con criterio, sostener lo que sí depende de vosotros y evitar que el nerviosismo genere un segundo incidente, este sí, propio. Esa función no se improvisa a las cinco de la tarde. Se decide antes.
Lo que no haríamos
- ✕Montar una segunda suite "por si acaso". Un Google Workspace de respaldo suena bien en la diapositiva: en la práctica pagas dos licencias, mantienes dos configuraciones de seguridad y duplicas superficie de ataque para que, el día D, nadie recuerde ni la contraseña. Es continuidad de PowerPoint, no de empresa.
- ✕Irse "a otra nube" por reflejo. En nueve meses se han caído Cloudflare, Azure, AWS y Microsoft 365 dos veces. Cambiar de proveedor no elimina la categoría de fallo; solo cambia el logo de la página de estado que refrescas. Lo decimos gestionando tenants de Microsoft 365 a diario, y sin cobrar comisión de nadie: para el puesto de trabajo, M365 sigue dando más de lo que cuesta. El problema no es la elección de proveedor: es no tener plan para sus horas malas.
- ✕Tocar tu configuración en mitad de la caída. Reconfigurar los Outlook de 200 usuarios, cambiar DNS, puentear el proxy "a ver si así". Recuerda enero: fue el propio Microsoft quien alargó su caída con un cambio pensado para acortarla. Si eso le pasa al fabricante en su plataforma, imagina a tu equipo improvisando en la tuya. Durante la caída de un proveedor, la primera regla es no convertir su incidente en el tuyo: todo lo que cambies hoy lo tendrás que deshacer mañana.
El plan que sí funciona cabe en dos páginas
Nada de lo que sigue requiere comprar tecnología. Requiere decidir en frío, escribirlo y ensayarlo una vez. Es la parte de la continuidad de negocio que de verdad se usa:
- 1.Canal B de comunicación. La pregunta trampa: el día que Teams no va, ¿por dónde avisas de que Teams no va? Un grupo de mensajería en los móviles y una lista de teléfonos que viva también fuera de OneDrive. Cuesta cero y es lo primero que falla en casi todas las empresas.
- 2.Quién mira y quién cuenta. Una persona sigue el estado (la página de estado de Microsoft, el centro de administración si responde — el miércoles también iba a trompicones, tenlo en cuenta — y la cuenta de estado de Microsoft en X) y otra comunica hacia dentro a intervalos fijos. El resto trabaja con lo que haya. Sin dueño, la "gestión del incidente" son cuarenta personas refrescando Downdetector.
- 3.Trabajo local por diseño. Apps de escritorio instaladas y no solo el navegador, Outlook en modo caché, y los ficheros críticos marcados para conservarse siempre en el dispositivo. Una organización que trabaja solo en web se detiene entera; una con clientes de escritorio y sincronización cojea, que es infinitamente mejor. Esto se configura un martes cualquiera, no durante la caída.
- 4.Mapa de dependencias no evidentes. ¿Tu centralita es Teams Phone? Ese día tampoco hay teléfono. ¿Hay flujos de Power Automate en medio de pedidos o avisos? Ese día no corren. ¿Tu VPN o tus aplicaciones internas autentican contra Entra ID? Una caída de identidad puede dejarte fuera hasta de lo que tienes en casa. No hace falta rediseñarlo todo: hace falta haberlo listado antes, para que ese día sea un vistazo y no un descubrimiento.
- 5.Umbral y modo degradado decididos antes. ¿A partir de qué momento se activa qué? A los 30 minutos, aviso general por el canal B; a la hora, teléfono para clientes y el correo alternativo para pedidos urgentes. Los números exactos importan menos que el hecho de haberlos decidido en frío, con la cabeza de un martes por la mañana y no la de un miércoles a las cinco.
- 6.Y el matiz del backup, por honestidad. Un backup de Microsoft 365 no te devuelve Teams durante una caída: no existe "restaurar Teams en tu servidor". El backup te protege del riesgo contrario — borrados, ransomware, retención — que Microsoft no cubre por ti. Son dos riesgos distintos con dos respuestas distintas, y las necesitas ambas: que nadie te venda una como remedio de la otra.
La continuidad no se compra: se decide
La próxima caída de un proveedor grande no es una hipótesis: mirando los últimos nueve meses, es cuestión de semanas que le toque a alguno. No puedes evitarla y no puedes acortarla. Lo único que decides tú es si esas horas pillan a tu empresa con seis decisiones escritas o con cuarenta personas mirándose. En everyWAN trabajamos exactamente esto dentro de cumplimiento y continuidad: planes proporcionados al tamaño de cada empresa — de los que caben en dos páginas y se ensayan una vez al año, no de los que crían polvo en un cajón. Si el tuyo hoy es "esperemos que no se caiga", hablamos.
Fuentes (verificadas): caída de Microsoft 365 del 23-jul-2026, servicios afectados, alcance en Norteamérica, pico de Downdetector y reversión del cambio de red — BleepingComputer; cronología del incidente MO1437424 (inicio 14:44 UTC, resolución y rollback) y lista completa de servicios — Cybersecurity News; análisis de la caída de Azure Front Door del 29-oct-2025 (cambio de configuración, duración) — ThousandEyes; caída de Exchange Online/Teams del 22-ene-2026 y el cambio de balanceo que alargó la recuperación — Messageware; SLA del 99,9% con créditos de servicio — Microsoft, SLA for Online Services.
¿Tu plan de continuidad depende de que Teams funcione?
En everyWAN ayudamos a las empresas a decidir en frío qué pasa cuando su proveedor tiene un mal día: canal B, dependencias mapeadas, modo degradado y un plan que cabe en dos páginas y se ensaya. Mejor escribirlo un martes tranquilo que improvisarlo un miércoles a las cinco.
Hablar con everyWAN
Microsoft 365
ES 
CAT 
EN