Cuando la nube de tu proveedor se cae, tu negocio se cae con ella: la peor racha de outages de 2026

El 3 de septiembre de 2026, ChatGPT, Claude y Grok sufrieron interrupciones simultáneas durante aproximadamente 90 minutos. Cada servicio atribuyó el incidente a causas diferentes: OpenAI reportó un error de enrutamiento, Anthropic un problema de infraestructura sin confirmar que fuera Azure, y xAI (Grok) reportó una falla en su data center de Memphis. Microsoft no registró un incidente de Azure de nivel amplio en ese período, y ninguno de los proveedores confirmó una causa compartida. Downdetector registró más de 37,000 reportes sobre ChatGPT y Codex, además de miles sobre Claude y Grok, según el análisis publicado por Shattered.io. Tres productos de tres empresas distintas, compitiendo entre sí, cayeron juntos porque comparten la misma infraestructura de nube por debajo. Ese es el problema que importa a cualquier empresa que dependa de un proveedor externo para facturar, cobrar o atender clientes: la falla no está en tu código ni en tu equipo, está en una capa que no controlas.

No fue un incidente aislado. Fue el cuarto de una racha que empezó en mayo.

Cuatro proveedores, cuatro fallas, unos meses

Fecha 2026	Proveedor	Qué falló	Duración	Causa reportada
7 al 8 de mayo	AWS	Múltiples servicios en us-east-1	De 20 a 28 horas según el corte de medición	Falla de enfriamiento, apagado automático por temperatura
7 al 14 de agosto	Cloudflare	R2, Durable Objects, Workers KV, Workers AI	13 incidentes en 8 días	Cadena que arrancó con una falla de escritura en R2
20 de agosto	Google Cloud	33 productos en us-west1	2 horas 22 minutos	Mantenimiento de fibra con reenrutamiento automático fallido
3 de septiembre	Microsoft Azure	ChatGPT, Claude, Grok, Copilot	Aproximadamente 90 minutos	Falla en infraestructura compartida de East US

La falla de AWS es la que más costó parar: según la cobertura de Network World sobre el evento, varias unidades de enfriamiento fallaron en una sala de datos que sirve a la zona de disponibilidad use1-az4, los servidores se apagaron solos al superar el umbral de temperatura, y el enfriamiento no se restauró a capacidad total hasta unas 20 horas después; la recuperación completa de los servicios más pesados en datos tomó hasta 28 horas según otros rastreadores del incidente.

La de Cloudflare es la más reveladora de un patrón, no de un evento único: el 7 de agosto una escritura a un grupo de buckets de R2 falló en la región Este de Norteamérica entre las 14:52 y las 17:02 UTC, y de ahí en adelante el panel de estado de la empresa acumuló trece incidentes distintos en ocho días, entre R2, Durable Objects, Workers KV y Workers AI, con reportes de usuarios de datos no restaurados en al menos un bucket, según el hilo de la comunidad de Cloudflare sobre el incidente.

La de Google Cloud tuvo una causa más mundana: mantenimiento rutinario de fibra que salió mal. El propio reporte de incidente de Google Cloud documenta que entre las 08:00 y las 10:22 hora del Pacífico del 20 de agosto, clientes en us-west1 vieron tiempos de espera, fallas de aprovisionamiento y errores elevados en 33 productos, desde Compute Engine hasta BigQuery, porque el sistema automático diseñado para reenrutar el tráfico ante ese tipo de falla no lo hizo.

Y no es percepción: la red en general está más inestable. Cisco ThousandEyes contó 687 eventos globales de interrupción de red durante la semana del 31 de agosto al 6 de septiembre de 2026, un 6% más que los 649 de la semana anterior, según el reporte de Network World sobre el estado de la red en 2026. En Estados Unidos las fallas de proveedores de internet subieron 21% en esa misma semana. Ninguna cifra ahí te dice cuándo te va a tocar. Te dice que la probabilidad no está bajando.

Por qué esto no es un problema de "elegir mejor proveedor"

Los cuatro proveedores de la tabla no son actores marginales: entre Amazon, Microsoft, Google y Cloudflare corre buena parte de la infraestructura sobre la que están construidas las aplicaciones que factura, cobra o atiende clientes de cualquier empresa mediana en México. No hay una alternativa que esté libre de este riesgo, y cambiar de proveedor no resuelve el problema de fondo: la disponibilidad de tu operación depende de una infraestructura que otro opera, con sus propios incentivos, su propio ritmo de mantenimiento y sus propios errores humanos.

Lo que sí cambia el resultado es qué tan expuesta está tu operación cuando ese proveedor falla. Una empresa cuyo sistema de facturación tiene un solo punto de entrada, sin cola de reintentos ni aviso al cliente, pierde ventas cada minuto que el proveedor está caído. Una que diseñó ese mismo flujo con una cola que reintenta automáticamente y notifica al equipo de cobranza, pierde tiempo de respuesta, no ventas.

Dónde el multicloud es la respuesta equivocada

