# La recuperación de Outlook de Microsoft seguía fallando bajo tráfico Published: 2026-11-13 La interrupción del correo electrónico de Microsoft del 12 al 13 de noviembre expuso un bucle de recuperación: los servidores restaurados podían volverse a quedar sin respuesta 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 los problemas intermitentes y el trabajo en otros lugares persistían. Este seguimiento explica las dependencias y las salvaguardias del correo retrasado. Canonical: https://thedailydiff.dev/es/video/2026-11-13-microsoft-recovery-loop/ ## Qué cubre este vídeo - 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 permanecieron funcionales, mientras que las funciones dependientes de Exchange se vieron afectadas. - Microsoft informó que los servidores restaurados podían volverse a quedar sin respuesta cuando el tráfico llegaba a ellos; su explicación del componente de procesamiento de estado seguía siendo una hipótesis. - El tiempo de espera de correo electrónico extendido de cuarenta y ocho horas tenía como objetivo preservar el correo retrasado durante el procesamiento de la cola y la acumulación. No era un plazo de reparación ni una garantía de entrega universal. - La guía ordinaria de limitación de Graph recomienda respetar Retry-After y la retirada 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 fallar de nuevo bajo tráfico? Microsoft informó que los servidores restaurados podían volverse a quedar sin respuesta una vez que recibían tráfico. Su investigación describió procesos abrumados y un posible problema en un componente que procesa el estado del servidor, pero el desencadenante 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 las funciones de calendario fallaban? La mayoría de las llamadas, reuniones y chats principales de Teams permanecieron funcionales según el aviso de estado de 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 permaneció 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 fallo. ### ¿El tiempo de espera de correo electrónico de cuarenta y ocho horas estableció un plazo de reparación? Microsoft extendió la ventana de tiempo de espera del correo electrónico para preservar los mensajes retrasados mientras priorizaba la cola y el procesamiento de la acumulación. 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 ninguna garantía de que cada mensaje llegaría a su destinatario. Una notificación pendiente o en cola, por lo tanto, requería una entrega real o una verificación de resultado 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 expirar 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 de limitación ordinaria separada de Microsoft discute el respeto a Retry-After y la retirada exponencial cuando ese encabezado está ausente; esas políticas no establecen la causa de este incidente ni prometen un servicio restaurado. ### ¿Cuál fue el veredicto de The Daily Diff sobre la recuperación de Microsoft? El veredicto de The Daily Diff fue NECESITA REVISIÓN. Niko mantuvo la recuperación bajo revisión porque las actualizaciones de Microsoft describían que los servidores restaurados fallaban bajo tráfico. El servicio sostenido con trabajo real llegando era la prueba útil de recuperación. La causa inicial permaneció abierta en la fecha límite 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 la fecha límite del informe? - 3:17 ¿Por qué podría fallar una solicitud de Graph? - 4:05 ¿Qué se consigue con la ventana de correo de 48 horas? - 4:48 ¿Qué necesitaría probar una recuperación sostenida? ## Transcripción traducida Traducido de la narración original en inglés. El audio y los subtítulos disponibles están controlados por YouTube. ### ¿Por qué volvieron a fallar los servidores restaurados? 0:00 Microsoft volvió a poner en servicio los servidores de correo. Podrían dejar de responder de nuevo cuando el tráfico regresara. Aquí está el seguimiento para desarrolladores. En este vídeo, ¿por qué la recuperación seguía fallando? ¿Y qué partes de tu aplicación seguían funcionando? Microsoft también dio cuarenta y ocho horas al correo electrónico retrasado. ¿Qué consigues realmente con eso? Es viernes, trece de noviembre, y esto es The Daily Diff. 0:18 Exchange Online es el servicio de correo electrónico alojado de Microsoft, y otras funciones de Microsoft 3 ### ¿Qué características dependían de Exchange? 0:22 65 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 buzón podían fallar. Verifique la dependencia que realmente usa su aplicación. Eso significa que una reunión aún puede ocurrir 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 dice muy poco sobre qué backend necesita su próximo clic. La interrupción comenzó el jueves, con Microsoft investigando inicialmente el acceso al buzón 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 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 de repente una pasión por enviar correos electrónicos. La compañía luego investigó las comprobaciones de estado automatizadas. Estas comprobaciones ayudan a decidir si un servidor puede realizar un 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 se quedaron inicialmente no disponibles. Las actualizaciones se leen como un turno de guardia cada vez ### ¿Qué intentó Microsoft primero? 1:37 menos interesado en el desayuno. Pausar implementaciones. Mover tráfico. Reiniciar servidores. Microsoft validó una comprobación de estado alternativa que restauró 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 la capacidad. Luego vino la línea que explica el bucle de recuperación. Microsoft dijo que los servidores que volvieron a estar en servicio podrían volverse a quedar sin respuesta una vez que recibieran 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 la teoría segura de cualquiera en las respuestas. Imagine el mismo servidor a través de esos estados. No disponible. Vuelto a poner en servicio. Tomando tráfico. Inoperante 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 permanece sin resolver. El consejo de apagarlo y volver a encenderlo empieza a cobrar horas extras. Los ingenieros tienen que comprobar qué sucede después de que el trabajo regresa. Los clientes necesitan que el servicio siga funcionando a través de 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 permanecerían receptivos. Esos fueron experimentos de mitigación reportados. Pausar las implementaciones durante la recuperación no nos da ninguna evidencia de que una implementación del viernes causara la interrupción original. ### ¿Qué se sabía en la fecha límite del informe? 2:48 Según la actualización del viernes de Microsoft a las once y cuatro UTC, las acciones de recuperación habían terminado en partes de Asia-Pacífico. El tráfico regresaba gradualmente, con mejoras en el acceso al buzón y el procesamiento de correos electrónicos retrasados. Algunos usuarios aún podrían enfrentar problemas intermitentes, y la recuperación en otros lugares continuó. 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 Esperaría ese informe antes de asignar un villano. El trabajo de detective en Internet puede darte un culpable 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 expirar. Su aplicación puede llamar a Graph con éxito para una operación y fallar en otra. Una solicitud exitosa no relacionada le dice poco sobre si la operación de buzón que necesita su usuario se completará. La página de estado incluso necesitaba su propia vía 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 panel para averiguar qué está roto depende de lo que está roto, 3:46 el panel se ha unido al incidente. Mantenga disponible un enlace de estado fuera de banda. Para la limitación de Graph ordinaria, la guía de Microsoft dice que se debe respetar el retraso de reintento cuando una solicitud obtiene una respuesta de demasiadas solicitudes, y usar una retirada exponencial cuando ese encabezado esté ausente. Esa guía gestiona la limitación. No diagnostica esta interrupción ni promete que los reintentos restaurarán el servicio. Ahora las cuarenta y ocho horas. ### ¿Qué se consigue con la ventana de correo de 48 horas? 4:05 La página de estado ampliada de Microsoft dice que priorizó la cola y el procesamiento de la acumulación y extendió la ventana de tiempo de espera del correo electrónico para preservar los mensajes retrasados. Eso da más tiempo al correo retrasado durante la recuperación. Establece una ventana de tiempo de espera del correo. Microsoft no dio un plazo de cuarenta y ocho horas para arreglar el servicio, y ninguna garantía de que cada mensaje llegaría. 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 que leer en el eventual informe del incidente. Si prefiere leer esto en lugar de escucharme decirlo, el "diff" llega a su bandeja de entrada todas las mañanas, gratis en the daily diff dot dev, enlace a continuación. Así que el veredicto de hoy, NECESITA REVISIÓN. ### ¿Qué necesitaría probar una recuperación sostenida? 4:49 Mantendría la recuperación bajo revisión porque las propias actualizaciones de Microsoft mostraron que los servidores restaurados fallaban bajo tráfico. La prueba útil es el servicio sostenido con trabajo real llegando. Hasta el informe final, la causa inicial permanece abierta. Y ese es el "diff" de hoy. Soy Niko de Axrisi. Fusionar responsablemente. ## 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