Microsoft Outage History

Started Jun 21, 2026, 08:03 AM UTC· resolved Jun 23, 2026, 09:00 AM UTC

1. monitoring Jun 23, 2026, 04:10 AM UTC

   Current status: We've identified a problem that may be preventing some admins from viewing the Microsoft 365, operated by 21Vianet, Service Health Dashboard (SHD) and/or Message Center (MC). We’re working to restore access to the SHD and MC, and we'll provide more information when we’ve isolated the root cause. Next update by: Tuesday, June 23, 2026, at 7:00 AM UTC

2. monitoring Jun 23, 2026, 06:41 AM UTC

   User impact: Admins may not be able to view Service Health Dashboard (SHD) and Message Center (MC) posts in the Microsoft 365 admin center operated by 21Vianet. Current status: We're reviewing contextual details provided by impacted users together with service logs to pinpoint the underlying root cause of impact and determine a strategy to restore access. Next update by: Tuesday, June 23, 2026, at 9:00 AM UTC

3. monitoring Jun 23, 2026, 07:29 AM UTC

   User impact: Admins may not been able to view SHD and Message Center posts in the Microsoft 365 admin center operated by 21Vianet. Final Status: After a period of monitoring, we confirmed that the impacted infrastructure self-restored, and service returned to expected performance levels. We closely monitored the service to ensure that it remained healthy. Scope of impact: Any admin might have been impacted and might not have been able to view SHD and Message Center posts in the Microsoft 365 admin center operated by 21Vianet. This section could have been updated as the investigation continued. Start time: Sunday, June 21, 2026, at 8:03 AM UTC End time: Tuesday, June 23, 2026, at 7:17 AM UTC Root cause: A portion of the infrastructure performed suboptimally, resulting in impact. Next steps: - We're analyzing performance data and trends on the affected infrastructure to help prevent this problem from happening again. This is the final update for the event.

4. monitoring Jun 23, 2026, 08:17 AM UTC

   User impact: Admins may not have been able to view Service Health Dashboard (SHD) and Message Center posts in the admin center. Final Status: While we were in the process of attempting to redeploy our service resources to the affected section of infrastructure, system monitoring indicated that the service had returned to normal health. We've confirmed that the problem is no longer occurring, and we'll continue to monitor the service to ensure that the problem does not happen again. Scope of impact: Impact was specific to any admin attempting to view SHD and Message Center posts in the Microsoft 365 admin center operated by 21Vianet. Start time: Sunday, June 21, 2026, at 8:03 AM UTC End time: Tuesday, June 23, 2026, at 6:30 AM UTC Root cause: A section of infrastructure that facilitates access to SHD and Message Center posts in the Microsoft 365 admin center operated by 21Vianet performed suboptimally, resulting in impact Next steps: - We're analyzing performance data and trends on the affected infrastructure to help prevent this problem from happening again. This is the final update for this event.

Read the full incident report →

Started Jun 15, 2026, 11:44 PM UTC· resolved Jun 16, 2026, 12:10 AM UTC

1. monitoring Jun 15, 2026, 11:44 PM UTC

   Impact Statement: Starting at 21:45 UTC on 15 June 2026, a subset of Azure customers leveraging services which depend upon MCR (Microsoft Container Registry) for storing images may experience 401 authentication errors for requests attempting to pull Microsoft images from mcr.microsoft.com.Current Status: We detected this issue via internal service monitoring upon identifying a spike of 401 errors. We’ve identified a potential underlying factor to be a recent update which introduced a code regression, and we've completed roll out of a hotfix to address the code regression and mitigate impact for affected customers. We are closely monitoring internal telemetry to validate full mitigation and prevent further occurrences. The next update will be provided within 60 minutes, or as events warrant.

2. resolved Jun 16, 2026, 12:01 AM UTC

   What happened?Between 21:45 UTC and 23:23 UTC on 15 June 2026, Azure customers leveraging services which depend upon Microsoft Artifact Registry (MAR) may have experienced 401 authentication errors when attempting to pull images from MAR . This incident is now mitigated. Further details will be provided directly to impacted customers through the Azure Portal.

Read the full incident report →

Started Jun 15, 2026, 11:04 PM UTC· resolved Jun 15, 2026, 11:50 PM UTC

1. monitoring Jun 15, 2026, 11:04 PM UTC

   We are actively investigating customer alerts of 401 authentication errors when pulling images from mcr.microsoft.com. We’ve identified a potential underlying factor related to a recent update made to a backed service and we are actively working on determining mitigation workstreams. More information will be provided shortly.

Read the full incident report →

Started Jun 11, 2026, 08:00 PM UTC· resolved Jun 11, 2026, 10:02 PM UTC

1. monitoring Jun 11, 2026, 09:23 PM UTC

   More info: As a workaround, admins may be able to access the Microsoft 365 admin center via admin.cloud.microsoft as a temporary solution. Start time: Thursday, June 11, 2026, at 8:00 PM UTC Current status: This is a continuation of a communication posted under CW1387674. We’ve identified an issue with a recent deployment for Microsoft Copilot. We’re reverting to a previous build to remediate impact as soon as possible. We expect this to be completed in the next 30 minutes. Next update by: Thursday, June 11, 2026, at 10:00 PM UTC

2. monitoring Jun 11, 2026, 09:29 PM UTC

   User impact: Users are unable to access Microsoft 365 Copilot Chat or portal.office.com. More info: Admins may be able to access the Microsoft 365 admin center via admin.cloud.microsoft as a temporary solution. Additionally, Copilot in Microsoft Teams is not expected to be impacted and can be leveraged in the interim while we mitigate the issue. Current status: This is a continuation of a communication posted under CW1387674. We’ve identified an issue with a recent deployment for Microsoft Copilot. We’re reverting to a previous build to remediate impact as soon as possible. We expect this to be completed in the next 30 minutes. Scope of impact: Our investigation indicates that any user or admin may be affected by this event. This section is subject to change as the investigation continues. Start time: Thursday, June 11, 2026, at 8:00 PM UTC Estimated time to resolve: We expect the reversion to be complete in the next 30 minutes. Root cause: The root cause is still being investigated. We will provide more information in our next update. Next update by: Thursday, June 11, 2026, at 10:00 PM UTC

Read the full incident report →

Started Jun 01, 2026, 03:18 PM UTC· resolved Jun 02, 2026, 05:42 PM UTC

1. monitoring Jun 01, 2026, 03:18 PM UTC

   User impact: We don't have details on impact yet. We're seeing an increase in user reported issues above our alerting threshold. Current status: We are reviewing service telemetry and available information to determine if there is an issue happening and we'll update this message shortly with our latest findings. This communication serves as a preliminary notification about a potential issue affecting your service.

Read the full incident report →

Started Jun 01, 2026, 01:55 PM UTC· resolved Jun 01, 2026, 05:35 PM UTC

1. monitoring Jun 01, 2026, 03:53 PM UTC

   User impact: Users may be unable to access the Microsoft Copilot desktop or web app. Current status: We’re reviewing our telemetry to determine the specific impact and isolate the root cause. Next update by: Monday, June 01, 2026, at 5:00 PM UTC

2. monitoring Jun 01, 2026, 04:33 PM UTC

   User impact: Users may be unable to access the Copilot desktop or web app. Current status: We're working on getting logs from impacted users to focus our investigative efforts to isolate the source of impact. Start time: Monday, June 01, 2026, at 1:55 PM UTC Next update by: Monday, June 01, 2026, at 5:00 PM UTC

3. monitoring Jun 01, 2026, 04:46 PM UTC

   User impact: Users may be unable to access the Copilot desktop or web app. Current status: We've received logs from impacted users and are reviewing them to identify the root cause. We're also continuing to monitor our telemetry to determine mitigating actions we can implement in the interim as our investigation progresses. Start time: Monday, June 01, 2026, at 1:55 PM UTC Next update by: Monday, June 01, 2026, at 6:00 PM UTC

4. monitoring Jun 01, 2026, 05:30 PM UTC

   User impact: Users may be unable to access the Copilot desktop or web app. Current status: We identified a routing issue which is sending Copilot traffic to a portion of infrastructure that is unhealthy, resulting in the access and timeout errors. We're rerouting requests to healthy infrastructure and our telemetry is starting to show service health recovery. Start time: Monday, June 01, 2026, at 1:55 PM UTC Next update by: Monday, June 01, 2026, at 6:00 PM UTC

5. resolved Jun 01, 2026, 05:55 PM UTC

   User impact: Users may have been unable to access the Copilot desktop or web app. Final status: We've rerouted requests to healthy infrastructure and have confirmed through our telemetry that service health has recovered. Start time: Monday, June 01, 2026, at 1:55 PM UTC End time: Monday, June 01, 2026, at 5:52 PM UTC

Read the full incident report →

Started May 29, 2026, 02:30 PM UTC· resolved May 29, 2026, 05:35 PM UTC

1. monitoring May 29, 2026, 03:50 PM UTC

   User impact: Users may be unable to use Microsoft Copilot. Current status: We're reviewing service telemetry to isolate the source of the issue. Next update by: Friday, May 29, 2026, at 5:30 PM UTC

2. monitoring May 29, 2026, 05:01 PM UTC

   User impact: Users may be unable to use Microsoft Copilot. Current status: We've identified high utilization on the underlying infrastructure that the Copilot LLM APIs use and are applying mitigations. Additionally, at the Copilot service level, we're reviewing options to change routing paths, throttling rules and retry logic to allow the underlying infrastructure to recover. Next update by: Friday, May 29, 2026, at 6:30 PM UTC

