Azure OpenAI Service, Foundry Agent Service, Foundry Models, and Azure AI services – Intermittent request failures and latency in Sweden Central

Update timeline

1. monitoring Sep 29, 2026, 10:00 AM UTC

   We are investigating an issue affecting Azure OpenAI and Foundry agent services in the Sweden Central region. Impacted customers may experience intermittent errors when making service requests. We are investigating the underlying issue and exploring mitigation options to restore normal service performance. Our analysis remains ongoing, and we are closely monitoring service health while continuing our investigation. We will provide additional information as it becomes available.

2. monitoring Sep 29, 2026, 10:00 AM UTC

   We are investigating an issue affecting Azure OpenAI Service, Azure AI Foundry Agent Service, Azure AI Foundry Models, and Azure AI Cognitive Services in the Sweden Central region. Impacted customers may experience intermittent request failures, increased latency and HTTP 5XX error codes when making service requests. We are investigating the underlying issue and exploring mitigation options to restore normal service performance. Our analysis remains ongoing, and we are closely monitoring service health while continuing our investigation. We will provide additional information as it becomes available.

3. monitoring Sep 29, 2026, 10:00 AM UTC

   Impact Statement: Starting at 10:00 UTC on 29 September 2026, a subset of customers using OpenAI Service, Foundry Agent Service, Foundry Models, and Cognitive Services, in Sweden Central may experience intermittent request failures, increased latency, and HTTP 5XX error codes when submitting requests to affected models and APIs hosted in this region. Current Status: Currently we are monitoring improvements in the overall experience. Initial findings indicate that a backend service which is relied on to retrieve metadata information when managing requests for this region, was experiencing timeouts when reading from dependent database and caching layers. As a result, requests that depend on these processes were delayed or failed intermittently. Queued requests are being processed. We are continuing to investigate the health of supporting platform infrastructure or system processes that may impact these requests. The next update will be provided within 60 minutes, or as events warrant.

