Entre el 7 y el 14 de agosto de 2026, la página de estado de Cloudflare registró 13 incidentes en 8 días: escrituras que fallaban en R2, caídas de Durable Objects, errores en Workers KV y Workers AI, y degradación de red en cuatro continentes. Ninguno tuvo la escala del apagón global de noviembre de 2025, pero la frecuencia reabrió una pregunta incómoda para cualquiera que corra infraestructura: qué pasa cuando el edge que te sirve el tráfico y el object storage donde guardás tus datos viven en el mismo bolsillo.
La caída de R2 de Cloudflare del 7 de agosto de 2026 fue una pérdida de disponibilidad de escritura en la región ENAM (Eastern North America) entre las 14:52 y las 17:02 UTC, dentro de una racha de 13 incidentes en 8 días que tocó R2, Durable Objects, Workers KV, Workers AI, Magic Transit y la red. R2 es el object storage S3-compatible de Cloudflare; el episodio expuso el riesgo de concentrar edge y almacenamiento en un único proveedor.
¿Qué falló en Cloudflare entre el 7 y el 14 de agosto de 2026?
Fallaron subsistemas distintos, uno tras otro, sin una única causa raíz que los encadenara. La racha arrancó con las escrituras de R2 en ENAM el 7 de agosto y se estiró hasta una caída de disponibilidad de Durable Objects y Workflows el 14. En el medio hubo errores 503 en Magic Transit, fallas de autenticación en el MCP Server Portal, problemas con modelos específicos en Workers AI y picos de 5xx regionales.
Según el análisis publicado por shattered.io, fueron 12 incidentes menores y 1 mayor (una inclusión en Spamhaus que afectó Email Security). La distribución geográfica de los cortes de red da la pauta de que no fue un solo evento:
| Fecha (2026) | Servicio | Qué pasó |
|---|---|---|
| 7 ago | R2 Object Storage | Caída de escrituras en buckets de ENAM (14:52–17:02 UTC) |
| 8 ago | Red (Estambul) | Pérdida de conectividad por fibra oscura |
| 11 ago | Red (Londres) / Analytics | Errores de conectividad y demoras |
| 12 ago | Email Security | Impacto por listado en Spamhaus (mayor) |
| 13 ago | Magic Transit, Workers KV, MCP Portal, Workers AI | 503, errores de request, fallas de auth, modelos con errores |
| 14 ago | Durable Objects/Workflows y red | Caída de disponibilidad; 5xx en Kuwait, Bangkok, Yakarta, Dammam; congestión en EE.UU. y Querétaro |
Como resume el propio análisis: "cuando el status page muestra cuatro incidentes el mismo día, como pasó el 13 y el 14 de agosto, son cuatro subsistemas degradándose de forma independiente, no una causa raíz en cascada". Esa es la parte que asusta: no es un bug puntual, es la densidad de la plataforma.
¿Por qué la caída de R2 pesa más que un corte de CDN?
Porque un CDN caído devuelve errores efímeros, pero un object storage que rechaza escrituras puede dejarte con datos a medio subir o inaccesibles justo cuando tu aplicación depende de él. R2 es el almacenamiento donde muchos proyectos guardan imágenes, backups, artefactos de build y salidas de procesos. Si el mismo proveedor te da el edge (Workers, CDN) y el storage (R2), un mal deploy en su red puede afectar las dos capas a la vez.
Ahí está el nudo del título: el edge y el object storage en el mismo bolsillo. Cuando ambos comparten plano de control, credenciales y red, pierden la independencia de fallos que uno espera al separar responsabilidades. De acuerdo con el análisis de shattered.io, Cloudflare actuó como reverse proxy del 24,2% de todos los sitios web a fines de julio de 2026 y maneja más de un quinto del tráfico global de requests; concentrar tu storage ahí también suma tu proyecto a esa superficie compartida.
El caso comfy-storage: 67 GB que no volvieron
El resultado medible más crudo lo puso un cliente: reportó que un bucket de R2 llamado comfy-storage quedó con unos 67 GB sin restaurar varios días después del incidente de ENAM del 7 y 8 de agosto, según un hilo en la comunidad de Cloudflare. Al 15 de agosto, Cloudflare no había publicado un postmortem formal que confirmara pérdida permanente de datos en ese caso.
La lección no es "R2 es malo" —el episodio afectó a un subconjunto de buckets, no a todos—. La lección es de diseño de resiliencia: si tus datos viven en un único proveedor y no tenés una copia independiente, el día que ese proveedor tiene un mal día, vos también lo tenés, y no hay ticket que te devuelva los bytes.
¿Es un patrón o mala suerte? Marzo y noviembre de 2025
Es un patrón conocido: el camino de escritura de R2 ya había figurado en un incidente público en marzo de 2025. Según el postmortem reportado por BleepingComputer, aquella caída del 21 de marzo de 2025 (21:38–22:45 UTC, 1 hora y 7 minutos) fue por un error de rotación de credenciales: un ingeniero omitió el flag --env production al desplegar credenciales nuevas, que terminaron en un Worker de desarrollo en vez de producción. El resultado: 100% de las escrituras y ~35% de las lecturas fallando. Como remediación, Cloudflare pasó a exigir la firma de al menos dos ingenieros para cambios de credenciales de alto impacto.
El apagón global de noviembre de 2025
El corte más grande del período fue otro y más profundo. Un cambio rutinario de permisos en una base de datos hizo que una query de ClickHouse devolviera metadata de columnas duplicada, lo que generó un archivo sobredimensionado que disparó un panic en el proxy: thread fl2_worker_thread panicked: called Result::unwrap() on an Err value. Afectó el CDN core, Turnstile, Workers KV, el dashboard, Access y Email Security durante unas 6 horas. Distinta causa raíz que R2, mismo denominador: en una red tan densa, un cambio chico se propaga a muchos productos a la vez.
¿Qué podés desplegar en tu cloud server para no depender de un solo bolsillo?
Object storage S3-compatible self-hosted, más una réplica en un destino independiente. La API S3 se volvió un estándar de facto, así que podés correr tu propio almacén y replicarlo con herramientas estándar. Las opciones vigentes en 2026 (MinIO Community Edition quedó archivado en febrero de 2026) son:
- Garage: object storage distribuido escrito en Rust. Ships como un único binario sin dependencias externas, está pensado para despliegues geo-distribuidos en hardware modesto y tolera hasta ~200 ms de latencia entre nodos. Ideal para armar tu propio storage replicado entre datacenters.
- SeaweedFS: sistema de archivos distribuido inspirado en el paper Haystack de Facebook. Soporta objetos de tamaño ilimitado, una capa Filer con estructura de directorios y replicación active-active para escenarios geo-distribuidos.
- rclone: la navaja suiza de la replicación cross-provider. Con
rclone synccopiás todos los objetos de tu Garage (o de cualquier bucket S3-compatible) a otro destino S3-compatible, lo que te da una copia fuera de la superficie de fallo de tu proveedor principal.
Un patrón mínimo de respaldo cruzado, corriendo en un cron dentro de tu cloud server, se ve así:
# Réplica de tu bucket primario a un destino independiente
rclone sync primary:comfy-storage backup:comfy-storage \
--transfers 8 --checksum --log-file /var/log/rclone-comfy.log
La idea no es dejar de usar servicios administrados, sino que tu copia de verdad no viva en el mismo proveedor que tu operación diaria. Si te interesa el enfoque self-hosted, en el blog ya cubrimos "MinIO archivado: mc quedó en solo lectura y qué usar ahora" y "Celld: corré Durable Objects self-hosted coordinados por S3" como lecturas complementarias.
La lección: separá el edge del object storage
El takeaway concreto es tratar edge y almacenamiento como dominios de fallo distintos. No es una crítica a la ingeniería de Cloudflare —su tasa de incidentes hay que leerla contra el volumen que mueve—, sino una consecuencia de arquitectura: cuanto más apilás en un único proveedor, más comparte tu proyecto su suerte. Podés seguir usando su edge y, al mismo tiempo, tener tu object storage (o al menos su réplica) en infraestructura que no caiga con él. Un cloud server con Garage o SeaweedFS te da exactamente esa independencia, y desplegarlo en un VPS —por ejemplo, un Cloud Server— es cuestión de un binario y un poco de red.
Preguntas frecuentes
¿Cuántos incidentes tuvo Cloudflare en agosto de 2026?
Trece incidentes entre el 7 y el 14 de agosto de 2026, según su página de estado: 12 menores y 1 mayor. Tocaron R2, Durable Objects, Workers KV, Workers AI, Magic Transit, el MCP Server Portal y la red en varias regiones.
¿Qué pasó exactamente con R2 el 7 de agosto?
Fallaron las escrituras en un conjunto acotado de buckets de la región ENAM (Eastern North America) entre las 14:52 y las 17:02 UTC. La recuperación se extendió hacia el 8 de agosto.
¿Hubo pérdida de datos en R2?
Un cliente reportó en el foro de Cloudflare unos 67 GB sin restaurar en el bucket comfy-storage días después del incidente. Al 15 de agosto de 2026 Cloudflare no había publicado un postmortem formal que confirmara pérdida permanente en ese caso.
¿R2 es lo mismo que S3?
No, pero comparten la API. R2 es el object storage de Cloudflare y expone una API S3-compatible, lo que permite migrar o replicar datos con herramientas estándar como rclone hacia otros destinos S3-compatibles, incluidos los self-hosted.
¿Qué alternativa self-hosted puedo desplegar para no depender de un solo proveedor?
Garage y SeaweedFS son las opciones S3-compatibles self-hosted vigentes en 2026 (MinIO Community quedó archivado en febrero de 2026). Corren en tu cloud server y podés replicar entre ellas o hacia otro destino con rclone sync.
¿Conviene dejar de usar servicios administrados por esto?
No necesariamente. La recomendación es de resiliencia, no de reemplazo: mantené una copia independiente de tus datos fuera de la superficie de fallo de tu proveedor principal, para que un mal día de la plataforma no sea también el tuyo.
Cloud Serversby Donweb
Todo el poder de la nube a tus proyectos y aplicaciones.
Alojamiento ultra rápido, escalable y con alta disponibilidad.
- Performance que te sorprenderá
- Rápida escalabilidad y sin limitaciones
- Arquitectura de alta disponibilidad
- Soporte experto y ejecutivos de cuenta
- Pagos en tu moneda y facturación local