3. resolved May 29, 2026, 07:01 PM UTC

   User impact: Users were unable to use Microsoft Copilot. Final status: The underlying infrastructure that the Copilot LLM APIs use has recovered after the mitigation actions were applied. We monitored the environment for an extended period of time and have validated that service has been restored. Start time: Friday, May 29, 2026, at 2:30 PM UTC End time: Friday, May 29, 2026, at 5:35 PM UTC This is the final update for this event.

Read the full incident report →

Started May 29, 2026, 09:39 AM UTC· resolved May 29, 2026, 12:58 PM UTC

1. monitoring May 29, 2026, 09:39 AM UTC

   Impact Statement: Starting at 09:39 UTC on 29 May 2026, you have been identified as a subset of customers using Azure OpenAI service in multiple regions who may experience degraded request success where some requests returned errors or failed to complete. Current Status: We identified this issue through internal automated service monitoring after detecting a drop in call success rates. Our investigation indicates that the issue is linked to elevated server-side errors within a backend service layer in the affected region. We are actively investigating and working to determine the full scope and mitigation steps. The next update will be provided within 60 minutes, or sooner if there are significant developments.

2. postmortem May 29, 2026, 05:05 PM UTC

   Watch our 'Azure Incident Retrospective' video about this incident: https://aka.ms/air/LYXT-C1Z What happened? Between 09:39 UTC and 17:05 UTC on 29 May 2026, customers using the Azure OpenAI Service may have experienced increased latency, intermittent request failures, timeouts, and/or HTTP 5XX errors when submitting inference requests. The impact was more pronounced in regions in Europe and Australia East that were directly processing the highest levels of affected traffic. The incident was triggered by an upstream change that altered how certain capacity-related failures were surfaced, which led to a rapid and unexpected increase in internal retry traffic. This retry amplification overwhelmed a shared inference load balancer component, which distributes the inference traffic, degrading service reliability across multiple regions. What went wrong and why? Azure OpenAI relies on an internal routing and load balancing layer to direct inference requests across regions and model capacity. This layer is designed to distribute traffic efficiently and support resiliency during transient failures. During this incident, that layer became overloaded and unstable after it was subjected to a large volume of retry traffic from an upstream internal workload. The triggering condition was a change in an upstream API layer used by a Microsoft first-party workload, Microsoft 365, which relies on Azure OpenAI for some request processing scenarios, including Copilot-related experiences. This change altered how capacity-related failures were surfaced to higher layers in the request path. The rollout first occurred in Australia East, and later expanded to Sweden Central. Before this change, some lower-level capacity or resource exhaustion conditions could still result in retry activity, as designed - but after repeated failures, they would ultimately return in a form that did not trigger broad retry behavior across multiple upstream layers. After the change, those same conditions began surfacing as transient server failures instead. Because those responses were now interpreted as retriable, multiple layers in the calling stack retried immediately and repeatedly, without sufficient backoff or jitter. In some cases, a single failed request resulted in up to 48 additional retry attempts. This created a cascading retry amplification effect that dramatically increased internal traffic volume, even though underlying customer demand had not materially changed. The first wave of impact occurred in Australia East, where the change was initially deployed. As retry traffic increased, it began exhausting resources in the Azure OpenAI inference routing layer and triggered failures in the affected backend path. During that first wave, early crash signatures pointed to an internal feature associated with error handling, which appeared to be a plausible explanation for the instability. We disabled that feature as a potential mitigation, and around the same time traffic in Australia East naturally declined as part of the normal regional usage pattern. Because service health improved after those two things happened in close succession, it initially appeared that the mitigation had addressed the problem. In reality, the feature we disabled was not the underlying cause, and the retry amplification issue remained in place. When the upstream rollout later expanded to Sweden Central, the same failure pattern reappeared, but at much greater scale. As a major European processing hub, Sweden Central serves significantly higher traffic volume - so the retry amplification effect was stronger and the resulting overload was more severe. This second wave made it clear that the issue was not limited to the internal feature we had first suspected. Instead, it exposed the true underlying problem: a large internal retry storm overwhelming the shared routing layer. As the retry storm intensified, it exhausted resources in the Azure OpenAI inference routing layer. The affected component scaled out, but the magnitude of the retry amplification exceeded the protection available at the time. In a small number of regions, recovery was further constrained because scale-out options were limited by available compute quota for replacement virtual machine SKUs. The result was resource exhaustion, out-of-memory crashes on multiple instances, and broad degradation across the shared routing path. This incident also exposed a gap in how internal workloads were protected, relative to traffic from external sources. The affected upstream workload operated in a model where traffic was not subject to the same rate-limiting and overload controls used for many external scenarios. In addition, some of this traffic reached the internal routing layer more directly than standard external traffic paths. That meant the system did not sufficiently suppress or isolate the amplified retry volume before it reached shared infrastructure. While the initial impact in Australia East led us toward a credible but incomplete explanation, the apparent recovery after disabling the suspected feature obscured the real cause. Once the rollout reached Sweden Central and the issue reappeared, albeit at greater scale, we were able to definitively correlate the degradation to retry amplification, correctly diagnose the trigger condition as the change in the upstream dependency API layer, then execute the targeted mitigations that restored stability. How did we respond? • 09:20 UTC on 29 May 2026 – Initial customer impact began as the first wave of retry amplification, associated with the upstream rollout in Australia East, caused increased failures and latency across multiple regions. • 09:39 UTC on 29 May 2026 – Automated monitoring detected a drop in request success rates and initiated incident investigation. • 10:10 UTC on 29 May 2026 – We identified widespread service instability and correlated failures across regions and models. • 12:17 UTC on 29 May 2026 – Based on early crash diagnostics, we disabled a component that was suspected of contributing to the instability. • 12:40 UTC on 29 May 2026 – Service health began improving as traffic conditions in Australia East eased, which initially made the earlier mitigation appear effective. • 14:20 UTC on 29 May 2026 – The upstream rollout expanded to Sweden Central, where significantly higher traffic volume increased the impact of the retry amplification. • 14:40 UTC on 29 May 2026 – The issue reoccurred after the upstream rollout reached Sweden Central, where higher traffic volume magnified the retry amplification and overloaded the system at greater scale. • 16:20 UTC on 29 May 2026 – We identified that the earlier mitigation had addressed a secondary symptom rather than the underlying cause, and refocused the investigation on upstream retry behavior. • 16:27 UTC on 29 May 2026 – We confirmed that the amplified traffic was originating from an internal first-party workload and began targeted mitigation planning. • 16:30 UTC on 29 May 2026 – We identified the source of the amplified retry traffic, isolated the offending internal workload onto dedicated infrastructure, and coordinated with the upstream service to roll back the triggering change and reduce traffic volume. • 16:25 UTC on 29 May 2026 – The upstream service began rollback of the triggering change and took additional actions to reduce retry-driven traffic volume. • 17:05 UTC on 29 May 2026 – Following the completion of the isolation and rollback, and all backlogged requests were cleared, customer impact was confirmed as mitigated. How are we making incidents like this less likely or less impactful? • We are reducing shared infrastructure blast radius by moving large first-party generative AI workloads onto dedicated routing infrastructure, rather than allowing them to share the same inference load balancing stamp with broader multi-tenant traffic. (Estimated completion: June 2026) • We are improving our diagnostic guidance, runbooks, and alerting so that engineers can more quickly distinguish between secondary crash symptoms and the true underlying source of overload during fast-moving incidents. (Estimated completion: June 2026) • We are partnering with upstream service teams to improve retry policy design, dependency contracts, and telemetry so retry amplification conditions can be detected earlier and prevented from propagating across shared infrastructure. (Estimated completion: July 2026) • We are implementing stronger overload prevention and workload throttling controls so that excessive retry traffic from any single internal workload cannot overwhelm shared components. (Estimated completion: July 2026) • Finally, we are continuing work to identify and eliminate single points of failure and improve resiliency in the inference routing layer. (Perpetual/Ongoing) How can customers make incidents like this less impactful? • For mission-critical AI workloads, customers should consider a multi-region resiliency strategy so that service degradation affecting a specific processing path or region is less likely to impact the full application experience. Customers using regional deployments may wish to evaluate whether additional geographic diversity or fallback patterns would improve resilience for their scenarios. See: https://learn.microsoft.com/azure/ai-services/openai/how-to/business-continuity-disaster-recovery • Customers should also review application retry behavior to ensure that client-side retries use appropriate backoff and jitter, and that applications degrade gracefully when dependent services are under stress. Well-controlled retry behavior helps avoid compounding platform-level recovery events. See: https://learn.microsoft.com/azure/architecture/patterns/retry • 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/LYXT-C1Z

Read the full incident report →

Started May 29, 2026, 07:07 AM UTC· resolved May 29, 2026, 07:42 AM UTC

1. monitoring May 29, 2026, 06:57 AM UTC

   Impact Statement- Starting at 04:27 UTC on 29 May 2026, customers may experience increased latency, intermittent connectivity, or timeouts when accessing resources hosted in the West US 2 region. Engineers are actively investigating the issue and working to restore network stability. Some requests may succeed upon retry as connectivity intermittently recovers. We are sending targeted communications to impacted customers through the Azure Service Health dashboard. The next update will be provided within 60 minutes.

