El jueves por la tarde se cayó Microsoft 365 y con él el correo, el Teams y el Copilot de miles de empresas. Hubo oficinas enteras mirando la pantalla a la espera de que volviera, porque no tenían otra forma de hablar con clientes, proveedores ni compañeros. El plan B, cuando existía, también estaba en Teams.
Lo han seguido de cerca nuestros compañeros de RevistaCloud y de OpenSecurity, que detallaron los servicios afectados y los riesgos de seguridad que dejó la caída. Aquí juntamos lo que se sabe ya con la incidencia cerrada y lo traducimos a lo que importa a una empresa: qué habría que tener preparado para la próxima vez. Porque habrá una próxima vez, en Microsoft o en cualquier otro proveedor.
Las horas están en horario peninsular. Las hemos convertido desde los avisos de Microsoft que recogieron Petri y la prensa que siguió la incidencia.
| Momento | Qué ocurrió |
|---|---|
| Jueves 12, 17:17 | Empiezan los fallos en Exchange Online: los buzones no cargan desde Outlook, la web ni el móvil |
| Jueves 12, tarde | El problema se extiende: Teams (calendario y reuniones), SharePoint, OneDrive, Copilot, Defender, Purview, Intune. Microsoft pausa los despliegues, reinicia servidores y desvía tráfico, y los servidores que vuelven se caen otra vez |
| Viernes 13, madrugada | Microsoft empieza a revertir un cambio reciente de configuración de red que coincide con el inicio del problema, sin confirmar aún que sea la causa |
| Viernes 13, mañana | Recuperaciones parciales en Asia-Pacífico y en Europa que no se sostienen. A media mañana se cumplen 17 horas de problemas |
| Viernes 13, 19:09 | Microsoft pide disculpas y explica la causa: un fallo introducido en una ampliación anterior de capacidad de red |
| Viernes 13, 23:15 | El servicio se estabiliza. Queda procesar las colas de correo retrasado |
| Sábado 14, 7:22 | Microsoft da por resuelto el problema de fondo y el servicio restablecido en todo el mundo |
Desde el primer fallo hasta que se dio por cerrado pasaron unas 38 horas. No todas fueron de apagón total: el viernes por la tarde el correo ya funcionaba para muchos usuarios, aunque con retrasos e intermitencias. Pero para una empresa que trabaja de lunes a viernes supuso perder la tarde del jueves y buena parte del viernes. Downdetector llegó a recibir más de 130.000 avisos de Outlook desde 74 países y territorios, según ITdaily.
Fuera de España el golpe fue serio. En Reino Unido, el NHS tuvo que cancelar algunas operaciones y sufrió problemas con la receta electrónica, según The Guardian, y en Australia la ABC se dedicó a calcular el coste para las empresas.
Microsoft lo ha dejado claro: «Fue un problema técnico, no relacionado con ciberataques ni con IA o agentes». No hubo un pico de usuarios ni un ataque de denegación de servicio. Lo que se ve en sus avisos es un fallo que se alimenta a sí mismo:
Es el escenario que más temen quienes operan sistemas grandes. Cada medida de alivio (reiniciar, redistribuir) genera más carga. Microsoft llegó a reconocer el viernes por la mañana que su propia redistribución había provocado un pico de tráfico entre los servicios de enrutamiento y los servidores. Salir de ahí exigió congelar todos los cambios no esenciales, limitar parte del tráfico de entrada, parchear un componente de autenticación y enrutamiento, añadir máquinas virtuales y devolver el servicio por partes, comprobando la estabilidad en cada paso.
La explicación oficial señala que el fallo se introdujo durante una ampliación anterior de capacidad de red y salió a la luz con un cambio posterior. Es decir, el fallo llevaba un tiempo ahí y nadie lo había visto. Coincidió además con el Patch Tuesday de noviembre, que OpenSecurity cifró en más de 1.000 vulnerabilidades corregidas, aunque Microsoft no ha relacionado una cosa con la otra. El análisis completo de la causa, el informe posterior al incidente que Microsoft suele publicar en el aviso MO1550821 del centro de administración, todavía no se ha publicado.
Al principio, los avisos de Microsoft no se publicaban donde suelen publicarse. El estado de Microsoft 365 se consulta en el centro de administración del propio Microsoft 365, y ese panel tampoco funcionaba bien. Microsoft acabó trasladando la información a su página pública de estado, status.cloud.microsoft, y a su cuenta en X, avisando de que los administradores quizá no podían entrar en el panel.
Esto tiene consecuencias prácticas:
La lista de servicios afectados dice mucho. En Microsoft 365 el correo, el calendario, el chat, los documentos, el asistente, la gestión de dispositivos y parte de la seguridad del correo dependen de la misma plataforma. Cuando cae Exchange Online, el efecto se encadena. Es una dependencia que la mayoría de las empresas aceptó sin medirla.
RevistaCloud recuerda que esta es la tercera incidencia importante de Microsoft 365 en 2026. En enero el servicio estuvo casi diez horas caído en Norteamérica y a finales de agosto miles de usuarios de Outlook se quedaron sin buzón por un fallo en una configuración de autenticación compartida. Ninguna de las tres fue un ataque. Las tres fueron cambios internos que salieron mal.
Esto no va contra Microsoft. Le ha pasado a AWS, a Google Cloud y a Cloudflare, y volverá a pasarle a cualquiera, nosotros incluidos. Un servicio de este tamaño no puede no fallar nunca. El problema es que muchas empresas organizaron su trabajo como si fuera a ser así.
El acuerdo de nivel de servicio de Microsoft para los servicios en línea compromete un 99,9 % de disponibilidad mensual en Exchange Online, Teams o SharePoint. Si no se cumple, Microsoft devuelve un crédito sobre la cuota de ese servicio:
| Disponibilidad del mes | Crédito sobre la cuota mensual del servicio |
|---|---|
| Menos del 99,9 % | 25 % |
| Menos del 99 % | 50 % |
| Menos del 95 % | 100 % |
Un 99,9 % mensual equivale a unos 43 minutos de parada permitidos al mes. Esta caída los ha superado con creces. Aun así, conviene tener claras tres cosas:
Por eso la pregunta útil no es qué te debe Microsoft, sino cuánto aguanta tu empresa sin correo ni Teams antes de empezar a perder dinero.
Clientes, proveedores, equipo y quien da soporte informático. Con teléfono móvil, no solo con dirección de correo. Impresa en la oficina o guardada en el móvil, fuera de Outlook y fuera de OneDrive. Parece una recomendación de 1995, pero el jueves por la tarde hacía falta.
«Si cae el correo, nos hablamos por aquí», decidido y probado antes de que pase, no improvisado a media tarde. Hay un matiz que casi nadie revisa: el canal alternativo no puede depender de la misma identidad. Si la otra herramienta de chat, el CRM o la VPN entran con la cuenta corporativa de Microsoft Entra ID, se pueden caer junto con lo demás si falla la autenticación, como pasó en agosto. Lo prudente es que al menos un canal funcione con su propio usuario y contraseña, y que la plantilla sepa cuál es.
Ese canal también es el sitio para avisar a los empleados de que no deben reenviar correos en bucle ni fiarse de mensajes que pidan contraseñas mientras dure la incidencia.
Un plan de continuidad no sirve de nada si nadie lo activa. Hay que decidir de antemano quién lo declara y con qué criterio, por ejemplo: «más de 60 minutos sin correo en horario laboral». También qué se hace a continuación: avisar por el canal alternativo, llamar a los clientes con entregas comprometidas, pasar las reuniones al teléfono y apuntar las horas y lo que se ha dejado de hacer. Si esa persona no existe, el plan tampoco.
Que el correo esté en la nube no significa que esté respaldado. Microsoft replica los datos para que no se pierdan si falla un disco o un centro de datos, pero eso no es una copia de seguridad que puedas usar cuando quieras. En Exchange Online, un correo borrado se puede recuperar durante 14 días por defecto y 30 como máximo, según la documentación de Microsoft. Después desaparece.
Microsoft vende su propio producto, Microsoft 365 Backup, y está bien para lo que promete, que es recuperarse rápido de un ransomware o de un borrado masivo. Pero su documentación lo dice claramente: los datos «nunca salen del perímetro de confianza de Microsoft 365». Si la plataforma no responde, la copia tampoco.
Una copia fuera de Microsoft, en tu propia infraestructura o en un almacenamiento europeo independiente, no te devuelve el servicio de correo durante la caída. Ninguna copia lo hace, y conviene no venderla así. Lo que sí hace es dejarte consultar el correo, los contactos y los archivos de antes de la caída: el presupuesto que había que mandar, la dirección de entrega o el contrato que estaba en SharePoint. También te protege de lo que no cubre ninguna réplica: una cuenta suspendida, un borrado que se detecta tarde o una disputa con el proveedor. Sigue la misma lógica que contamos en la regla 3-2-1: al menos una copia en otro sitio y con otra tecnología.
Muchas pólizas de ciberriesgo cubren la interrupción del negocio causada por un ataque, pero no la que provoca un fallo no malicioso de un proveedor. Esta caída es justo de las segundas. Cuando esa cobertura existe, suele ser una extensión que hay que contratar aparte, con nombres como «interrupción por fallo de sistemas» o «interrupción por dependencia de terceros».
Además, casi todas aplican una franquicia temporal: el seguro empieza a contar a partir de cierto número de horas de parada, a menudo 8, 12 o 24 según la póliza. En una caída como esta, esa franquicia se come buena parte del daño. Merece la pena preguntar hoy mismo al corredor qué habría pagado la póliza por lo del jueves y el viernes.
Sin una cifra, no hay forma de dimensionar ni el plan ni el seguro. El cálculo no tiene que ser perfecto, basta con que sea honesto:
| Concepto | Cómo calcularlo |
|---|---|
| Productividad perdida | Personas afectadas × horas × coste por hora × porcentaje de trabajo que no pudieron hacer |
| Ventas y pedidos | Pedidos que no entraron o se retrasaron × margen medio |
| Penalizaciones | Entregas o plazos incumplidos con cláusula |
| Recuperación | Horas extra para sacar la cola de trabajo pendiente |
Un ejemplo inventado, solo para ilustrar el cálculo: una empresa de 40 personas, con un coste medio de 30 € por hora, que pierde 10 horas laborables y en las que la mitad del trabajo dependía del correo o de Teams, pierde 40 × 10 × 30 × 0,5 = 6.000 € solo en productividad, antes de contar un solo pedido. Si se compara con el crédito del SLA de un mes de licencias, se ve enseguida quién asume el riesgo.
Con esa cifra en la mano se pueden tomar decisiones razonables, como qué RTO y RPO necesita cada servicio, cuánto tiene sentido gastar en alternativas y qué franquicia de seguro se puede aceptar.
Es la reacción del día después, y casi siempre es la equivocada. Montar un Exchange propio ya no es una opción sensata: Exchange 2016 y 2019 se quedaron sin parches en octubre y Microsoft pide que se consideren «permanentemente vulnerables». Gestionar un servidor de correo propio en 2026 tampoco es trivial. Ya explicamos lo que exigen hoy Gmail y Outlook a quien envía desde su propio servidor de correo.
Para la mayoría de las empresas, Microsoft 365 sigue siendo una buena decisión. Lo que no tiene sentido es que todo dependa de él sin ninguna salida. Hay términos medios razonables:
La caída también alimenta el debate europeo sobre la dependencia de los grandes proveedores estadounidenses, y RevistaCloud lo apunta bien: este fallo no tiene que ver con la soberanía del dato, sino con la concentración. Cuantas más funciones críticas descansan en una sola plataforma, más alcance tiene cualquier error en ella. Si alguna vez te planteas cambiar de proveedor, recuerda que desde 2027 la Ley de Datos prohíbe los cargos por salida, aunque la migración siga siendo trabajo tuyo.
La nube no es tu plan de continuidad. Es el motivo por el que necesitas uno. Microsoft resolverá esta incidencia, publicará su informe y corregirá el proceso que falló. Lo que no puede hacer por ti es decidir cómo trabaja tu empresa durante las horas en que su plataforma no responde.
Si quieres revisar qué pasaría en tu caso, en continuidad de negocio y disaster recovery empezamos precisamente por ahí: qué servicios son críticos, cuánto cuesta una hora sin ellos y qué copia o alternativa tiene sentido mantener fuera del proveedor principal.
¿Cuánto tiempo aguantaría tu empresa sin correo ni Teams antes de que empezara a doler de verdad?
Empezó el jueves 12 de noviembre de 2026, hacia las 17:17 hora peninsular, con fallos en Exchange Online que se extendieron a Outlook, Teams, SharePoint, OneDrive, Copilot, Defender e Intune. Microsoft dio el servicio por restablecido en todo el mundo a las 7:22 del sábado 14, unas 38 horas después.
No. Microsoft afirma que fue un problema técnico sin relación con ciberataques ni con IA. Lo atribuye a un fallo introducido en una ampliación anterior de capacidad de red, que salió a la luz con un cambio posterior y saturó un proceso de los servidores. El informe definitivo está pendiente en el aviso MO1550821.
Solo a través del SLA, con un crédito del 25, el 50 o el 100 % de la cuota mensual del servicio afectado, según cuánto baje la disponibilidad del 99,9 %. El administrador tiene que reclamarlo. El crédito no cubre las pérdidas de negocio, como pedidos o entregas.
Sí. Microsoft replica los datos para que no se pierdan por un fallo de hardware, pero un correo borrado solo se puede recuperar durante 14 días por defecto y 30 como máximo. Su producto Microsoft 365 Backup guarda las copias dentro de Microsoft 365, así que no sirve si la plataforma no responde. Una copia fuera de Microsoft permite consultar los datos durante una caída y recuperarlos ante borrados tardíos o una cuenta suspendida.
Depende de la póliza. Muchas cubren la interrupción por ataque, pero no la provocada por un fallo no malicioso de un proveedor, que suele ser una extensión aparte. Además, la mayoría aplica una franquicia temporal de varias horas antes de empezar a cubrir. Conviene preguntar al corredor qué habría pagado por esta caída.
Una lista de contactos críticos fuera de Microsoft, un canal de comunicación alternativo con su propia autenticación, una persona con autoridad para declarar el incidente, una copia del correo y los archivos fuera de Microsoft 365, una póliza revisada y una estimación del coste de una hora parada. Y ensayarlo al menos una vez al año.
¿Recuperarías tus sistemas a tiempo?
Dinos cuántas máquinas tienes y cuánto puedes estar parado. Te respondemos con qué esquema de copias y recuperación te encaja.
Valkey se vende como reemplazo directo de Redis, y lo era en 2024. Hoy depende de la versión de la que vengas. Hemos probado copias, réplicas y carga de datos entre Redis 7.2, Redis 8 y Valkey 9 en Docker: un archivo de Redis 8 impide arrancar a Valkey, y al revés. Qué cambia en licencia, qué trae cada paquete y cómo migrar sin sorpresas.
DeepSeek ha publicado dsh-superagent, un prototipo abierto que separa al agente que reparte el trabajo de los que lo hacen. Hemos leído su código y sus documentos: cómo viaja una petición, qué miden de verdad sus experimentos, qué permisos tiene y qué cambia si quieres montarlo en infraestructura propia.
Un fallo de use-after-free en la gestión de conexiones TCP sobre IPv4, con puntuación de 9,8, afecta a kernels Linux desde la 4.4. Anthropic ha demostrado que da root remoto en servidores que escuchan con MPTCP, pero el fallo no depende de MPTCP. Qué sistemas están corregidos, qué pasa con Proxmox, por qué Ubuntu aún no tiene paquete y qué hacer mientras tanto.