A las 20:17, hora de Dubái, del jueves, el correo se detuvo.
No en una empresa. No en una región. En una porción enorme del planeta, en el mismo instante y la misma noche. Outlook se quedó en blanco. Los buzones de Exchange Online se negaban a abrir. Las llamadas de Teams caían en silencio. Copilot respondía con una disculpa. Los enlaces de SharePoint giraban sin fin. Unos 131.000 personas abrieron Downdetector en las primeras horas para comprobar si el problema era suyo, y los reportes llegaron de 74 países y territorios en unos sesenta minutos.
Lo observamos de la forma menos glamurosa posible: una terminal, un puñado de sondas y un reloj. A las 16:44 de Dubái de la tarde siguiente, más de veinte horas después, outlook.office.com y outlook.office365.com seguían sin completar un handshake TCP desde aquí, mientras graph.microsoft.com, login.microsoftonline.com y teams.microsoft.com respondían en milisegundos. Esa única asimetría contaba casi toda la historia antes de que Microsoft dijera una palabra: no era internet rompiéndose, ni un accidente de enrutamiento en el Golfo. Era la puerta principal de Microsoft, y estaba atascada.
Nuestro correo nunca se movió. aratech.ae funciona sobre Migadu, así que nuestras bandejas estuvieron activas todo el tiempo. No es una fanfarronada: es la lección completa de esta caída comprimida en una frase, y volveremos a ella.
Qué se rompió realmente
El propio canal de estado de Microsoft lo describe de una forma que debería hacer levantar la cabeza a cualquier ingeniero de infraestructura: un proceso central en los servidores afectados, el responsable de establecer conexiones seguras, quedó desbordado. Cuando ese proceso se satura, el servidor deja de procesar peticiones. No despacio. No parcialmente. Se detiene. Después los servidores fallaron sus propias comprobaciones internas de salud, el tráfico se desvió y la plataforma empezó a reiniciarlos.
Ahí es donde la recuperación se convirtió en un bucle. Los servidores reiniciados volvían sanos, recibían tráfico y dejaban de responder otra vez. Microsoft lo dijo sin rodeos: los servidores que causaron la caída pueden volver a quedar sin respuesta en cuanto reciben tráfico. Por eso, durante buena parte de la noche, la compañía limitaba deliberadamente qué tipos de tráfico podían siquiera llegar a la infraestructura afectada en algunas ubicaciones. Cuando un proveedor empieza a descartar las peticiones de sus propios clientes para proteger un servicio de ser querido hasta la muerte, no estás ante un error de software. Estás ante un fallo de capacidad y de plano de control con un bucle de reinicio encima.
ThousandEyes, mirando desde fuera, vio exactamente cómo se ve eso en el cable: reseteos de conexión, rechazos de conexión, tiempos de espera agotados, errores HTTP de servidor y una pérdida de paquetes significativa dentro de la propia red de Microsoft. No en el borde. Dentro.
La primera cronología de Microsoft situó el inicio a las 16:17 UTC del 12 de noviembre. ThousandEyes observó impacto desde cerca de las 17:30 UTC. Esa diferencia importa, porque es la distancia entre el momento en que un sistema se rompe y el momento en que lo admite.
Dos cosas han sido claras por parte de Microsoft, y ambas merecen repetirse en lugar de enterrarse: no hay evidencia de actividad maliciosa ni ciberataque, y habrá un informe completo posterior al incidente con causa raíz y acciones de defensa en profundidad cuando termine la mitigación. Hasta que llegue ese informe, cualquier explicación segura que leas, incluida una versión más detallada de esta, es inferencia vestida de hecho.
Por qué un proceso tumbó once productos
Aquí está la parte que debería preocuparte más que la caída en sí.
La lista de servicios afectados no era una lista de productos que casualmente comparten un centro de datos. Era Outlook, Exchange Online, Teams, SharePoint Online, Copilot, Defender XDR, Defender for Office 365, Planner, To Do e Intune. Lee la lista otra vez y fíjate en lo que comparten: casi todos leen de Exchange Online, escriben en él o se autentican a través de él.
Exchange no es solo correo. En un tenant de Microsoft 365 es el bus de notificaciones, la columna del calendario, la invitación a la reunión, el correo de aprobación, el restablecimiento de contraseña, la alerta de que falló una copia de seguridad, el ticket que avisa de que un servidor está caído. Cuando el plano del correo se atasca, el plano de control del negocio se atasca con él, y se atasca de formas que nadie documentó porque nadie dibujó nunca el grafo.
Ese es el hallazgo real de esta semana, y no es un hallazgo sobre Microsoft. Es un hallazgo sobre arquitectura. El grafo de dependencias de un negocio moderno es un diagrama de estrella con el logo de un proveedor en el centro, y la mayoría de las empresas nunca ha visto su propia copia.
La ventana de 48 horas y lo que significa
A las 04:15 ET del viernes, Microsoft amplió la ventana de timeout del correo a 48 horas.
Léelo como una confesión de ingeniería. La ventana de timeout es cuánto tiempo espera un servidor o un cliente de correo antes de rendirse y devolver un error. Ampliarla a 48 horas significa que Microsoft espera que los mensajes se queden en cola muchísimo tiempo mientras drena el atraso, y prefiere retenerlos antes que rebotarlos. Consecuencias prácticas, ordenadas por lo que te van a costar:
Los mensajes que te envíen desde Gmail, Outlook.com y otros proveedores sanos durante la caída probablemente estén en cola, no perdidos. Llegarán tarde, en bloque, desordenados y mezclados con todo lo demás.
Los mensajes que enviaron tus usuarios durante la caída pueden aparecer como enviados y no salir nunca, o salir dos veces, según cómo los cacheó el cliente. Facturas duplicadas y recordatorios de pago duplicados son un riesgo real esta semana.
Todo lo que tenía una fecha límite dentro de la ventana se perdió. Licitaciones, documentos de visado, instrucciones bancarias, firmas de contratos. El correo sigue siendo el registro legal de casi todo esto en esta región, y el registro tiene un agujero.
Lo que el mundo perdió de verdad
La lista de impacto se lee como una prueba de estrés de la infraestructura civil, que es lo que fue.
El correo del NHS británico se interrumpió lo suficiente como para que se esperara que algunos pacientes perdieran recetas. Fuerzas policiales de Merseyside, Greater Manchester, Bedfordshire, Dorset y Hertfordshire pidieron al público llamar al 101 porque los formularios online estaban caídos. La red del Parlamento en Westminster se vio afectada. En Estados Unidos, la Cámara de Representantes dijo que sus ingenieros trabajaban con Microsoft, gobiernos municipales desde Miami Beach hasta Austin y el condado de Baltimore pidieron a los vecinos usar el teléfono, y la oficina del sheriff del condado de Arapahoe reportó pagos de fianza retrasados. Workhorse Group aplazó su llamada de resultados trimestrales. OpenAI reportó problemas con los conectores de Microsoft y Anthropic tuvo que desplegar una corrección tras una ola de errores de Claude.
Ninguna de esas organizaciones carecía de departamento de IT. Casi todas tenían un plan de continuidad de negocio. Lo que no tenían era un plan para el caso concreto de que el plano de control del proveedor esté en un bucle de reinicio y tu proveedor de identidad esté dentro.
La aritmética incómoda para esta región
Microsoft 365 lo usan cientos de millones de personas, y la concentración no está repartida por igual. En el Golfo es casi el valor por defecto. Bancos, autoridades de zonas francas, clínicas, colegios, empresas logísticas y un número enorme de pymes gestionan toda su jornada a través de un tenant que, durante un día, fue el software menos fiable que tenían.
Ahora la parte que debe escocer. La caída empezó a las 20:17 del jueves en Dubái. En una semana laboral de domingo a jueves, ese es el mejor momento posible: después de enviar el trabajo de la semana, antes de que nadie necesitara responder nada. Si el mismo fallo hubiera caído a las 09:00 de un domingo, la semana de la región habría empezado con una bandeja muerta y sin forma de explicar a los clientes por qué.
Eso no es resiliencia. Es suerte, y la suerte no es un control que puedas meter en un registro de riesgos.
Qué haríamos el lunes por la mañana
No es un discurso comercial. Es una lista. Casi todo cuesta tiempo, no dinero, y todo es más barato que la noche del jueves.
1. Dibuja el grafo de dependencias con honestidad. Anota cada proceso de negocio que se detiene cuando se detiene el correo: facturación, códigos de un solo uso y de doble factor enviados por correo, firma electrónica, tickets, restablecimiento de contraseñas, notificaciones del CRM, alertas de copias de seguridad, aprobaciones de nómina. Luego marca cuáles tienen una vía que no sea el correo. En la mayoría de empresas la respuesta honesta es ninguna, y ese es el hallazgo.
2. Saca la identidad del camino del correo. Si el restablecimiento de contraseña, el alta de MFA y la recuperación de cuenta pasan por el mismo buzón que se apagó, una caída se convierte en un bloqueo total. Cuentas de administración de emergencia con llaves físicas, códigos de recuperación guardados offline y un canal de administración fuera de banda no son paranoia. Son la diferencia entre un incidente y un parón.
3. Mantén una segunda puerta abierta. Un proveedor de correo secundario en un registro MX aparte, o como mínimo un procedimiento documentado y probado para cambiar los MX y levantar un buzón de respaldo, convierte una caída de 20 horas en una molestia de 20 minutos. No es gratis ni es para todos, pero el cálculo cambió esta semana.
4. Monitoriza el recorrido del usuario, no el ping. Una comprobación ICMP en verde contra una IP de Microsoft no te dijo nada el jueves. Lo que necesitabas era un login sintético al cliente web, un mensaje real de envío y recepción cada cinco minutos, y una alerta cuando se rompe el viaje completo. Monitoriza lo que hace tu gente, no lo que es fácil de graficar.
5. Escribe el runbook de comunicación antes de necesitarlo. Quién avisa a los clientes, por qué canal, con qué palabras, y quién decide cambiar de canal. SMS y WhatsApp funcionaron perfectamente el jueves. Casi nadie tenía un mensaje preaprobado listo para enviar por ahí.
6. Sabe cuánto vale de verdad tu SLA. Los créditos de servicio de Microsoft por una caída así son un error de redondeo frente a un día perdido de una empresa comercial. El SLA es una política de reembolso, no un plan de continuidad. Presupuesta en consecuencia.
7. Lee el informe posterior cuando llegue y tradúcelo a tu registro de riesgos. Microsoft ha prometido causa raíz y acciones de defensa en profundidad. Sea lo que sea que publiquen, la pregunta no es qué hizo mal Microsoft, sino qué en nuestra pila tiene la misma forma.
La factura llega después
Caídas así se recuerdan como un viernes malo y se olvidan el miércoles siguiente. El coste no desaparece, solo se reparte: el acuerdo que se retrasó, la factura que se pagó dos veces, el cliente que empezó a preguntarse en silencio si tu correo es una forma fiable de llegar a ti.
El resumen honesto es este. Un único proceso saturado dentro de la infraestructura de un proveedor tumbó correo, chat, archivos, asistentes de IA, telemetría de seguridad y gestión de dispositivos para una gran parte del mundo, durante buena parte de un día, y la recuperación solo aguantó cuando el proveedor empezó a limitar a sus propios clientes. Sin atacante. Sin día cero. Solo un grafo de dependencias que nadie dibujó y un bucle de reinicio que nadie había ensayado.
Nosotros construimos y operamos infraestructura para vivir, y no estamos exentos de nada de lo anterior. La única diferencia es que pasamos la noche del jueves mirando las sondas en vez de la bandeja, y ya sabíamos qué clientes lo notarían primero. Si no sabes eso de tu propio negocio, esta semana te dio un ensayo gratis. Úsalo antes de que el siguiente te cueste algo.