2. monitoring May 29, 2026, 07:07 AM UTC

   Impact Statement- Starting at 04:27 UTC on 29 May 2026, customers may experience increased latency, intermittent connectivity, or timeouts when accessing resources hosted in the West US 2 region, due to a power event. We are in process of recovering power and working to restore infrastructure in the region. We started seeing partial recovery and will be sending targeted communications to impacted customers through the Azure Service Health dashboard. The next update will be provided within 60 minutes.

Read the full incident report →

Started May 29, 2026, 04:24 AM UTC· resolved May 29, 2026, 09:45 PM UTC

1. monitoring May 29, 2026, 04:27 AM UTC

   Impact Statement: Starting at 04:27 UTC on 29 May 2026, we are investigating an incident which is impacting multiple services in West US 2, due to a power event. This impacts service accessibility in the region, with customers potentially experiencing increased latency and intermittent connectivity, including timeouts when connecting to resources. Current Status: We identified this issue through our automated monitoring after detecting elevated alerts related to network and infrastructure health in the West US 2 region. The issue was triggered by a power event in the datacenter, which impacted underlying infrastructure and led to increased latency and intermittent connectivity for select resources. We are aware of the impact and are actively investigating. Mitigation efforts are underway to restore affected network components across dependent services, including Storage and Compute. Customers may begin to see signs of recovery as these actions progress. The next update will be provided within 60 minutes, or sooner if there are significant developments.

2. monitoring May 29, 2026, 04:27 AM UTC

   Impact Statement: Starting at 04:27 UTC on 29 May 2026, a severe thunderstorm caused widespread utility power loss to our West US 2 datacenter facilities, resulting in a multi-service outage. Impact is currently region-wide, and we have not yet confirmed isolation to specific scale units or availability zones and are treating this as full-region impact until physical inspections confirm otherwise. Customers are experiencing service connectivity failures, timeouts, and elevated error rates across affected services. This includes an inability to deploy new resources or scale existing workloads, intermittent availability where some requests may succeed while others fail depending on which infrastructure nodes have recovered, and both data plane and control plane impact for services not yet restored. Affected Azure services include, but are not limited to:Azure Functions, Azure Database for MySQL Flexible Servers, Azure Database for PostgreSQL Flexible Server, Azure Databricks, Redis, Azure SQL, Azure Managed Grafana, Virtual Machines, Virtual Machine Scale Sets, Azure Kubernetes Service, Storage, Application Insights, Azure Data Factory, Azure Monitor, and Azure Log Analytics Current Status: Severe thunderstorms resulted to a complete utility power loss to multiple datacenter buildings simultaneously. Our backup generators activated but were unable to fully compensate. The generator transfer switchover was only partially successful, with some generator sets failing to synchronize under the sudden full facility load and others experiencing thermal protection shutdowns as ambient temperatures rose due to simultaneous cooling system failures. This cascading combination of power instability and cooling loss exceeded our designed N+1 redundancy for this failure mode. We are still determining the full extent of mechanical vs. electrical failures in the generator systems. HVAC systems are being restarted in sequence; ambient temperatures are returning to safe ranges but have not fully normalized, so we are staged-powering equipment to avoid thermal re-trips. Network devices and storage arrays are being power-cycled and validated in sequence, with storage dependencies as the primary remaining bottleneck due to required manual intervention and data integrity verification. Where possible, traffic is being redirected to healthy nodes, and on-site teams are conducting physical hardware inspections to identify components requiring replacement. The following services have been confirmed restored and are operating normally:Service Bus, App Service (Web Apps), Azure Site Recovery, Backup (MAB), Azure Cosmos DB, Azure Resource Manager, Data Explorer, Azure IoT Hub, Microsoft Defender for Cloud Apps, Azure Container Registry, Azure Policy, Azure NetApp Files, Azure Resource Graph, Azure Synapse Customer Guidance: • If you have resources in paired or alternate regions, consider failing over traffic away from West US 2 until we confirm full recovery. • Single-region workloads will recover automatically as infrastructure is restored — no customer action is required. • We recommend pausing new deployments to West US 2 until this incident is resolved; use alternate regions if urgent. • Monitor Azure Status (status.azure.com) and Service Health in the portal for real-time updates specific to your subscriptions. Next update: We will provide our next status update within 1 hour, or sooner, if events warrant.

3. monitoring May 29, 2026, 04:27 AM UTC

   Impact statement: Starting at 04:27 UTC on 29 May 2026, a severe thunderstorm caused widespread utility power loss across multiple West US 2 datacenter facilities, resulting in impact to multiple Azure services. Datacenter power has been fully restored, and the majority of network and storage infrastructure has recovered. Infrastructure in Availability Zone 2 has recovered and is operating normally. Residual impact is now concentrated on a subset of infrastructure within Availability Zones 1 and 3, where two storage stamps are undergoing final recovery and validation. Customers with resources deployed exclusively in Availability Zone 2 should not be affected by the remaining recovery activities; however, those with dependencies in Availability Zones 1 or 3 may continue to experience intermittent connectivity, elevated latency, or resource unavailability. Currently affected Azure services include, but may not be limited to (recovery validation underway):Azure Functions, Azure Database for MySQL Flexible Server, Azure Database for PostgreSQL Flexible Server, Azure SQL, Azure Managed Grafana, Virtual Machines, Virtual Machine Scale Sets, Azure Kubernetes Service, Azure Storage, Application Insights, Azure Monitor, and Azure Log Analytics.The following services have recovered and are operating normally:Service Bus, App Service (Web Apps), Azure Site Recovery, Backup (MAB), Azure Cosmos DB, Azure Resource Manager, Azure Data Explorer, Azure IoT Hub, Microsoft Defender for Cloud Apps, Azure Container Registry, Azure Policy, Azure NetApp Files, Azure Resource Graph, Azure Data Factory, Azure Databricks, Azure Cache for Redis, and Azure Synapse Analytics. Current Status: A severe weather event, including multiple lightning strikes, affected several datacenter facilities in the West US 2 region, resulting in concurrent utility power interruptions across multiple availability zones. Backup generators activated as designed; however, during the transition to sustained generator operation, a subset of generator systems were unable to fully synchronize under the sudden facility load, while others subsequently shut down due to thermal protection mechanisms as cooling systems were impacted by the broader power disruption. Because these events occurred across multiple facilities within the same timeframe, the resulting conditions exceeded the resiliency designed for this particular failure scenario. Datacenter utility power has been fully restored. HVAC systems have normalized, ambient temperatures have returned to expected operating ranges, and the majority of network and storage infrastructure has recovered successfully. While most services have returned to normal operation, a small subset of storage clusters and network devices did not recover cleanly and continue to limit full-service restoration. Some storage clusters remain partially unavailable or dependent on ongoing network recovery activities, and a limited number of network devices connecting compute resources to storage infrastructure remain impaired. As a result, some virtual machines are currently unable to access their underlying storage dependencies and may remain unavailable. Recovery efforts have transitioned from broad infrastructure restoration to targeted remediation of specific network devices, storage clusters, and isolated compute nodes. As these components are restored, validated, and returned to service, dependent workloads are recovering incrementally. Two storage stamps are currently completing final recovery and integrity validation activities, and services dependent on those stamps are expected to recover as this work is completed. Estimated Time to Resolution: With datacenter power restored and the majority of network and storage infrastructure recovered, remaining work is focused on two storage stamps completing final recovery and data integrity validation activities. Based on current progress, we estimate full-service restoration within approximately 2-3 hours. Individual services dependent on these stamps will recover progressively as validation activities are completed. Customer Guidance:Single-region workloads will recover automatically as infrastructure restoration activities are completed; no customer action is required.We recommend postponing new deployments into West US 2 until this incident is resolved and using alternate regions for urgent deployment needs.Logical availability zones assigned to customer subscriptions may map to different physical availability zones. Customers can use the Locations API to understand this mapping: https://learn.microsoft.com/rest/api/resources/subscriptions/list-locations?HTTP#availabilityzonemappings. Next Update: We will provide our next status update within 60 minutes, or sooner if significant progress is made.

