La “nube” volvió a recordar esta semana su parte más terrenal: la electricidad. Microsoft confirmó el sábado 7 de febrero de 2026 una interrupción inesperada del suministro de la red eléctrica en una de sus instalaciones de la región West US, un incidente físico que acabó trasladándose a servicios que millones de personas dan por sentados, como Windows Update y la Microsoft Store, y también a cargas empresariales alojadas en Azure.

Según el mensaje oficial publicado en el centro de estado de Windows, el corte de energía impactó en la capacidad de los clientes para completar operaciones en la Microsoft Store y Windows Update, provocando fallos o tiempos de espera al instalar aplicaciones o descargar actualizaciones del sistema. Aunque el suministro se restableció, la compañía advirtió de que la recuperación seguía en curso y que los servicios de almacenamiento estaban volviendo gradualmente a la normalidad, con la posibilidad de que persistieran incidencias residuales durante el proceso.

En la práctica, el problema se tradujo en una oleada de errores y descargas fallidas. Usuarios de Windows 11 reportaron el conocido código 0x80244022 al intentar actualizar el sistema o instalar aplicaciones desde la tienda, una señal habitual de que el dispositivo no logra completar la comunicación con los servicios de actualización en el lado servidor. Distintos medios especializados en Windows recogieron testimonios y capturas del fallo, coincidiendo con la ventana de impacto reconocida por Microsoft.

Por qué un apagón no se “arregla” solo con volver a encender

El aspecto más revelador de este tipo de incidentes es que el restablecimiento de la energía no equivale a una recuperación instantánea. En grandes plataformas cloud, la vuelta a la normalidad suele depender de chequeos de integridad, re-sincronización de sistemas distribuidos y reequilibrio del tráfico para evitar que un “arranque en frío” provoque nuevos cuellos de botella. Microsoft, de hecho, vinculó la recuperación a la vuelta progresiva de componentes de almacenamiento, una pieza crítica cuando hablamos de distribución de paquetes, metadatos y contenido asociado a actualizaciones y descargas.

Para el mundo empresarial, el golpe no se limita a la experiencia de usuario en un PC. En su panel de estado, Microsoft indicó que, desde las 08:00 UTC del 7 de febrero, un subconjunto de clientes con recursos en West US podía experimentar indisponibilidad intermitente o retrasos en la telemetría, monitorización y datos de logs de algunos servicios alojados en las áreas afectadas del centro de datos. En otras palabras: durante parte del incidente, algunas organizaciones tuvieron que operar con visibilidad degradada justo cuando más se necesita observar qué ocurre.

Una semana especialmente incómoda para la fiabilidad percibida de Azure

El contexto agrava la lectura del suceso. Apenas unos días antes, entre el 2 y el 3 de febrero, Azure ya había atravesado una interrupción prolongada que afectó a operaciones de gestión de servicios y, posteriormente, a Managed Identities, un componente clave en autenticación y automatización en entornos cloud. El propio historial de estado de Azure describe una cadena de eventos iniciada el 2 de febrero a las 19:46 UTC, con mitigaciones, re-habilitaciones y un pico posterior de impacto sobre el servicio de identidades gestionadas, especialmente en regiones como East US y West US.

Medios del sector cifraron aquel episodio en más de 10 horas de afectación global en distintas capas operativas —desde el ciclo de vida de máquinas virtuales hasta flujos dependientes de identidad—, subrayando cómo una corrección o cambio en componentes de plataforma puede amplificar el impacto cuando confluyen dependencias internas y reintentos masivos.

La coincidencia temporal de un fallo “lógico” (configuración y gestión de servicios) y otro “físico” (energía y recuperación de infraestructura) en menos de una semana alimenta una pregunta recurrente en los comités de riesgos tecnológicos: ¿qué pasa cuando un proveedor hiperescalares tropieza dos veces seguidas, por motivos distintos, en un intervalo corto? No porque sea excepcional que ocurran incidentes, sino porque obliga a revisar supuestos de continuidad que a menudo se dan por hechos.

Lecciones que reaparecen cada vez que la nube se vuelve tangible

En términos de resiliencia, el episodio vuelve a poner sobre la mesa tres ideas conocidas, pero no siempre aplicadas:

1. La redundancia no es lo mismo que la continuidad automática. Tener respaldo energético o sistemas duplicados reduce riesgos, pero la “transición perfecta” es difícil en infraestructuras complejas, especialmente cuando entran en juego estados intermedios de almacenamiento y balanceo.
2. El “multi-región” debe ser real, no decorativo. Copias de seguridad y réplica son imprescindibles, pero los servicios críticos solo sobreviven a un evento regional si pueden operar en otra geografía con procedimientos y automatismos probados.
3. La observabilidad también es un punto único de fallo. Si la telemetría se retrasa o se degrada, conviene disponer de validaciones externas (monitorización fuera del proveedor o señales independientes) para evitar decisiones a ciegas.

Microsoft no detalló públicamente el alcance exacto por cliente ni el número de servicios empresariales afectados en West US más allá de su comunicación de “subconjunto de clientes” y del impacto en operaciones de Store/Update, pero sí dejó claro el mensaje operativo: el incidente fue físico, el respaldo se activó y la recuperación dependía de la estabilización progresiva del almacenamiento y servicios relacionados.

Preguntas frecuentes

¿Qué significa el error 0x80244022 en Windows 11 durante una caída de Microsoft?
Suele indicar que Windows Update o Microsoft Store no logran completar la conexión con los servicios de actualización/descarga. Durante incidencias en centros de datos o en la infraestructura de distribución, puede aparecer aunque el equipo esté correctamente configurado.

¿Puede una caída en Azure West US afectar a Windows Update y Microsoft Store fuera de esa región?
Sí. Aunque el incidente se localice en una región, algunos componentes y flujos de distribución pueden tener dependencias regionales o sufrir efectos indirectos por congestión, reintentos y recuperación escalonada.

¿Cómo se prepara un plan de continuidad ante un fallo eléctrico en un centro de datos cloud?
Con arquitectura multi-región, procedimientos de failover probados, copias de seguridad verificadas, y monitorización independiente. En entornos críticos, también se recomiendan pruebas periódicas de recuperación (DR drills).

¿Qué deben revisar las empresas tras dos incidentes seguidos en Azure (identidad y energía)?
Conviene auditar dependencias (identidad, almacenamiento, colas, extensiones), revisar límites de reintentos, comprobar que el despliegue multi-región es operativo y no solo documental, y validar tiempos reales de recuperación (RTO/RPO).

vía: cybersecuritynews