La reacción reflejo ante esta racha es "hay que estar en dos nubes". Para la mayoría de las empresas medianas en México, eso es exactamente el consejo que no deben seguir sin antes hacer el diagnóstico.

Ignia Cloud, proveedor mexicano de infraestructura, describe el fenómeno como "fatiga de multicloud": empresas con facturas variables e imposibles de proyectar, cargos por salida de datos que castigan justo el intento de moverse, y una dependencia técnica de cada proveedor que termina limitando en vez de dar libertad. Su CEO, Esteban Rey, lo resume así: "hoy los directores financieros buscan no sólo tecnología, sino certeza financiera", porque el modelo de "paga por lo que usas" se convirtió en "paga por lo que no puedes controlar", según la cobertura de la posición de Ignia Cloud. Clouxter, otra firma mexicana de cómputo en la nube, plantea el mismo dilema desde el lado de la complejidad operativa en su análisis sobre multicloud como estrategia de resiliencia o trampa: duplicar proveedores sin gobierno claro sobre quién administra qué añade fricción y costo antes de sumar resiliencia real.

Una pyme que corre su sistema de punto de venta y su contabilidad sobre un solo proveedor no necesita una arquitectura de tres nubes: necesita saber cuánto tiempo puede estar caída antes de que eso le cueste dinero de verdad, y tener un plan simple para ese escenario. Multiplicar proveedores sin ese diagnóstico previo sólo multiplica la factura y el número de paneles de estado que alguien tiene que vigilar.

Qué revisar en tu operación, en orden

1. Identifica qué proceso realmente se detiene si tu proveedor cae. No es lo mismo que se caiga el sitio de contenido que el proceso de cobranza o el sistema que factura. Empieza por el que mueve dinero.
2. Pregunta a tu proveedor de nube o de plataforma cuál es su historial real de incidentes, no su promesa de disponibilidad. Los estados de servicio públicos de Cloudflare, Google Cloud, AWS y Azure son gratuitos y muestran el patrón real, no el marketing.
3. Revisa si tu sistema reintenta o se cae de golpe. Una cola de reintentos con aviso al equipo cuesta una fracción de lo que cuesta una arquitectura multicloud, y cubre la mayoría de los apagones de menos de dos horas, que son los más comunes según la tabla de arriba.
4. Define un tiempo de tolerancia por proceso, no uno genérico para toda la empresa. Cuánto tiempo puede estar caída la facturación antes de perder ingresos es una pregunta distinta a cuánto tiempo puede estar caído el blog corporativo.
5. Pon monitoreo activo sobre tus propios flujos críticos, no sólo sobre el estado del proveedor. Un proveedor puede reportarse "operativo" mientras tu integración específica con él ya falló.
6. Antes de evaluar un segundo proveedor, mide el costo real de salida de datos y de duplicar operación. Es el punto que las firmas mexicanas de nube están señalando: el multicloud sin ese cálculo previo genera facturas impredecibles, no resiliencia.

Dónde esto no aplica

Si tu operación ya vive dentro de la nube de un proveedor con contratos de nivel de servicio negociados, equipo dedicado a infraestructura y presupuesto para redundancia real, el ejercicio de arriba ya lo hiciste o lo tienes delegado a tu equipo de TI. Y si tu empresa no factura ni cobra a través de un sistema digital todavía, el problema urgente no es la resiliencia de la nube: es que sigues expuesta a fallas más baratas de resolver, como el papel y las hojas de cálculo que documentamos en Nearshoring en México: la condición que ya no es negociable es dejar el papel y el Excel. Resolver eso primero.

También vale la pena revisar cómo estás leyendo el contrato con tu proveedor actual antes de sumar otro: no sólo el precio de cómputo, sino qué te cobra por moverte, tema que tratamos en Cómputo más barato, memoria más cara: por qué no puedes leer tu contrato de nube como un solo número. Y si la dependencia que te preocupa no es de nube sino de un proveedor externo de soporte o de red, el mismo principio de diagnóstico aplica al caso que cubrimos en Tu proveedor de soporte remoto o tu router pueden ser la puerta de entrada.

Si nunca has hecho este diagnóstico sobre tu propia operación, revisamos con tu equipo qué sistema se cae primero y construimos el plan de contingencia proporcional a tu tamaño. No es un ejercicio de comprar más nube: es saber, antes del próximo apagón, exactamente qué se detiene y cuánto te cuesta cada minuto que dura.

Fuentes

• ChatGPT, Claude, Grok Down 90 Min as Azure Fails, Shattered.io
• AWS hit by US-East-1 outage after data center thermal event, Network World
• 2026 network outage report and internet health check, Network World
• Incident details, Google Cloud Service Health
• R2 data loss after ENAM incident, Cloudflare Community
• Ignia Cloud lidera la transición hacia la soberanía digital ante el fenómeno del "Multi-cloud Fatigue", MNI Noticias
• Multi-Cloud: ¿estrategia de resiliencia o trampa de complejidad?, Clouxter