4. postmortem May 30, 2026, 02:30 AM UTC

   Watch our 'Azure Incident Retrospective' video about this incident: https://aka.ms/air/GHRP-84G What happened? Between 04:24 UTC on 29 May and 02:30 UTC on 30 May 2026, customers with resources in the West US 2 region may have experienced failures when attempting to access or manage some Azure services in the region. Impact included connectivity failures, resource unavailability, and service management failures. The issue was triggered by a severe thunderstorm that caused utility power disturbances affecting multiple datacenter facilities serving the region. These disturbances led to some cooling systems entering a protective mode to preserve equipment integrity. This caused elevated temperatures which triggered proactive shutdowns of infrastructure affecting compute, networking, and storage systems across two different availability zones in the region (physical AZ-01 and AZ-03). After cooling systems stabilized, storage services - and the networking on which they depend - required extensive manual recovery actions, which contributed to the total duration of customer impact. The following services were among those affected: Application Insights, Azure App Service, Azure Backup, Azure Cache for Redis, Azure Container Registry, Azure Cosmos DB, Azure Databricks, Azure Data Explorer, Azure Data Factory, Azure Functions, Azure IoT Hub, Azure Kubernetes Service, Azure Monitor, Azure NetApp Files, Azure Resource Manager, Azure Site Recovery, Azure SQL Database, Azure Storage, Azure Synapse Analytics, Azure Virtual Machines, Log Analytics, Service Bus, and Virtual Machine Scale Sets. What went wrong and why? A severe thunderstorm produced lightning strikes, resulting in utility power disturbances across multiple datacenter facilities serving the West US 2 region. These disturbances affected a wide enough geographic area that a subset of datacenters within two Availability Zones experienced impact. While this event was not a complete utility power interruption, these datacenters experienced multiple voltage sag/swell events, meaning utility power remained present but was unstable. The region consists of datacenters built at different times with varying infrastructure designs, including differences in cooling control systems and power protection mechanisms. Some datacenters transferred to generator power, while others did not transfer, as the utility power source remained available even as voltage fluctuated. Independently of whether each datacenter transferred to backup power, a subset of components within the mechanical cooling systems - across multiple datacenters - detected abnormal electrical conditions and, by design, entered a 'lockout' protective state. This reduced cooling capability and prevented parts of the cooling system from automatically returning to normal operation after the power disturbance. As temperatures rose beyond safe operating thresholds, a subset of cloud infrastructure automatically shut down to prevent physical damage and preserve data integrity. Impacted cooling systems required manual intervention and troubleshooting, including multiple restart attempts before stable cooling capacity could be reestablished. Additionally, we had to identify which devices required manual recovery and which were expected to self-recover. Impacted Storage scale units required additional validation. These factors contributed to the extended recovery time for services dependent on storage, including telemetry processing systems. How did we respond? Recovery efforts began immediately, prioritizing cooling restoration, then network infrastructure, followed by compute and storage systems. Cooling was restored within approximately two hours of impact start. The majority of compute resources recovered within eight hours. Storage validation, which must be performed sequentially, extended over approximately 14 hours. Finally, telemetry services (Application Insights and Log Analytics) required an additional six hours beyond storage recovery to process accumulated backlogs. The timeline below details the progression of recovery: • 04:14 UTC on 29 May 2026 – Utility power sag/swells were observed across multiple datacenters. These caused a subset of the mechanical cooling systems to enter a 'lockout' protective state. • 04:24 UTC on 29 May 2026 – Customer impact began; our monitoring produced thermal alerts as temperatures rose due to reduced cooling functionality. • 04:31 UTC on 29 May 2026 – Manual cooling diagnosis and restoration efforts began. • 04:40 UTC on 29 May 2026 – As temperatures rose, some cloud infrastructure shut down to prevent damage. • 04:50 UTC on 29 May 2026 – Networking and Storage engineers began assessing infrastructure health and necessary restoration efforts. • 05:55 UTC on 29 May 2026 – All cooling was restored in impacted datacenters, and temperatures had stabilized. Assessments continued on remaining infrastructure issues. • 06:15 UTC on 29 May 2026 – Approximately 50% of impacted underlying Virtual Machines (VMs) had recovered. • 12:00 UTC on 29 May 2026 – Approximately 95% of impacted underlying Virtual Machines (VMs) had recovered, after premium Storage had been largely recovered. Compute and Storage teams continued to identify and mitigate remaining unhealthy nodes. • 18:46 UTC on 29 May 2026 – Storage was confirmed as the remaining recovery bottleneck; validation of Storage-specific issues was ongoing. • 20:18 UTC on 29 May 2026 – All affected services confirmed as recovered, except for Application Insights and Log Analytics which were still processing backlogs. • 02:30 UTC on 30 May 2026 – Customer impact for Log Analytics and Application Insights confirmed as mitigated. How are we making incidents like this less likely or less impactful? • First and foremost, we are reviewing and enhancing our operational processes for cooling system recovery based on learnings from this incident, to ensure that all employees have clear and documented actions to support faster recovery during high-stress scenarios. (Estimated completion: June 2026) • Our Log Analytics team is improving the resiliency of service startup processes so that transient initialization failures self-recover automatically, reducing the need for manual intervention during large-scale restarts. (Estimated completion: June 2026) • Our Networking team is addressing platform limitations that constrained the speed at which storage nodes could be returned to service following the thermal event. This includes reducing dependencies on manual coordination steps, and enabling faster parallel recovery of storage infrastructure. (Estimated completion: July 2026) • Our Networking team is also improving the tooling and processes used to identify which infrastructure devices have entered protective states and require manual recovery. This includes developing clearer prioritization of foundational devices (such as management and networking components) earlier in the recovery sequence, and improving awareness across teams when thermal events affect shared infrastructure. (Estimated completion: August 2026) • Our Log Analytics team is improving the architectural resiliency of our telemetry processing services by enabling multi-cluster flexibility and support for a broader pool of compute resource types, reducing dependence on any single cluster or resource type's availability and improving the ability to recover during large-scale scenarios. (Estimated completion: August 2026) • Finally, in the longer term we are performing a joint, holistic engineering review to evaluate the fail-state behavior of the cooling system protection logic. The current system prioritizes equipment protection and data security over operational continuity, which resulted in a full lockout rather than staged or degraded operation. This includes evaluating proactive row-level shutdown strategies during rapid temperature increases, and expanding the decision-making window available to operators before protective systems engage. (Estimated completion: October 2026) How can customers make incidents like this less impactful? • Note that the 'logical' Availability Zones used by each customer subscription may correspond to different physical Availability Zones - customers can use the Locations API to understand this mapping, to confirm which resources run in which physical AZ: https://learn.microsoft.com/rest/api/resources/subscriptions/list-locations • For mission-critical workloads, customers should consider a multi-region geodiversity strategy to avoid impact from incidents like this one that impacted a single region: https://learn.microsoft.com/en-us/azure/architecture/patterns/geodes and https://learn.microsoft.com/en-us/azure/well-architected/design-guides/regions-availability-zones • Consider leveraging data redundancy options such as Geo-Redundant Storage (GRS) or Read-Access Geo-Redundant Storage (RA-GRS), which replicate data to a secondary region and can provide continued read access to data during regional incidents: https://learn.microsoft.com/azure/storage/common/storage-redundancy • 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/GHRP-84G

Read the full incident report →

Started May 27, 2026, 01:01 PM UTC· resolved May 27, 2026, 02:44 PM UTC

1. monitoring May 27, 2026, 01:01 PM UTC

   Impact: From 08:40 UTC, 27 May 2026, some customers using Azure Synapse Analytics (private link, East US) may experience delays or failures accessing Synapse Studio or workspaces. We detected elevated connection failures via automated monitoring and are actively investigating.

2. monitoring May 27, 2026, 02:05 PM UTC

   Impact: From 08:40 UTC, 27 May 2026, some customers using Azure Synapse Analytics (private link) may experience delays or failures accessing Synapse Studio or workspaces across multiple regions. As of now mitigation is in progress, and we are seeing initial signs of recovery.

Read the full incident report →

Started May 18, 2026, 07:22 PM UTC· resolved May 18, 2026, 10:17 PM UTC

1. monitoring May 18, 2026, 05:24 PM UTC

   Impact Statement: Starting from 13:59 UTC on 18 May 2026, customers using Microsoft Fabric - including Power BI and PowerBI Embedded - may be experiencing delays or failures while interacting with the service. This issue is affecting multiple regions in the Azure public cloud. Current Status: We are aware of this issue and are actively investigating. Our analysis indicates that an unexpected increase in request traffic is causing a portion of the infrastructure to operate below optimal levels. Our on-call engineering teams are investigating relevant mitigations. There is no workaround available at this time. We expect to be able to resolve this issue by 18:45 UTC, approximately 90 minutes from now. The next update will be provided in 60 minutes, or as events warrant.

2. monitoring May 18, 2026, 06:33 PM UTC

   Impact Statement: Starting from 13:59 UTC on 18 May 2026, customers using Microsoft Fabric - including Power BI and PowerBI Embedded - may be experiencing delays or failures while interacting with the service. This issue is affecting multiple regions in the Azure public cloud. The Microsoft Fabric service status page is being updated at: https://support.fabric.microsoft.com/support/. Current Status: We identified that an unexpected increase in request traffic is causing a portion of the infrastructure to operate below optimal levels. Our on-call engineering teams have identified what we believe to be the relevant contributing factors, and have started to apply mitigations. We are initially applying these in a single region to help validate their effectiveness, before applying them more broadly. We are not able to provide a revised estimate of when this issue will be resolved - but the next update will be provided by 19:30 UTC (in approximately 60 minutes) or sooner if we have more to share.

3. monitoring May 18, 2026, 07:22 PM UTC

   Impact Statement: Starting from 13:59 UTC on 18 May 2026, customers using Microsoft Fabric - including Power BI and PowerBI Embedded - may be experiencing delays or failures while interacting with the service. This issue is affecting multiple regions in the Azure public cloud. Current Status: For the latest details, please refer to the Microsoft Fabric service status page: https://support.fabric.microsoft.com/support/

Read the full incident report →

Started May 14, 2026, 01:16 PM UTC· resolved May 14, 2026, 05:00 PM UTC

1. monitoring May 14, 2026, 05:09 PM UTC

   User impact: Users may see failures when accessing Microsoft Copilot More info: Users may be presented with a 401-error response code. Current status: We're investigating a potential issue with Microsoft Copilot and checking for impact to users. We'll provide an update within 30 minutes.

2. resolved May 14, 2026, 05:43 PM UTC

   User impact: Users may have seen failures when accessing Microsoft Copilot. More info: Users may be presented with a 401-error response code. Final status: We've completed a deployment to roll back to the most recent stable version of the service. Through our service side telemetry, we've confirmed that the service has been restored to a healthy level. Start time: Thursday, May 14, 2026, at 1:16 PM UTC End time: Thursday, May 14, 2026, at 5:00 PM UTC This is the final update for this event.

Read the full incident report →

Started May 05, 2026, 04:21 PM UTC· resolved May 11, 2026, 08:53 PM UTC

