Análisis de incidentes12 de noviembre de 20269 min de lecturaPor Ale Cano

Anatomía de la caída de Microsoft 365 del 12 de noviembre: health checks, fallas en cascada y lo que revela un error de Outlook Web

Microsoft 365 cayó sin un aumento de tráfico: sus servidores empezaron a fallar las revisiones de salud y la carga se volvió una cascada. Cronología técnica, análisis del error de OWA y lecciones de arquitectura.

El 12 de noviembre de 2026, Microsoft 365 sufrió una de las caídas más amplias del año. Durante horas, Exchange Online, Teams, SharePoint, Copilot y una lista creciente de servicios de seguridad y cumplimiento fallaron para usuarios de cualquier región. Lo interesante desde el punto de vista de ingeniería es el mecanismo. Según Microsoft, no hubo más tráfico del normal: los servidores empezaron a fallar sus revisiones automáticas de salud (health checks), salieron del servicio y dejaron al resto de la infraestructura con una carga que no podía absorber.

En este artículo reconstruimos la cronología técnica, analizamos el error que mostraba Outlook en la web y sacamos las lecciones de arquitectura que aplican a cualquier sistema que opere detrás de un balanceador de carga.

Resumen del incidente

Identificador	Tipo	Alcance	Inicio (Guatemala / UTC)
EX1550543	Incidente	Exchange Online: buzones inaccesibles desde Outlook en la web, MAPI, Exchange ActiveSync y la API REST	10:17 / 16:17
MO1550821	Aviso	Suite Microsoft 365: Teams, SharePoint Online, Copilot, Defender XDR, Planner, To Do, Intune, Defender for Office 365, Purview, Power BI, centro de administración de Apps y Universal Print	12:26 / 18:26
TM1550488	Incidente (aparte)	Mensajería de Teams en América, por contención de recursos. Resuelto de 8:45 a 9:53	8:45 / 14:45

TM1550488 fue un incidente distinto y anterior. No conviene mezclarlo con los otros dos en un análisis posterior.

Cronología técnica

Horas de Guatemala (UTC−6), reconstruidas a partir de las actualizaciones públicas de Microsoft 365 Status:

Hora	Evento
10:17	Empieza EX1550543. Fallan las conexiones a los buzones por varios protocolos.
11:45	Microsoft encuentra errores de conectividad en la infraestructura que atiende las solicitudes de acceso y recopila registros de red.
12:07	El impacto puede alcanzar a usuarios de cualquier región.
12:19	Hay carga elevada en varias regiones. Empiezan los reinicios y reparaciones.
12:43	Los servidores se vuelven intermitentemente no disponibles. Se redistribuye a nivel mundial el tráfico de conexión de Outlook.
13:06	Se congelan todos los despliegues y cambios de configuración.
13:18	La carga no viene de más tráfico, sino de muchos servidores no disponibles de forma inesperada.
13:43	Los servidores fallan los health checks automáticos. Se sospecha de un cambio reciente en el componente que procesa esas revisiones.
13:57	No aparece ningún cambio que coincida con el inicio. Se omite el componente sospechoso en un subconjunto de servidores y se investiga un uso alto de procesador.
14:38	Muchos servidores dejan de responder durante la validación y se reinician con el cambio aplicado.
14:56	Un método alterno de health check devuelve un subconjunto de servidores al servicio. Se extiende al resto. Se preparan reinicios automáticos de los nodos que no respondan.
15:31–15:40	Se evalúa revertir unas pocas actualizaciones de configuración recientes.
16:00	Las acciones previas no dieron el alivio esperado: un proceso central de los servidores se satura y causa pérdida de capacidad. Se aísla parte de la infraestructura para probar una recuperación.
16:57	Una parte de los servidores vuelve y se mantiene estable. Se aplica gestión protectora de tráfico. Hay recuperación limitada.

Al cierre de esta nota (18:30, hora de Guatemala), Microsoft no había publicado la causa raíz ni dado el incidente por resuelto. La página pública de estado de Microsoft también dejó de cargar un rato, alrededor de las 13:21.

¿Por qué un health check puede tumbar un servicio entero?

Un balanceador de carga revisa periódicamente cada servidor de su grupo. Si un servidor no responde bien, lo saca de la rotación para que los usuarios no lleguen a un nodo enfermo. Es un mecanismo de protección, pero tiene un modo de falla conocido: la falla en cascada.

Por alguna razón, un grupo de servidores empieza a fallar la revisión. La causa puede ser un componente defectuoso, un pico de procesador o un cambio de configuración.
El balanceador los saca de la rotación, y su tráfico se reparte entre los que quedan.
Los servidores restantes reciben más carga de la que pueden atender. Responden lento y también empiezan a fallar la revisión.
Salen más servidores, la carga por nodo sube otra vez y el ciclo se repite.
Cuando se reinician, los nodos que regresan reciben de golpe todas las conexiones pendientes y pueden caer de nuevo. Es una tormenta de reconexiones.

Esto coincide con lo que Microsoft describió: carga elevada sin aumento de tráfico, servidores que fallaban la revisión y un proceso central saturado. Por eso la solución tuvo que ver con cambiar la forma de revisar la salud y con automatizar los reinicios, no con agregar capacidad.

El componente que revisa la salud también puede fallar

Si la revisión depende de un componente compartido, una falla en ese componente hace que servidores sanos parezcan enfermos. Ese componente puede ser un servicio de configuración, un proceso que procesa las revisiones o una dependencia común. Microsoft mencionó justamente un «componente responsable de procesar la salud de los servidores». En ese escenario, el sistema de protección se convierte en el origen de la caída.

Diseccionando el error de Outlook en la web

