Azure OpenAI is taking a lot of time and timeouts to answer on Foundry agent

Hola Luis Garcia

El 27 de enero de 2026, Microsoft confirmó oficialmente un incidente a nivel de plataforma que afectó a Azure OpenAI Service, comenzando a las 09:22 UTC y resuelto a las 16:12 UTC, impactando principalmente a la región de Suecia Central. Los clientes experimentaron latencia severa, tiempos de espera agotados para las solicitudes, errores HTTP 500/503, fallos en las llamadas de inferencia y problemas con los metadatos de implementación. No se trató de un problema de aplicación o configuración, sino de un fallo del servicio de backend a nivel de la plataforma Azure OpenAI.

Causa raíz (explicación oficial):

La revisión del incidente realizada por Microsoft indicó que la interrupción fue causada por fallos en un servicio de backend dependiente, específicamente en el Administrador de Recursos Internos (IRM). El problema provocó que los pods fallaran con errores de falta de memoria (OOM), lo que causó fallos en cascada en toda la infraestructura de Azure OpenAI. Esto degradó directamente la autorización y el procesamiento de las solicitudes, lo que resultó en una lentitud extrema y tiempos de espera agotados en lugar de fallos completos.

Los agentes de Azure AI Foundry estaban lentos o con tiempos de espera agotados:

Los agentes de Azure AI Foundry dependen internamente de los puntos finales de inferencia de Azure OpenAI. Debido a esta dependencia, el problema de la plataforma se propagó, lo que provocó que los agentes de Foundry se bloquearan, respondieran muy lentamente o agotaran el tiempo de espera. Varios hilos de Microsoft Q&A confirman que, aunque el incidente de Azure OpenAI se marcó como "resuelto", los agentes de Foundry continuaron mostrando un comportamiento degradado, incluyendo largos tiempos de espera y éxito intermitente.

Discrepancia en los paneles de estado (aclaración importante):

Durante y después del incidente, los clientes observaron que los paneles de estado de Azure y Microsoft Foundry mostraban un estado "verde" o de funcionamiento normal, incluso cuando las solicitudes agotaban el tiempo de espera. Los moderadores de Microsoft señalaron explícitamente que la página de estado de Foundry aún está en versión preliminar y no refleja degradaciones parciales ni problemas de backend específicos del inquilino, lo que explica la discrepancia entre el estado del panel y el comportamiento real.

Comportamiento posterior al incidente (por qué persistieron los problemas):

Después de la hora de resolución oficial, los clientes continuaron informando de respuestas lentas en lugar de fallos completos. Esto concuerda con la explicación de Microsoft de que la mitigación implicó la estabilización del tráfico, el escalado y el aumento de la memoria, lo que puede dejar los clústeres operativos pero aún bajo presión de recuperación. En tales estados, los reintentos de autorización y la limitación del backend pueden causar largos tiempos de espera y tiempos de espera agotados a nivel de agente.

Estado actual (a principios de febrero de 2026):

A principios de febrero de 2026, no hay ninguna nueva interrupción de Azure OpenAI declarada a nivel mundial, y el incidente del 27 de enero está oficialmente cerrado. Sin embargo, los monitores de interrupciones independientes y los informes de los usuarios muestran un rendimiento lento intermitente y tiempos de espera agotados en varias regiones, incluidas Europa e India, lo que indica una presión de capacidad residual o localizada en lugar de un nuevo incidente declarado.

Los tiempos de espera prolongados que observó con los agentes de Azure AI Foundry alrededor del 27 de enero fueron causados ​​por un incidente real en la plataforma Azure OpenAI, no por su código, la lógica del agente ni la configuración. El impacto fue más notorio en los agentes de Foundry porque se basan en las capas de inferencia y orquestación de OpenAI, lo que amplificó la latencia durante la inestabilidad del sistema.

¡Gracias!