1. monitoring May 05, 2026, 04:21 PM UTC

   User impact: We're checking for potential impact to your users. Current status: We're investigating a potential issue with Microsoft 365 Copilot and checking for impact to your organization. We'll provide an update within 30 minutes.

2. monitoring May 11, 2026, 08:35 PM UTC

   User impact: We're checking for potential impact to your users. Current status: We're investigating a potential issue impacting Microsoft 365 Copilot and checking for impact to your organization. We'll provide an update within 30 minutes.

3. resolved May 11, 2026, 08:53 PM UTC

   User impact: We're checking for potential impact to your users. Final status: The investigation is complete and we've determined the service is healthy. A service incident didn't actually occur. This communication has expired. This is the final update for this event.

Read the full incident report →

Started May 02, 2026, 07:54 PM UTC· resolved Oct 02, 2026, 02:50 AM UTC

1. monitoring May 02, 2026, 07:54 PM UTC

   This site is updated when service issues are preventing tenant administrators from accessing the Power Platform admin center to view Service health status. Alternatively, customers can navigate to the M365 admin center to view the Service health status for the Power Platform services and Dynamics 365 applications.

Read the full incident report →

Started May 01, 2026, 04:17 PM UTC· resolved May 05, 2026, 11:32 PM UTC

1. monitoring May 05, 2026, 04:59 PM UTC

   User impact: Users may be unable to select "Allow editing" when using Copilot through Word or Excel. More info: Affected users may be unable to click on the drop-down menu to select "Allow editing" and may only be able to utilize "Chat mode" for Copilot queries through Word or Excel. Current status: We've received reports from a subset of users who have stated they are unable to select "Allow editing" when using Copilot through Word or Excel. We've isolated that a recent update intended to add additional agent functionality for Copilot premium users incorrectly marked "Allow editing" and other agent mode functionalities to be unavailable to non-premium users. We're deploying a code fix to address this and we anticipate the code fix to be fully deployed by our next scheduled update. Start time: Friday, May 01, 2026, at 4:17 PM UTC Next update by: Tuesday, May 05, 2026, at 6:00 PM UTC

2. monitoring May 05, 2026, 05:41 PM UTC

   User impact: Users may be unable to select "Allow editing" when using Copilot through Word or Excel. More info: Affected users may be unable to click on the drop-down menu to select "Allow editing" and may only be able to utilize "Chat mode" for Copilot queries through Word or Excel. Current status: Our fix deployment is currently at 90 percent saturation but is taking longer than expected to complete. We're working to expedite the remainder of our deployment, and we anticipate the code fix to be fully deployed by our next scheduled update. Start time: Friday, May 01, 2026, at 4:17 PM UTC Next update by: Wednesday, May 06, 2026, at 12:00 AM UTC

3. resolved May 06, 2026, 12:08 AM UTC

   User impact: Users may be unable to select "Allow editing" when using Copilot through Word or Excel. More info: Affected users may have been unable to click on the drop-down menu to select "Allow editing" and may have only been able to utilize "Chat mode" for Copilot queries through Word or Excel. Final status: We confirmed that an eligibility check error introduced in a recent update caused limited access for users. We developed and deployed a fix to correct the offending update, and after a period of monitoring the service health telemetry, confirmed that the errors associated with impact have been resolved and the issue was remediated by our actions. Start time: Friday, May 1, 2026, at 4:17 PM UTC End time: Monday, May 4, 2026, at 11:32 PM UTC This is the final update for the event.

Read the full incident report →

Started Apr 29, 2026, 09:02 PM UTC· resolved May 09, 2026, 04:16 PM UTC

1. monitoring Apr 29, 2026, 09:02 PM UTC

   User impact: iOS and iPadOS users may experience issues accessing Outlook and Hotmail from the iOS default Mail app. More Info: Outlook.com, Hotmail.com, and the Outlook app are still working as expected. However, if your account is locked out, you'll need to take multiple actions. First, you'll need to follow guidance in the article: https://support.microsoft.com/en-us/office/ios-ipados-users-may-experience-issues-accessing-their-outlook-and-hotmail-accounts-from-the-ios-ipados-default-mail-app-3584197b-8ffb-46ce-b5c6-f4cc71ff29a7 Next, after you've completed the steps in the above article, you will need to complete the numbered steps below for each impacted device. iOS and iPadOS users must take the following steps to access their accounts on EACH impacted device: 1. Open the Settings app on your iOS/iPadOS device. 2. Scroll down and tap on Mail. 3. Select Accounts under the Mail settings. 4. Tap on the email account for which you need to re-enter the password. 5. Tap on Account Settings or directly on the Password field (depending on your iOS/iPadOS version). 6. Enter the updated or correct password in the Password field. 7. Tap Done to save the changes. 8. Open the Mail app to confirm that the account is syncing properly and emails are being sent/received. Current status: Our service environment remains healthy, and users should follow the instructions listed in the More info section above for EACH impacted device. We’ve included a link to a support article with guidance should you encounter additional issues. Next update by: Thursday, April 30, 2026, at 10:00 PM UTC

Read the full incident report →

Started Apr 29, 2026, 01:51 PM UTC· resolved Apr 29, 2026, 03:28 PM UTC

1. resolved Apr 29, 2026, 04:11 PM UTC

   User impact: Affected users may have been unable to use Copilot services and features. More info: Prompts to Copilot may have returned an error message stating "Oops, Something happened. Can you try again?" Final status: We observed and mitigated an infrastructure issue that caused issues accessing Microsoft Copilot. We redirected traffic to healthy infrastructure and have confirmed that the issue is resolved. Start time: Wednesday, April 29, 2026, at 1:51 PM UTC End time: Wednesday, April 29, 2026, at 3:28 PM UTC This is the final update for the event.

Read the full incident report →

Started Apr 29, 2026, 07:37 AM UTC· resolved May 09, 2026, 04:16 PM UTC

1. monitoring Apr 29, 2026, 07:37 AM UTC

   User impact: Users may experience intermittent issues signing in to Outlook.com. More Info: If you are still impacted, we recommend the following steps outlined below to sign-in again on iOS devices: 1. Open the Settings app on your iPhone. 2. Scroll down and tap on Mail. 3. Select Accounts under the Mail settings. 4. Tap on the email account for which you need to reenter the password. 5. Tap on Account Settings or directly on the Password field. This will depend on your iOS version. 6. Enter the updated or correct password in the Password field. 7. Tap Done to save the changes. 8. Open the Mail app to confirm that the account is syncing properly and emails are being sent/received. Current status: We’re closely monitoring our internal and external service telemetry to ensure the impact does not reoccur. We still advise that users attempt to sign-in again and if they encounter the error message stating “You’ve tried to sign-in too many times with an incorrect account or password”, they should follow the inline user experience to reset their password and sign-in again. Next update by: Wednesday, April 29, 2026, at 2:00 PM UTC

2. monitoring Apr 29, 2026, 12:46 PM UTC

   User impact: Users may experience intermittent issues signing in to Outlook.com. Current status: We’re continuing to closely monitor service telemetry which continues to show the mitigation actions have been successful. However, if users are still impacted, we recommend that users attempt to sign-in again and if they encounter the error message stating “You’ve tried to sign-in too many times with an incorrect account or password”, they should follow the inline user experience to reset their password and sign-in again. Next update by: Wednesday, April 29, 2026, at 10:00 PM UTC

Read the full incident report →

Started Apr 28, 2026, 09:46 PM UTC· resolved Apr 28, 2026, 09:52 PM UTC

1. monitoring Apr 28, 2026, 09:46 PM UTC

   User impact: We're checking for potential impact to your users. Current status: We're investigating a potential issue impacting Microsoft 365 Copilot Chat and checking for impact to your organization. We'll provide an update within 30 minutes.

2. resolved Apr 28, 2026, 09:52 PM UTC

   User impact: We're checking for potential impact to your users. Final status: The investigation is complete and we've determined the service is healthy. A service incident didn't actually occur. This communication has expired. This is the final update for the event.

Read the full incident report →

Started Apr 28, 2026, 02:21 PM UTC· resolved May 09, 2026, 04:16 PM UTC

1. monitoring Apr 28, 2026, 02:21 PM UTC

   User impact: Users may experience intermittent issues signing-in to Outlook.com in the iOS mail app. Current status: We’ve received reports that impact associated with OL1292958 persists. We've resumed our investigation of the issue and are currently analyzing service telemetry and investigating reported behavior to determine scope and next steps. Next update by: Tuesday, April 28, 2026, at 5:00 PM UTC

2. monitoring Apr 28, 2026, 05:10 PM UTC

   User impact: Users may experience intermittent issues signing-in to Outlook.com in the iOS mail app. Current status: We're performing some changes to optimize the outlook.com iOS sign-in experience and, once complete, we'll provide instructions to help users sign back into their accounts. In the interim as we develop this change, we recommend trying the following steps to sign in to your account: 1. Open the Settings app on your iPhone. 2. Scroll down and tap on Mail. 3. Select Accounts under the Mail settings. 4. Tap on the email account for which you need to reenter the password. 5. Tap on Account Settings or directly on the Password field (depending on your iOS version). 6. Enter the updated or correct password in the Password field. 7. Tap Done to save the changes. 8. Open the Mail app to confirm that the account is syncing properly and emails are being sent/received. Next update by: Tuesday, April 28, 2026, at 11:00 PM UTC

