# La recuperación de Outlook de Microsoft seguía fallando bajo tráfico Published: 2026-11-13 La interrupción del servicio de correo electrónico de Microsoft del 12 al 13 de noviembre expuso un bucle de recuperación: los servidores restaurados podían volverse inactivos nuevamente bajo tráfico. En el corte aprobado del 13 de noviembre a las 11:04:50 UTC, la recuperación había avanzado en algunas partes de Asia Pacífico, mientras que persistían problemas intermitentes y trabajo en otras áreas. Este seguimiento explica las dependencias y las salvaguardias del correo retrasado. Canonical: https://thedailydiff.dev/es-US/video/2026-11-13-microsoft-recovery-loop/ ## Lo que cubre este video - Verifique la dependencia de backend de cada operación: la mayoría de las funcionalidades principales de Teams y el acceso directo a archivos de SharePoint se mantuvieron funcionales, mientras que las características dependientes de Exchange se vieron afectadas. - Microsoft informó que los servidores restaurados podían volverse inactivos nuevamente cuando el tráfico los alcanzaba; su explicación del componente de procesamiento de estado seguía siendo una hipótesis. - El tiempo de espera extendido de cuarenta y ocho horas para el correo electrónico tenía como objetivo preservar el correo retrasado durante el procesamiento de la cola y el backlog. No era un plazo de reparación ni una garantía de entrega universal. - La guía ordinaria de limitación de solicitudes de Graph recomienda respetar Retry-After y el retroceso exponencial cuando ese encabezado está ausente; no diagnostica ni repara este incidente. ## Preguntas y respuestas ### ¿Por qué los servidores de correo de Microsoft restaurados podrían volver a fallar bajo tráfico? Microsoft informó que los servidores restaurados podían volverse inactivos nuevamente una vez que recibían tráfico. Su investigación describió procesos sobrecargados y un posible problema en un componente que procesa el estado del servidor, pero el detonante inicial aún esperaba un informe final del incidente. El episodio ilustra conceptualmente la secuencia reportada de retorno, trabajo y recaída; no afirma una arquitectura interna probada o una causa raíz final. ### ¿Por qué las llamadas de Teams funcionaban mientras que las funciones de calendario fallaban? La mayoría de las llamadas, reuniones y chats principales de Teams se mantuvieron funcionales según el aviso de estado del servicio ampliado de Microsoft. Los escenarios de calendario y programación dependían de Exchange Online y podían fallar durante la interrupción. El acceso directo a archivos de SharePoint también se mantuvo funcional. La distinción útil a nivel de aplicación es la dependencia detrás de una operación, en lugar de tratar cada función bajo un logotipo de producto como si compartiera el mismo estado de falla. ### ¿El tiempo de espera de cuarenta y ocho horas para el correo electrónico estableció un plazo de reparación? Microsoft amplió la ventana de tiempo de espera del correo electrónico para preservar los mensajes retrasados mientras priorizaba el procesamiento de la cola y el backlog. Eso dio más tiempo al correo retrasado durante la recuperación. El aviso público no proporcionó un plazo de reparación de cuarenta y ocho horas y no garantizó que todos los mensajes llegarían a su destinatario. Por lo tanto, una notificación pendiente o en cola requería una entrega real o una verificación de resultados antes de que un flujo de trabajo sensible al tiempo pudiera depender de ella. ### ¿Cómo afectó la interrupción de Exchange a las aplicaciones de Microsoft Graph? Las solicitudes de correo, calendario y contactos de Exchange Online podían agotar el tiempo de espera según Microsoft. Una aplicación podía encontrar diferentes resultados en operaciones con diferentes dependencias subyacentes. El episodio recomienda verificar la dependencia real del servicio de la operación. La documentación separada de Microsoft sobre la limitación de solicitudes ordinaria discute cómo respetar Retry-After y el retroceso exponencial cuando ese encabezado está ausente; esas políticas no establecen la causa de este incidente ni prometen la restauración del servicio. ### ¿Cuál fue el veredicto de The Daily Diff sobre la recuperación de Microsoft? El veredicto de The Daily Diff fue NEEDS REVIEW. Niko mantuvo la recuperación bajo revisión porque las actualizaciones de Microsoft describieron servidores restaurados que fallaban bajo tráfico. El servicio sostenido con trabajo real llegando fue la prueba de recuperación útil. La causa inicial permaneció abierta en el momento del corte del informe del episodio, con Microsoft prometiendo un informe completo del incidente y acciones de defensa en profundidad después de la mitigación. ## Capítulos - 0:00 ¿Por qué volvieron a fallar los servidores restaurados? - 0:19 ¿Qué características dependían de Exchange? - 1:03 ¿Cómo sobrecarga un servicio la falta de capacidad? - 1:34 ¿Qué intentó Microsoft primero? - 2:48 ¿Qué se sabía en el momento del corte del informe? - 3:17 ¿Por qué podría fallar una solicitud de Graph? - 4:05 ¿Qué logra la ventana de correo de 48 horas? - 4:48 ¿Qué necesitaría demostrar una recuperación sostenida? ## Transcripción traducida Traducido de la narración original en inglés. El audio y los subtítulos disponibles son controlados por YouTube. ### ¿Por qué volvieron a fallar los servidores restaurados? 0:00 Microsoft devolvió los servidores de correo al servicio. Podrían dejar de responder nuevamente cuando regresara el tráfico. Aquí está el seguimiento del desarrollador. En este video, ¿por qué la recuperación seguía fallando? ¿Y qué partes de tu aplicación seguían funcionando? Microsoft también le dio al correo electrónico retrasado cuarenta y ocho horas. ¿Qué logra eso realmente? Es viernes, trece de noviembre, y este es The Daily Diff. 0:18 Exchange Online es el servicio de correo electrónico alojado de Microsoft, y otras funciones de Microsoft 365 ### ¿Qué características dependían de Exchange? 0:22 dependen de él. Aquí está la distinción útil de la página de estado de Microsoft. Las llamadas y los chats grupales de Teams funcionaron en su mayoría. Las funciones de calendario y las solicitudes de datos de buzones podrían fallar. Verifique la dependencia que realmente usa su aplicación. Eso significa que una reunión aún puede llevarse a cabo mientras el calendario se niega a cooperar. El acceso directo a los archivos en SharePoint también siguió siendo funcional, mientras que algunas funciones para compartir se vieron afectadas. 0:42 El logotipo en la ventana le dice muy poco sobre qué backend necesita su próximo clic. La interrupción comenzó el jueves, con Microsoft investigando inicialmente el acceso a los buzones en las Américas. Luego confirmó que los usuarios de cualquier región podían verse afectados. CNN informó problemas en bancos, gobiernos y tribunales. Un correo electrónico perdido es un inconveniente hasta que el trabajo real de alguien depende de que llegue. La explicación inicial de Microsoft fue una pérdida de servidores disponibles. ### ¿Cómo sobrecarga un servicio la falta de capacidad? 1:06 El trabajo que esas máquinas deberían haber manejado sobrecargó la infraestructura restante. Puede sobrecargar un servicio con una demanda ordinaria cuando su capacidad desaparece. La cola se alarga incluso si nadie ha descubierto repentinamente una pasión por enviar correos electrónicos. Luego, la compañía investigó las comprobaciones de estado automatizadas. Estas comprobaciones ayudan a decidir si un servidor puede recibir trabajo. Microsoft dijo que un componente que procesa el estado del servidor podría estar involucrado. Esa es una hipótesis de una investigación aún en curso. 1:29 No tenemos un informe final del incidente que explique exactamente por qué esos servidores quedaron no disponibles por primera vez. Las actualizaciones se leen como un turno de guardia que ### ¿Qué intentó Microsoft primero? 1:37 progresivamente pierde interés en el desayuno. Pausar implementaciones. Mover tráfico. Reiniciar servidores. Microsoft validó una comprobación de estado alternativa que recuperó un subconjunto, y preparó sistemas automatizados para detectar y reiniciar máquinas que no respondían. Cada actualización describía un intento de recuperar capacidad. Luego vino la frase que explica el bucle de recuperación. Microsoft dijo que los servidores devueltos al servicio podían volverse inactivos nuevamente una vez que recibían tráfico. 1:59 Una máquina podría volver, recibir trabajo real y dejar de responder. Esa observación es una prueba más sólida que cualquier teoría confiada en las respuestas. Imagine el mismo servidor a través de esos estados. No disponible. Devuelto al servicio. Recibiendo tráfico. Inactivo de nuevo. Esto ilustra el relato de Microsoft. Lo que desencadena esa última transición sigue sin respuesta. Un reinicio puede producir una mejora 2:18 temporal mientras la condición que derrota al servidor sigue sin resolverse. El consejo de apagarlo y volver a encenderlo empieza a cobrar horas extras. Los ingenieros tienen que comprobar qué ocurre después de que vuelve el trabajo. Los clientes necesitan que el servicio siga funcionando con la siguiente solicitud, y la siguiente. Microsoft limitó cierto tráfico que llegaba a la infraestructura afectada en algunas ubicaciones. También reconstruyó un subconjunto de servidores utilizando una configuración anterior para 2:39 probar si se mantendrían reactivos. Esos fueron experimentos de mitigación reportados. Pausar las implementaciones durante la recuperación no nos da ninguna evidencia de que una implementación de viernes causara la interrupción original. ### ¿Qué se sabía en el momento del corte del informe? 2:48 Según la actualización del viernes de Microsoft a las 11:04 UTC, las acciones de recuperación habían terminado en partes de Asia Pacífico. El tráfico estaba regresando gradualmente, con mejoras en el acceso a buzones y el procesamiento de correos electrónicos retrasados. Algunos usuarios aún podrían enfrentar problemas intermitentes, y la recuperación en otras partes continuaba. Ese es nuestro punto de corte para el informe. Microsoft dijo que no tenía pruebas de actividad maliciosa, y prometió un informe completo del incidente después de la mitigación. 3:10 Yo esperaría ese informe antes de asignar un villano. El trabajo de detective en Internet puede darte un culpable incluso antes de que hayas terminado de actualizar la página. Para los desarrolladores, Microsoft Graph hace que la dependencia sea especialmente fácil de pasar por alto. ### ¿Por qué podría fallar una solicitud de Graph? 3:20 Sus solicitudes de correo, calendario y contactos de Exchange podrían agotar el tiempo de espera. Su aplicación puede llamar a Graph con éxito para una operación y fallar en otra. Una solicitud no relacionada exitosa le dice poco sobre si la operación de buzón que su usuario necesita se completará. La página de estado incluso necesitaba su propia ruta de escape. Microsoft publicó información sobre el incidente públicamente porque los administradores podrían no poder cargar el centro de administración para leer el estado del servicio. Cuando el tablero para averiguar qué está roto depende de lo que está roto, 3:46 el tablero se ha unido al incidente. Mantenga un enlace de estado fuera de banda disponible. Para la limitación de solicitudes ordinaria de Graph, la guía de Microsoft dice que se respete el retardo de reintento cuando una solicitud recibe una respuesta de demasiadas solicitudes, y use el retroceso exponencial cuando ese encabezado esté ausente. Esa guía gestiona la limitación de solicitudes. No diagnostica esta interrupción ni promete que los reintentos restauren el servicio. Ahora las cuarenta y ocho horas. ### ¿Qué logra la ventana de correo de 48 horas? 4:05 La página de estado ampliada de Microsoft dice que priorizó el procesamiento de la cola y el backlog y amplió la ventana de tiempo de espera del correo electrónico para preservar los mensajes retrasados. Eso le da más tiempo al correo retrasado durante la recuperación. Establece una ventana de tiempo de espera para el correo. Microsoft no dio un plazo de cuarenta y ocho horas para solucionar el servicio, ni garantizó que todos los mensajes llegarían. Así que mantenga las afirmaciones de entrega honestas. Una notificación retrasada no ha desaparecido necesariamente, 4:28 y un mensaje en cola no ha llegado necesariamente a su destinatario. Para trabajos urgentes, verifique el resultado a través de un canal independiente aprobado. Una ventana de cliente es un recibo de entrega optimista cuando el backend todavía se está recuperando. Lo que deja mucho para leer en el eventual informe del incidente. Si prefiere leer esto en lugar de oírme decirlo, la diferencia llega a su bandeja de entrada cada mañana, gratis en the daily diff dot dev, enlace a continuación. Así que el veredicto de hoy, NEEDS REVIEW. ### ¿Qué necesitaría demostrar una recuperación sostenida? 4:49 Mantendría la recuperación bajo revisión porque las propias actualizaciones de Microsoft mostraron que los servidores devueltos fallaban bajo tráfico. La prueba útil es el servicio sostenido con trabajo real llegando. Hasta el informe final, la causa inicial sigue abierta. Y esa es la diferencia de hoy. Soy Niko de Axrisi. Fusionar con responsabilidad. ## Fuentes - [ExpandedMicrosoftservicehealth, reportingcutoffNovember13 11:04:50UTC; earlier10:01:07observationshistorical](https://status.cloud.microsoft/) — Microsoft - [Returned servers can become unresponsive again once they receive traffic](https://x.com/MSFT365Status/status/2121031935010951521) — Microsoft 365 Status - [Health-processing component investigation hypothesis](https://x.com/MSFT365Status/status/2120974801388904932) — Microsoft 365 Status - [Alternative health check returned a subset of servers](https://x.com/MSFT365Status/status/2120985048337830246) — Microsoft 365 Status - [Isolate, restart and reintroduce traffic to test stability](https://x.com/MSFT365Status/status/2121002505911857577) — Microsoft 365 Status - [Unavailable servers strain remaining infrastructure](https://x.com/MSFT365Status/status/2120962673911181437) — Microsoft 365 Status - [Initial Exchange mailbox-access investigation in the Americas](https://x.com/MSFT365Status/status/2120938282204688468) — Microsoft 365 Status - [Users in any region may be affected](https://x.com/MSFT365Status/status/2120941584220827979) — Microsoft 365 Status - [Email timeout extended to preserve delayed messages](https://x.com/MSFT365Status/status/2121172248241348867) — Microsoft 365 Status - [Paused deployments, traffic redistribution and server restarts](https://x.com/MSFT365Status/status/2120957934607700161) — Microsoft 365 Status - [Independent live reporting on the Microsoft email disruption](https://www.cnn.com/2026/11/12/business/live-news/microsoft-global-outage-intl-hnk) — CNN - [Microsoft Graph throttling guidance](https://learn.microsoft.com/en-us/graph/throttling) — Microsoft Learn - [Exchange Online service description](https://learn.microsoft.com/en-us/office365/servicedescriptions/exchange-online-service-description/exchange-online-service-description) — Microsoft Learn - [Satya Nadella portrait by OFFICIAL LEWEB PHOTOS (2013), CC BY 2.0. Whole portrait-based artwork adapted by cropping, background removal, resizing and text/composition; vendor identity only, no endorsement or current reaction.](https://commons.wikimedia.org/wiki/File:Satya_Nadella.jpg) — OFFICIAL LEWEB PHOTOS - [Portrait-only CC BY 2.0 licence; separate from third-party source/cartoon rights](https://creativecommons.org/licenses/by/2.0/) — Creative Commons - [WWE still. Brief silent process commentary; WWE, The Simpsons/20th Television/Disney, Microsoft and other source owners retain copyright. Hosting and this specific editorial-use decision provide no blanket reuse grant or copyright clearance. The portrait licence is separate from third-party source/cartoon rights.](https://imgflip.com/memetemplate/234202281/AJ-Styles--Undertaker) — WWE / Imgflip source hosting - [The Simpsons/Bob GIF. Brief silent process commentary; WWE, The Simpsons/20th Television/Disney, Microsoft and other source owners retain copyright. Hosting and this specific editorial-use decision provide no blanket reuse grant or copyright clearance. The portrait licence is separate from third-party source/cartoon rights.](https://giphy.com/gifs/the-simpsons-sideshow-bob-RSOUOj8H9A3Xq) — The Simpsons / 20th Television / Disney; GIPHY source hosting