Este es el error que registramos en una de nuestras cuentas a las 17:45 (23:45 UTC), en plena ventana del incidente:

UTC Date: 2026-11-12T23:45:40.518Z
Client Version: 20261030007.20
BootResult: network
err: TypeError: Failed to fetch
esrc: StartupData
et: ServerError
estack: TypeError: Failed to fetch
    at https://res.public.onecdn.static.microsoft/owamail/hashed-v1/scripts/owa.mailindex.fba3a5ca.js:2:148026
    at new Promise (<anonymous>)

Cada campo cuenta parte de la historia:

estack apunta a res.public.onecdn.static.microsoft. El paquete de JavaScript de Outlook sí se descargó desde la CDN de Microsoft y se ejecutó en el navegador. La CDN de archivos estáticos funcionaba.
esrc: StartupData. Lo que falló fue la petición de datos de arranque: la primera llamada que hace la aplicación al servidor de Outlook para obtener la configuración del buzón, las carpetas y la sesión. Sin esos datos, la aplicación no puede dibujar la bandeja.
TypeError: Failed to fetch. Es el error genérico de la API fetch() del navegador cuando no recibe ninguna respuesta HTTP utilizable. Puede venir de una conexión rechazada o reiniciada, de un tiempo de espera agotado, de un fallo de TLS o de una respuesta de error sin los encabezados que el navegador exige. Desde JavaScript no se puede distinguir entre esas causas.
BootResult: network / et: ServerError. Outlook clasifica el arranque como fallido por red y atribuye el error al servidor.

Conclusión: el cliente y la CDN estaban bien, y el backend que entrega los datos del buzón no respondía. Es justo la capa que describe EX1550543.

Un apunte de diagnóstico: el mismo mensaje puede aparecer por causas locales, como un proxy corporativo, una extensión del navegador que bloquea peticiones o una VPN. Para descartarlas basta con:

probar desde otra red, por ejemplo los datos móviles;
revisar la pestaña Red de las herramientas de desarrollador y ver si la petición termina en (failed) o con un código 5xx;
comparar la hora con los incidentes abiertos en el estado del servicio.

Si abres un ticket con Microsoft, el Client Id y el Session Id del error permiten rastrear la sesión.

¿Cómo debió reaccionar un equipo de TI?

Monitorear el estado sin depender de la consola

El centro de administración y la página de estado fallaron durante el incidente. Conviene consultar el estado del servicio por la API de Microsoft Graph, desde un script o una herramienta de monitoreo propia (requiere el permiso ServiceHealth.Read.All):

GET https://graph.microsoft.com/v1.0/admin/serviceAnnouncement/healthOverviews
GET https://graph.microsoft.com/v1.0/admin/serviceAnnouncement/issues?$filter=isResolved eq false

Con eso se pueden mandar alertas a un canal que no dependa de Microsoft 365, por ejemplo SMS, Slack o un correo de otro proveedor.

Configurar notificaciones fuera de Exchange

En Service health → Manage notifications se pueden registrar hasta dos direcciones. Si ambas están en Exchange Online, el aviso de que Exchange está caído nunca llega.

Evitar acciones que empeoran el problema

Durante una caída del proveedor, restablecer contraseñas, recrear perfiles de Outlook o quitar y volver a agregar cuentas no ayuda. Además, genera trabajo y tickets cuando el servicio regresa.

Entender cómo se comporta el correo entrante

SMTP está diseñado para reintentar. Según el RFC 5321, un servidor que no logra entregar un mensaje debería seguir intentándolo durante al menos 4 a 5 días antes de rendirse. Por eso, en una caída de unas horas lo normal es que el correo llegue tarde, no que se pierda. El riesgo está en el correo saliente que el usuario cree haber enviado.

Lecciones de arquitectura para nuestros propios sistemas

**Separa liveness de readiness.** Un nodo lento pero vivo no siempre debe salir de la rotación. Orquestadores como Kubernetes distinguen entre «reiniciar el contenedor» y «dejar de mandarle tráfico».
Usa revisiones de salud superficiales para el balanceo. Si el health check consulta la base de datos o un servicio compartido, una falla en esa dependencia saca a todos los nodos a la vez.
**Ten un umbral de pánico (fail open).** Si demasiados nodos fallan a la vez, lo más probable es que el problema esté en la revisión. Envoy, por ejemplo, deja de excluir nodos cuando el porcentaje de sanos baja de un umbral configurable (50 % por defecto). AWS Application Load Balancer envía tráfico a todos los destinos cuando todos aparecen no saludables.
**Reinicia con escalonamiento y jitter.** Volver a meter todos los nodos a la vez provoca una tormenta de reconexiones. Hay que reincorporarlos de forma gradual.
Congela los cambios durante un incidente. Microsoft pausó todos los despliegues en la primera hora. Es una práctica que todo equipo debería tener por escrito.
Aloja la página de estado fuera de tu infraestructura. Si tu página de estado cae junto con tu servicio, tus clientes se quedan sin información justo cuando más la necesitan.
Mide desde afuera. Un monitoreo externo independiente detecta la caída tal como la ve el usuario, aunque los tableros internos digan que todo está bien.

En ABC Alpha aplicamos estas prácticas en los sistemas que desarrollamos y operamos: monitoreo externo independiente, reinicios automáticos controlados y procedimientos de continuidad. Si tu organización depende de Microsoft 365 o de servicios en la nube críticos, podemos ayudarte a diseñar el monitoreo y el plan de contingencia.

Fuentes

Artículo actualizado el 12 de noviembre de 2026 a las 18:30 (hora de Guatemala). El incidente seguía abierto al momento de publicar.

#balanceo de carga #continuidad del negocio #Exchange Online #health checks #Microsoft 365