3. monitoring Apr 28, 2026, 10:33 PM UTC

   User impact: Users may experience intermittent issues signing-in to Outlook.com in the iOS mail app. Current status: We're continuing to optimize the outlook.com iOS sign-in experience to address reports of persisting impact. We've also investigated the scenario in which users are encountering repeated sign-in prompts and are then informed, "You've tried to sign in too many times with an incorrect account or password"; users experiencing this scenario should sign in with other methods or reset their password to sign in to their accounts. We'll provide more guidance as it becomes available. Next update by: Wednesday, April 29, 2026, at 1:30 AM UTC

4. monitoring Apr 28, 2026, 11:35 PM UTC

   User impact: Users may experience intermittent issues signing-in to Outlook.com in the iOS mail app. Current status: We're continuing to optimize the outlook.com iOS sign-in experience to address reports of persisting impact. We've also investigated the scenario in which users are encountering repeated sign-in prompts and are then informed, "You've tried to sign in too many times with an incorrect account or password"; users experiencing this scenario should sign in with other methods or reset their password to sign in to their accounts. We'll provide more guidance as it becomes available. Next update by: Wednesday, April 29, 2026, at 1:30 AM UTC

5. monitoring Apr 29, 2026, 01:25 AM UTC

   User impact: Users may experience intermittent issues signing-in to Outlook.com in the iOS mail app. Current status: We’re continuing to implement further optimizations for the outlook.com iOS sign-in experience to help address reports of persisting impact. While we monitor these optimization changes to assess their effectiveness, we’re also looking into what additional changes may be needed to address the scenario in which users are encountering repeated sign-in prompts. We still recommend that for users experiencing this scenario, they should sign in with other methods or reset their password to sign in to their accounts. We’ll continue to provide more guidance as it becomes available. Next update by: Wednesday, April 29, 2026, at 3:30 AM UTC

6. monitoring Apr 29, 2026, 03:29 AM UTC

   User impact: Users may experience intermittent issues signing-in to Outlook.com in the iOS mail app. More Info: If you are still impacted, we recommend the following steps outlined below to sign-in again on iOS devices: 1. Open the Settings app on your iPhone. 2. Scroll down and tap on Mail. 3. Select Accounts under the Mail settings. 4. Tap on the email account for which you need to reenter the password. 5. Tap on Account Settings or directly on the Password field. This will depend on your iOS version. 6. Enter the updated or correct password in the Password field. 7. Tap Done to save the changes. 8. Open the Mail app to confirm that the account is syncing properly and emails are being sent/received. Current status: We’ve completed all our optimization changes to fully address the impact for the outlook.com iOS sign-in experience and we’ve confirmed service health has returned to normal. We anticipate that users should no longer experience repeated sign-in prompts hindering the sign-in process. We recommend that users attempt to sign-in again and if they encounter the error message stating “You’ve tried to sign-in too many times with an incorrect account or password”, they should follow the inline user experience to reset their password and sign-in again. Next update by: Wednesday, April 29, 2026, at 9:00 AM UTC

Read the full incident report →

Started Apr 27, 2026, 08:45 AM UTC· resolved May 08, 2026, 04:00 PM UTC

1. monitoring Apr 30, 2026, 05:33 PM UTC

   User impact: iOS, iPadOS, and iPad users may experience issues accessing Outlook and Hotmail from the iOS default Mail app. More Info: Outlook.com, Hotmail.com, and the Outlook app are still working as expected. However, if your account is locked out, you'll need to take multiple actions as outlined below. First, you'll need to follow guidance in the article: https://support.microsoft.com/en-us/office/ios-ipados-users-may-experience-issues-accessing-their-outlook-and-hotmail-accounts-from-the-ios-ipados-default-mail-app-3584197b-8ffb-46ce-b5c6-f4cc71ff29a7 Next, after you've completed all steps in the above article, you will need to complete the numbered steps below for each impacted device. iOS and iPadOS users must take the following steps to access their accounts on EACH impacted device: 1. Open the Settings app on your iOS/iPadOS device. 2. Scroll down and tap on Mail. 3. Select Accounts under the Mail settings. 4. Tap on the email account for which you need to re-enter the password. 5. Tap on Account Settings or directly on the Password field (depending on your iOS/iPadOS version). 6. Enter the updated or correct password in the Password field. 7. Tap Done to save the changes. 8. Open the Mail app to confirm that the account is syncing properly and emails are being sent/received. Current status: We're continuing to monitor service telemetry and can confirm our environment remains healthy as more users follow the instructions provided in the More info section of this communication for EACH individual impacted device. We’ve included a link to a support article with guidance on remediating impact should affected users encounter issues with this recommended process. Next update by: Friday, May 1, 2026, at 6:00 PM UTC

2. monitoring May 01, 2026, 04:29 PM UTC

   User impact: iOS, iPadOS, and iPad users may experience issues accessing Outlook and Hotmail from the iOS default Mail app. More info: Outlook.com, Hotmail.com, and the Outlook app are still working as expected. However, if your account is locked out, you'll need to take multiple actions as outlined below. First, you'll need to follow guidance in the article: https://support.microsoft.com/en-us/office/ios-ipados-users-may-experience-issues-accessing-their-outlook-and-hotmail-accounts-from-the-ios-ipados-default-mail-app-3584197b-8ffb-46ce-b5c6-f4cc71ff29a7 Next, after you've completed all steps in the above article, you will need to complete the numbered steps below for each impacted device. iOS and iPadOS users must take the following steps to access their accounts on EACH impacted device: 1. Open the Settings app on your iOS/iPadOS device. 2. Scroll down and tap on Mail. 3. Select Accounts under the Mail settings. 4. Tap on the email account for which you need to re-enter the password. 5. Tap on Account Settings or directly on the Password field (depending on your iOS/iPadOS version). 6. Enter the updated or correct password in the Password field. 7. Tap Done to save the changes. 8. Open the Mail app to confirm that the account is syncing properly and emails are being sent/received. Current status: Our service health telemetry indicates that user access continues to be restored as the steps provided in the linked support article in the "More info" section are followed by each impacted device. We're continuing to monitor the telemetry to further validate that the environment remains in a healthy state. Next update by: Monday, May 4, 2026, at 6:00 PM UTC

3. monitoring May 04, 2026, 05:04 PM UTC

   User impact: iOS, iPadOS, and iPad users may experience issues accessing Outlook and Hotmail from the iOS default Mail app. More info: Outlook.com, Hotmail.com, and the Outlook app are still working as expected. However, if your account is locked out, you'll need to take multiple actions as outlined below. First, you'll need to follow guidance in the article: https://support.microsoft.com/en-us/office/ios-ipados-users-may-experience-issues-accessing-their-outlook-and-hotmail-accounts-from-the-ios-ipados-default-mail-app-3584197b-8ffb-46ce-b5c6-f4cc71ff29a7 Next, after you've completed all steps in the above article, you will need to complete the numbered steps below for each impacted device. iOS and iPadOS users must take the following steps to access their accounts on EACH impacted device: 1. Open the Settings app on your iOS/iPadOS device. 2. Scroll down and tap on Mail. 3. Select Accounts under the Mail settings. 4. Tap on the email account for which you need to re-enter the password. 5. Tap on Account Settings or directly on the Password field (depending on your iOS/iPadOS version). 6. Enter the updated or correct password in the Password field. 7. Tap Done to save the changes. 8. Open the Mail app to confirm that the account is syncing properly and emails are being sent/received. Current status: We're continuing to observe the number of impacted devices decrease as users follow the steps provided in the "More info" section and recover access. We'll continue to monitor the telemetry to ensure the service remains in a healthy state. Next update by: Wednesday, May 6, 2026, at 6:30 PM UTC

4. monitoring May 06, 2026, 05:00 PM UTC

   User impact: iOS, iPadOS, and iPad users may experience issues accessing Outlook and Hotmail from the iOS default Mail app. More info: Outlook.com, Hotmail.com, and the Outlook app are still working as expected. However, if your account is locked out, you'll need to take multiple actions as outlined below. First, you'll need to follow guidance in the article: https://support.microsoft.com/en-us/office/ios-ipados-users-may-experience-issues-accessing-their-outlook-and-hotmail-accounts-from-the-ios-ipados-default-mail-app-3584197b-8ffb-46ce-b5c6-f4cc71ff29a7 Next, after you've completed all steps in the above article, you will need to complete the numbered steps below for each impacted device. iOS and iPadOS users must take the following steps to access their accounts on EACH impacted device: 1. Open the Settings app on your iOS/iPadOS device. 2. Scroll down and tap on Mail. 3. Select Accounts under the Mail settings. 4. Tap on the email account for which you need to re-enter the password. 5. Tap on Account Settings or directly on the Password field (depending on your iOS/iPadOS version). 6. Enter the updated or correct password in the Password field. 7. Tap Done to save the changes. 8. Open the Mail app to confirm that the account is syncing properly and emails are being sent/received. Current status: We're continuing to observe the number of impacted devices decrease as users follow the recovery guidance provided in the “More info” section and regain access. Our continued close monitoring of system telemetry indicates that the service remains healthy. Next update by: Friday, May 8, 2026, at 6:30 PM UTC