4. postmortem Sep 29, 2026, 03:58 PM UTC

   Join either of our upcoming 'Azure Incident Retrospective' livestreams discussing this incident (to hear from our engineering leaders, and to get any questions answered by our experts) or watch a recording of the livestream (available the following week, on YouTube): • Option #1 - 17:30 to 18:00 UTC on 22 October 2026 - https://aka.ms/air/7QL5-Z50/1 • Option #2 - 05:30 to 06:00 UTC on 23 October 2026 - https://aka.ms/air/7QL5-Z50/2 What happened? Between 10:03 UTC and 15:58 UTC on 29 September 2026, a platform issue resulted in impact to Azure OpenAI Service, Foundry Agent Service, Foundry Models, and Azure AI services in the Sweden Central region. Impacted customers experienced intermittent request failures, increased latency, and/or HTTP 500 and 503 errors when submitting requests to affected models and data plane APIs hosted in this region. Note that the Azure OpenAI Service processes customer requests through model engines deployed across multiple Azure regions and supported by traffic routing systems. Depending on the selected deployment model (Global, Data Zone, or Regional), note that requests may be routed across multiple Azure regions within defined geographic boundaries to support availability and resilience, while customer data remains stored at rest in the selected Azure region. Learn more at: https://azure.microsoft.com/blog/enterprise-trust-in-azure-openai-service-strengthened-with-data-zones/ What went wrong and why? When requests are made to Azure OpenAI Service and related Azure AI services in a region, the service relies on a regional backend service to retrieve resource metadata and configuration information for the account making the request. This backend service reads from a caching layer and a database layer. Other internal services that call this backend service maintain their own caches of this information, to reduce load on the backend service. At approximately 09:38 UTC on 29 September 2026, a planned deployment of one of these internal services began in Sweden Central. As part of this deployment, the internal service's caches were cleared and - because the deployment coincided with peak traffic hours in the region - this produced a large number of cache misses, where requests were made for information no longer stored in the cache. Two other defects in how that service read from its caches amplified this effect, causing most lookups to bypass the cache and fall back to calling the backend service directly. By approximately 10:00 UTC, traffic to the backend service had increased to approximately 20 times its normal level. This surge drove a sharp increase in requests from the backend service to its caching layer, which reached full utilization, thereby increasing latency. This higher latency caused connections to be held open longer, while client retries added further requests. As a result, the network connection capacity on the infrastructure node instances was exhausted, so new outbound connections to both the caching layer and the database layer could not be established. While this traffic surge was a trigger, the extended duration of the incident was primarily caused by how the backend service determined whether its instances were healthy. Automated health checks for each instance depended on successfully connecting to the database layer. When instances could not establish new outbound connections, they failed this health check and were automatically restarted by design. As more instances entered this restart loop, fewer healthy instances remained to serve requests, and retries from dependent services further increased the load on the remaining instances. Multiple factors also extended the duration of the incident. Existing network metrics and diagnostic metrics did not effectively indicate the connection exhaustion issue in this scenario. It took an extended amount of time to correlate the failures with what was causing this specific connection exhaustion scenario. As a result, different mitigation attempts - including scaling the number of service instances, and increasing compute and memory resources - could not resolve the incident, until the health check issue was identified and mitigated. How did we respond? • 09:38 UTC on 29 September 2026 – A deployment of an internal service in Sweden Central began, which cleared its caches. • 10:00 UTC on 29 September 2026 – Traffic to the backend service began increasing sharply. • 10:03 UTC on 29 September 2026 – Customer impact began because of service instance instability. • 10:17 UTC on 29 September 2026 – Service monitoring detected elevated failure rates for Azure OpenAI Service requests in the region, and alerted our engineering teams. • 10:28 UTC on 29 September 2026 – Engineers were engaged and investigating the issue. • 11:21 UTC on 29 September 2026 – Additional engineering teams were engaged, ongoing deployments were reviewed for the Azure OpenAI Service in Sweden Central to determine whether any recent change correlated with the issue. • 11:30 UTC on 29 September 2026 – We identified that infrastructure node service instances were experiencing timeouts when attempting to connect to the backend service's caching and database layers. • 13:55 UTC on 29 September 2026 – We confirmed that the database layer was healthy. We made attempts to mitigate through different scaling adjustments of service instances to lower the number of outbound connections, which did not result in significant improvements. • 15:00 UTC on 29 September 2026 – We further increased compute resources for the backend service and increased its resource limits. In parallel, we investigated infrastructure health for affected service instances and restarted service instances. • 15:40 UTC on 29 September 2026 – We reconfigured the automated health check to no longer depend on remote connectivity, which stopped the restart loop. Service availability began to recover. • 15:58 UTC on 29 September 2026 – Service availability had recovered, and customer impact was mitigated. • 16:30 UTC on 29 September 2026 – We identified the source of the increased traffic and correlated it with the internal service deployment, while monitoring confirmed that services were stable. How are we making incidents like this less likely or less impactful? • We have reconfigured the automated health check for the backend service so that it no longer depends on connectivity to its database layer, preventing instances from being restarted unnecessarily during dependency issues. (Completed) • We have added monitoring and alerting on the load and latency of the caching layer used by the backend service. (Completed) • We have updated our troubleshooting and procedural guidance for such connection exhaustion scenarios, to assist on-call engineers in mitigating similar scenarios. (Completed) • We are adding additional throttling and rate limiting for the backend service, to protect it from sudden increases in traffic. (Estimated completion: October 2026) • We are increasing the resource capacity of the caching layer used by the backend service across regions. (Estimated completion: October 2026) • We are improving diagnostic metrics and automated detection, to help identify such issues more quickly. (Estimated completion: October 2026) • In the longer term, we are partitioning the caching layer used by the backend service to increase its throughput. (Estimated completion: December 2026) How can customers make incidents like this less impactful? • Consider reviewing our guidance and best practices related to Business Continuity and Disaster Recovery (BCDR) scenarios for Microsoft Foundry: https://learn.microsoft.com/azure/foundry/how-to/high-availability-resiliency • Consider reviewing and implementing our best practices surrounding retry patterns, especially with exponential backoff, to improve workload resiliency during intermittent issues: https://learn.microsoft.com/azure/architecture/patterns/retry • More generally, consider evaluating the reliability of your applications using guidance from the Azure Well-Architected Framework and its interactive Well-Architected Review: https://aka.ms/AzPIR/WAF • The impact times above represent the full incident duration, so are not specific to any individual customer. Actual impact to service availability varied between customers and resources – for guidance on implementing monitoring to understand granular impact: https://aka.ms/AzPIR/Monitoring • Finally, consider ensuring that the right people in your organization will be notified about any future service issues – by configuring Azure Service Health alerts. These can trigger emails, SMS, push notifications, webhooks, and more: https://aka.ms/AzPIR/Alerts How can we make our incident communications more useful? You can rate this PIR and provide any feedback using our quick 3-question survey: https://aka.ms/AzPIR/7QL5-Z50