This week, the “cloud” once again brought its most down-to-earth aspect: electricity. On Saturday, February 7, 2026, Microsoft confirmed an unexpected power outage at one of its facilities in the West US region—an incident that physically affected services taken for granted by millions, such as Windows Update and the Microsoft Store, as well as enterprise workloads hosted on Azure.
According to the official message posted on the Windows status page, the power cut impacted customers’ ability to complete operations in the Microsoft Store and Windows Update, leading to failures or delays when installing applications or downloading system updates. Although power was restored, the company warned that recovery was still underway and that storage services were gradually returning to normal, with the possibility of residual issues during the process.
In practice, the problem resulted in a wave of errors and failed downloads. Windows 11 users reported the familiar error code 0x80244022 when trying to update their system or install apps from the store—an indicator that the device couldn’t establish communication with the update services on the server side. Several specialized Windows media outlets collected user reports and screenshots of the failure, aligning with the impact window acknowledged by Microsoft.
Why a power outage isn’t “fixed” just by turning it back on
The most revealing aspect of incidents like this is that restoring power doesn’t equate to an instant recovery. In large cloud platforms, normal operation often depends on integrity checks, re-synchronization of distributed systems, and traffic rebalancing to prevent a “cold start” from causing new bottlenecks. Microsoft, in fact, linked the recovery to the gradual reactivation of storage components—a critical element when distributing packages, metadata, and content related to updates and downloads.
For the business world, the impact isn’t limited to the user experience on a PC. In its status dashboard, Microsoft indicated that, since 08:00 UTC on February 7, a subset of customers with resources in West US might experience intermittent outages or delays in telemetry, monitoring, and log data from certain services hosted in the affected data center areas. In other words: during part of the incident, some organizations had to operate with degraded visibility just when they needed to monitor what was happening most.
A especially challenging week for Azure’s perceived reliability
The context worsens the interpretation of the event. Just days earlier, between February 2 and 3, Azure had already experienced a prolonged outage affecting service management operations and later Managed Identities, a key component for authentication and automation in cloud environments. Azure’s own status history describes a chain of events beginning on February 2 at 19:46 UTC, with mitigations, re-enabled services, and a subsequent peak of impact on managed identity services—especially in regions like East US and West US.
Industry reports estimated that episode caused more than 10 hours of global impact across various operational layers—from virtual machine lifecycle management to identity-dependent workflows—highlighting how a single platform change or fix can amplify impact when internal dependencies and mass retries converge.
The coinciding timing of both a “logical” failure (service configuration and management) and a “physical” failure (power and infrastructure recovery) within a week raises a recurring question in tech risk committees: what happens when a hyperscale provider falters twice in quick succession, for different reasons? Not because incidents are rare, but because they challenge assumptions about continuity that are often taken for granted.
Lessons that resurface whenever the cloud becomes tangible
In terms of resilience, this incident reaffirms three well-known, yet not always applied, principles:
- Redundancy isn’t the same as automatic continuity. Having backup power sources or duplicated systems reduces risks, but a “seamless transition” is hard in complex infrastructures—especially when intermediate storage states and load balancing come into play.
- Multi-region must be genuine, not just cosmetic. Backups and replication are essential, but critical services will only survive a regional outage if they can operate in another geography with proven procedures and automation.
- Observability is also a single point of failure. If telemetry is delayed or degraded, external validation (such as outside monitoring or independent signals) is advisable to prevent making decisions based on incomplete information.
Microsoft did not publicly detail the exact scope per customer or the number of enterprise services affected in West US beyond mentioning a “subset of customers” and the impact on Store/Update operations, but it clearly conveyed that the incident was physical, backup systems activated, and recovery depended on the gradual stabilization of storage and related services.
Frequently Asked Questions
What does error 0x80244022 mean in Windows 11 during a Microsoft outage?
It typically indicates that Windows Update or the Microsoft Store cannot complete the connection with update/download services. During data center or infrastructure outages, it may appear even if the device is properly configured.
Can an outage in Azure West US affect Windows Update and Microsoft Store outside that region?
Yes. Even if the incident is localized, some distribution components and flows may depend on regional elements or experience indirect effects due to congestion, retries, and phased recovery.
How does one prepare a continuity plan for a power failure at a cloud data center?
With multi-region architecture, tested failover procedures, verified backups, and independent monitoring. For critical environments, regular disaster recovery drills are also recommended.
What should companies review after experiencing two consecutive incidents in Azure (identity and power)?
Auditing dependencies (identity, storage, queues, extensions), reviewing retry limits, verifying multi-region deployment operability beyond documentation, and validating actual recovery times (RTO/RPO).
via: cybersecuritynews