5. resolved May 08, 2026, 05:21 PM UTC

   User impact: iOS, iPadOS, and iPad users may have experienced issues accessing Outlook and Hotmail from the iOS default Mail app. More info: Outlook.com, Hotmail.com, and the Outlook app worked as expected. However, if the user’s account was locked out, they’ll need to take multiple actions as outlined below. First, users will need to follow guidance in the article: https://support.microsoft.com/en-us/office/ios-ipados-users-may have-experience-issues-accessing-their-outlook-and-hotmail-accounts-from-the-ios-ipados-default-mail-app-3584197b-8ffb-46ce-b5c6-f4cc71ff29a7 Next, after users have completed all steps in the above article, they will need to complete the numbered steps below for each impacted device. iOS and iPadOS users must take the following steps to access their accounts on EACH impacted device: 1. Open the Settings app on your iOS/iPadOS device. 2. Scroll down and tap on Mail. 3. Select Accounts under the Mail settings. 4. Tap on the email account for which you need to re-enter the password. 5. Tap on Account Settings or directly on the Password field (depending on your iOS/iPadOS version). 6. Enter the updated or correct password in the Password field. 7. Tap Done to save the changes. 8. Open the Mail app to confirm that the account was synced properly and that email messages were being sent/received. Final status: We've confirmed through our system telemetry that the service continues to remain healthy. Users who continue to experience issues should follow the steps outlined in "More Info" section. Start time: Monday, April 27, 2026, at 8:45 AM UTC End time: Friday, May 8, 2026, at 4:00 PM UTC This is the final update for the event.

Read the full incident report →

Started Apr 24, 2026, 11:30 AM UTC· resolved Apr 24, 2026, 11:22 PM UTC

1. monitoring Apr 24, 2026, 11:39 AM UTC

   Impact Statement: Starting at 11:39 UTC on 24 April 2026, a platform issue resulted in provisioning, scaling, and connectivity issues for customers with Azure workloads hosted in the East US region. This issue initially affected one availability zone in East US. As traffic was automatically rerouted and shared services were involved, some customers in other availability zones may have also experienced an impact. Current Status: We detected this issue through our automated monitoring, which identified an unusual increase in failures within the services supporting virtual machine and virtual machine scale set operations in the East US region. We have taken steps to stabilize the affected services and address the underlying issue, while continuing the investigation to determine contributing factors. The next update will be shared within 60 minutes, or as events warrant.

2. postmortem Apr 24, 2026, 11:22 PM UTC

   Watch our 'Azure Incident Retrospective' video about this incident: https://aka.ms/air/5GP8-W0G What happened? Between 11:30 and 23:22 UTC on 24 April 2026, customers may have experienced failures or delays when attempting to provision, scale, or update resources in East US. Beyond this impact to service management, a small subset of customers may have encountered intermittent connectivity issues for newly-provisioned workloads including Virtual Machines and Azure Virtual Desktop sessions. The issue initially began with impact to a subset of customers in a single Availability Zone (physical AZ-01) but as demand shifted, similar symptoms were observed impacting service management operations in AZ-02 and AZ-03. While none of these zones were impacted for the full duration of the incident, customers could have experienced periods of impact in each zone for portions of the incident. The following services were among those affected: Azure Application Gateway, Azure App Service, Azure Batch, Azure Cache for Redis, Azure Data Explorer, Azure Data Factory, Azure Databricks, Azure Health Data Services, Azure Kubernetes Service (AKS), Azure Red Hat OpenShift, Azure Service Fabric, Azure Synapse Analytics, Azure Virtual Desktop, Azure Virtual Machines (VMs), Azure Virtual Network Manager, Azure VMware Solution, Oracle Database@Azure, Virtual Machine Scale Sets – and potentially additional services that were dependent on new compute allocations in the region. Note: Logical availability zones assigned to customer subscriptions may map to different physical availability zones. Customers can use the Locations API to understand this mapping: https://learn.microsoft.com/rest/api/resources/subscriptions/list-locations?HTTP#availabilityzonemappings. What went wrong and why? The Azure PubSub service is a key component of the networking control plane, acting as an intermediary between resource providers and networking agents on Azure hosts. Resource providers, such as the Network Resource Provider (NRP), publish customer configurations during VM or networking ‘create, update, or delete’ operations. Networking agents (subscribers) on the hosts retrieve these configurations from the resource providers to program the host's networking stack. Additionally, the PubSub service functions as a cache, ensuring efficient retrieval of configurations during the lifecycle of a VM. This capability is essential for resource allocation and network mappings in Azure Virtual Network (VNet) environments. Like many Azure control plane services, Azure PubSub leverages Azure Service Fabric for distributed state management through a compute and data co-locating architecture. This is designed to enable low-latency, high-performance execution with built-in consistency by keeping application logic and replicated state together on the same nodes. During normal platform operations, one partition of the PubSub control plane service in a single Availability Zone (AZ-01) experienced lock contention errors for several minutes, resulting in operations on that partition to timeout and fail. As designed, the platform initiated an automatic failover to a secondary replica, but this failover did not complete successfully. We intervened to investigate and attempted a manual failover of the primary partition, but this attempt was also unsuccessful, therefore resources on the impacted partition continued to see service management failures. Approximately two hours into troubleshooting, we received alerts of impact to a single partition in AZ-03, which indicated partial loss of control plane availability in this zone as well. As the investigation progressed, we suspected that a previously deployed update to a control plane dependency had introduced a regression which could trigger lock contention under certain conditions.As part of our mitigation efforts, we prepared a rollback to the ‘last known good’ version to eliminate the possibility of a regression. We first applied this rollback in AZ-03, which successfully restored control plane service in that zone. Based on this, we began rolling back the affected components in AZ-01. By design, rollback operations are executed in stages by our Service Fabric controllers using update domains to ensure platform safety. Recovery time was further extended because compute and data are co-located on the same nodes. In some cases, rollback requires rebuilding full replicas on new nodes, which significantly increases the time required to complete each stage. Given these conditions, we intentionally prioritized maintaining availability for unaffected partitions and services rather than accelerating the rollback. This combination of sequential update domain processing, replica rebuild requirements, and our standard safe recovery approach, resulted in an extended time to mitigate. While mitigation was in progress, there were two periods of time during which we were unable to maintain two simultaneous fully healthy instances of the PubSub service across availability zones, a requirement for normal replication and control plane operations. This resulted in a temporary loss of quorum within the service. As the service attempted to self-heal, customer impact shifted between availability zones, leading to periods of degraded behavior across multiple zones. These failure patterns began to appear in AZ-02 and again in AZ-03, broadening the scope of impact across the region. For AZ-02 we initiated and completed a rollback, and although AZ-03 had previously shown recovery following the earlier attempted rollback, we discovered that the rollback in that zone had not fully completed to all update domains. As impact reemerged, a rollback in AZ-03 was reinitialized and then completed, fully restoring service health. Our post incident investigations confirmed that a latent regression in a recently deployed version of the PubSub service exacerbated the replica build times for the large Availability Zones of this region. This regression also contributed to the failure of the failover process, as it increased contention and reduced the service’s ability to build replicas under these conditions successfully. This issue had not surfaced during earlier testing, or in any other regions which had already received the update. During the early stages of the incident, the impact appeared limited to a specific set of VM service management operations. Our first customer communication was automatically sent to impacted customers within 30 minutes of the issue starting, via our “BRAIN” automated messaging system. As more signals surfaced, it became clear that the impact was becoming broader and affecting the underlying systems on which multiple services rely, across Availability Zones. Consequently, we expanded our communications from attempting to target affected subscriptions, to communicating to all customers with resources in the region – in addition to publishing to our public Azure Status page. Finally, some updates lacked specificity that could have helped customers understand the evolving impact, how widespread the issue was, and how best to respond. We have included communications-related learnings below, to improve both the speed and level of detail. How did we respond? • 11:30 UTC on 24 April 2026 – Customer impact began, including failures and delays when attempting to provision, scale, or update resources. • 11:38 UTC on 24 April 2026 – We detected an issue in AZ-01. A control plane partition experienced lock contention, and automatic failover attempts to secondary replicas did not complete successfully. • 11:38–13:40 UTC on 24 April 2026 – We attempted manual failover in AZ-01, but these efforts did not successfully restore service. • 11:59 UTC on 24 April 2026 – First targeted notifications were sent to a subset of impacted customers, via our “BRAIN” automated messaging system. • 13:14 on 24 April 2026 – Notifications expanded to customer subscriptions that were using VMs/VMSS resources in the region. • 13:40 UTC on 24 April 2026 – We identified a recently deployed update as the likely trigger condition for this issue. • 13:50 UTC on 24 April 2026 – We began observing impact in AZ-03, indicating the issue was now affecting multiple Availability Zones. • 14:07 UTC on 24 April 2026 – We initiated a rollback to the last known good version in AZ-03. • 15:03 UTC on 24 April 2026 – We observed significant recovery in AZ-03, control plane availability exceeded 99%. • 15:04 UTC on 24 April 2026 – We initiated a rollback to the last known good version in AZ-01. • 15:36 UTC on 24 April 2026 – First public Azure Status page update, to ensure wider visibility. • 17:19 on 24 April 2026 – Notifications expanded to all customer subscriptions that were using any resources in the region. • 18:52 UTC on 24 April 2026 – We observed significant improvement in AZ-01, as the rollback progressed. • 19:02 UTC on 24 April 2026 – We observed significant recovery in AZ-01, control plane availability exceeded 99%. • 19:05 UTC on 24 April 2026 – We began observing impact in AZ-02, as load redistributed across the region. • 19:10 UTC on 24 April 2026 – We initiated a rollback to the last known good version in AZ-02. • 21:02 UTC on 24 April 2026 – We observed instability reappear in AZ-03, determined that this was because the rollback had not yet completed across all update domains, so manually reinitialized the rollback. • 22:39 UTC on 24 April 2026 – We confirmed the rollback was fully completed in AZ-03. • 23:22 UTC on 24 April 2026 – All customer impact confirmed as mitigated. How are we making incidents like this less likely or less impactful? • We assessed the risk of occurrence in other regions with large Availability Zones and rolled back the PubSub service update in these regions. (Completed) • We are improving our test coverage surrounding the failure cases and load patterns that contributed to this incident, to catch similar issues before they reach production. (Estimated completion: June 2026) • We are reducing the blast radius of each partition by adjusting the scale of the partitioning used by the PubSub service. (Estimated completion: June 2026) • We are investing in additional enrichment surrounding our Network Resource Provider monitoring, to determine impacted subscriptions and send initial communications automatically. (Estimated completion: August 2026) • While co-locating compute and data on the same node in Service Fabric provides performance benefits, it can make rollback and recovery more challenging under resource-constrained conditions. To address this, we are developing a solution designed to ensure resource constraints do not delay recovery operations. (Estimated completion: September 2026) • Finally, we are further developing our AI-assisted communication system to consolidate relevant incident information into more detailed customer updates. (Estimated completion: September 2026) How can customers make incidents like this less impactful? • For mission-critical workloads, customers should consider a multi-region geodiversity strategy to avoid impact from incidents like this one that impacted a single region: https://learn.microsoft.com/azure/architecture/patterns/geodes and https://learn.microsoft.com/azure/well-architected/design-guides/regions-availability-zones • 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/5GP8-W0G

Read the full incident report →

Started Apr 08, 2026, 06:45 AM UTC· resolved May 21, 2026, 12:09 PM UTC

1. monitoring Apr 28, 2026, 02:12 PM UTC

   User impact: Users are unable to search, chat or call users in Microsoft Teams Free. More info: Some new users who signed up during the impact window were incorrectly treated as already onboarded, causing onboarding and privacy consent screens to be skipped, their profiles to appear as “Unknown users” to others, and preventing them from being searchable or reliably reachable in chat. Current status: We've identified a recently deployed backend change is causing new Teams Free users to bypass required onboarding steps, leaving user profiles in an incomplete state. As a result, affected users can not be discovered, connect with others, or successfully complete chat request flows. We're analyzing all our available resources to identify a mitigation plan. Start time: Wednesday, April 08, 2026, at 6:45 AM UTC Next update by: Wednesday, April 29, 2026, at 3:30 PM UTC

2. monitoring Apr 29, 2026, 01:44 PM UTC

   User impact: Users are unable to search, chat or call users in Microsoft Teams Free. More info: Some new users who signed up during the impact window were incorrectly treated as already onboarded, causing onboarding and privacy consent screens to be skipped, their profiles to appear as “Unknown users” to others, and preventing them from being searchable or reliably reachable in chat. Current status: We're continuing to review various available mitigation strategies to determine the most effective method to relieve impact. As a workaround, affected users can sign into the mobile application and complete onboarding steps to make the desktop application function as expected. Start time: Wednesday, April 8, 2026, at 6:45 AM UTC Next update by: Wednesday, May 6, 2026, at 3:30 PM UTC

3. monitoring May 06, 2026, 02:37 PM UTC

   User impact: Users are unable to search, chat or call users in Microsoft Teams Free. Current status: We're validating a fix to address the underlying issue. Due to the complexity of the deployment, the validation is taking longer than initially anticipated. Once the fix is finalized, we’ll confirm the update in our internal test environment to ensure it doesn’t introduce any regression, before progressing with a gradual rollout to the affected environment. We'll share an estimated completion timeline when one becomes available. Start time: Wednesday, April 8, 2026, at 6:45 AM UTC Next update by: Wednesday, May 13, 2026, at 3:30 PM UTC

4. monitoring May 13, 2026, 03:15 PM UTC

   User impact: Users are unable to search, chat, or call users in Microsoft Teams Free. Current status: We've completed validations of our fix within our internal testing environment and have initiated a gradual rollout of our fix to affected users. Start time: Wednesday, April 08, 2026, at 6:45 AM UTC Next update by: Wednesday, May 13, 2026, at 5:30 PM UTC

5. monitoring May 20, 2026, 03:20 PM UTC

   User impact: Users are unable to search, chat, or call users in Microsoft Teams Free. Current status: We're monitoring our fix deployment to ensure it has saturated throughout the entire affected environment before validating this issue is resolved. Start time: Wednesday, April 08, 2026, at 6:45 AM UTC Next update by: Wednesday, May 20, 2026, at 5:30 PM UTC

6. resolved May 20, 2026, 04:12 PM UTC

   User impact: Users may have been unable to search, chat, or call users in Microsoft Teams Free. Final status: We've determined that a recent service update introduced the problem for the Microsoft Teams Free new user onboarding flow and caused new accounts to skip this flow entirely and appear as "unknown user." These affected "unknown" users were marked as non-searchable accounts, which resulted in impact. We've validated that our configuration change fix to correct this error has fully deployed throughout the affected environment and has successfully remediated all impact. Start time: Wednesday, April 08, 2026, at 6:45 AM UTC End time: Wednesday, May 20, 2026, at 12:02 PM UTC This is the final update for the event.

Read the full incident report →

Started Mar 09, 2026, 11:20 PM UTC· resolved Mar 10, 2026, 07:32 PM UTC

1. postmortem Mar 10, 2026, 07:32 PM UTC

   Watch our 'Azure Incident Retrospective' video about this incident: https://aka.ms/air/8GCS-858 What happened? Between 23:20 UTC on 9 March and 19:32 UTC on 10 March 2026, a platform issue resulted in impact to the Azure OpenAI Service. Impacted customers experienced HTTP 400 and HTTP 429 error responses, specifically for the GPT-5.2 model. All other GPT models were unaffected during this time. This incident impacted customer resources and queries in the following regions: Australia East, Central US, East US 2, Korea Central, Norway East, Sweden Central, and UK South. What went wrong and why? 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. A recent update to the Azure OpenAI GPT 5.2 model introduced a configuration change that was not compatible with the version of the model engine code running in production. As part of this update, certain feature settings were enabled to improve service efficiency and resilience – however, the deployed engine version did not yet support those settings. As a result, when customer requests were routed to engines with this mismatch, the service was unable to process these requests correctly. Generally speaking, any updates to the service are rolled out in line with our Safe Deployment Practices (SDP) which deploys to different regions gradually, in stages. During this update, the earlier stages of the rollout did not include sufficient backend model instances for this issue to surface before the update progressed to additional regions. As a result, the rollout had completed its deployment across our fleet before we were able to determine customer impact. During mitigation of the primary issue, we identified a secondary issue that affected service recovery. Azure OpenAI relies on internal telemetry to understand real-time service capacity across regions and to route traffic accordingly. At the time recovery actions were underway, an unrelated issue in this internal telemetry system led to incomplete capacity information being leveraged. As a result, traffic routes were temporarily being determined using incomplete data, which led to a disproportionate amount of traffic being directed to a limited set of available regions. This created additional resource pressure in those regions and resulted in continued intermittent request failures (HTTP 429 errors) for some customers, even as the rollback of the configuration issue was progressing and other regions were actually available to receive requests. Once the routing updates were successfully completed and full capacity information was restored across regions, traffic distribution normalized and service recovery progressed as expected. During the incident, we also identified a monitoring gap related to anomalous HTTP 400 error patterns. While HTTP 400 responses do occur during normal service usage, our monitoring was not configured for service‑side anomalies, only for client-side errors – which are typically caused by incorrect parameters in user requests. This miss in monitoring during the initial stages of the incident delayed detection and response. How did we respond? • 23:20 UTC on 09 March 2026 – Customer impact began, triggered by the recent service update. • 00:19 UTC on 10 March 2026 – We detected the issue via service monitoring. This prompted us to begin our investigation, engage with other teams to troubleshoot, and start developing a hot fix. • 03:18 UTC on 10 March 2026 – We determined that a rollback could mitigate more quickly than hotfix, so started the rollback for the impacted model. • 10:55 UTC on 10 March 2026 – Traffic routes were determined to be using incomplete data, due to the aforementioned dependency issue. • 12:40 UTC on 10 March 2026 – We identified and investigated resource constraints. • 18:00 UTC on 10 March 2026 – Rollback actions completed across all affected regions. • 19:30 UTC on 10 March 2026 – Full capacity information was restored across regions, traffic distribution normalized. • 19:32 UTC on 10 March 2026 – Once monitoring confirmed stable recovery, we determined the service was fully restored and all customer impact had been mitigated. How are we making incidents like this less likely or less impactful? • We have already conducted additional engineer training on our operating procedures – including which scenarios can be quickly rolled back – to reduce the time to mitigate similar issues. (Completed) • We have incorporated storing a ‘cached’ known good version of the traffic routing details, as an additional layer of resilience in case the dependent service is not able to serve the latest information on regional capacity availability. (Completed) • We have improved our monitoring surrounding HTTP 400 errors, by establishing thresholds of errors on the service side. (Completed) • To expand that monitoring further, we are improving our anomaly detection surrounding HTTP 4xx errors – to alert on anomalous error rates that may not meet our usual thresholds. (Estimated completion: April 2026) • We are incorporating additional signals to our deployment systems, to reduce potential impact by stopping problematic rollouts automatically. (Estimated completion: May 2026) • Finally, we are improving our safe deployment practices by ensuring that early stages have sufficient backend model instances to catch issues like this earlier. (Estimated completion: June 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 Azure OpenAI: https://learn.microsoft.com/azure/ai-services/openai/how-to/business-continuity-disaster-recovery • 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/8GCS-858

Read the full incident report →