Se produce una interrupción en la red global de Cloudflare

• En la red global de Cloudflare se produjo una degradación del rendimiento de servicios internos, lo que afectó de forma intermitente a varios servicios
• Servicios principales como Access, Bot Management, CDN/Cache, Dashboard, Firewall, Network, WARP y Workers sufrieron una interrupción temporal
• El equipo de ingeniería identificó el problema y avanzó con las correcciones, y los servicios de WARP y Access fueron los primeros en recuperarse
• Después, a nivel mundial, la tasa de errores y la latencia volvieron gradualmente a niveles normales, y el servicio de dashboard también fue restaurado
• Actualmente todos los servicios operan con normalidad y el incidente está completamente resuelto

---

Resumen del incidente

• Cloudflare sufrió una degradación del rendimiento de servicios internos (Internal Service Degradation), lo que provocó interrupciones intermitentes en algunos servicios
  • Entre los servicios afectados estuvieron Access, Bot Management, CDN/Cache, Dashboard, Firewall, Network, WARP y Workers
  • La empresa inició de inmediato las labores de recuperación y mantuvo actualizaciones continuas sobre el avance de la resolución

Identificación del problema y respuesta inicial

• Cloudflare confirmó la degradación interna del servicio mientras se encontraba en la fase de investigación (Investigating)
  • Algunos clientes experimentaron errores intermitentes y latencia
  • El equipo de ingeniería trabajó en paralelo en el análisis de la causa y en la recuperación
• Después identificó la causa del problema (Identified) e inició las correcciones
  • Durante la corrección, el acceso a WARP en la región de Londres se deshabilitó temporalmente, por lo que los usuarios de esa zona experimentaron fallas de conexión a Internet

Progreso en la restauración del servicio

• Tras las correcciones, los servicios de Access y WARP fueron los primeros en recuperarse, y la tasa de errores volvió a los niveles previos al incidente
  • El acceso a WARP en la región de Londres fue reactivado
• Después continuaron las labores de restauración para los clientes de Application Services
  • Se desplegaron cambios para restaurar el servicio de dashboard
  • Aunque algunos clientes seguían teniendo problemas para iniciar sesión o usar el dashboard, se resolvieron con correcciones adicionales

Estabilización de toda la red

• A nivel mundial, la tasa de errores y la latencia (latency) fueron disminuyendo gradualmente hasta volver a niveles normales
  • El cálculo de puntuaciones de Bot Management (bot scores) se vio afectado temporalmente, pero se normalizó durante el proceso de recuperación
  • El equipo de ingeniería eliminó los errores restantes y aceleró la recuperación de toda la red
• Más tarde, todos los servicios volvieron a funcionar con normalidad y la tasa de errores y la latencia quedaron completamente normalizadas

Cierre del incidente y acciones posteriores

• Cloudflare confirmó que todos los servicios están operando con normalidad y dio por cerrado el incidente
  • Actualmente no hay cambios adicionales de configuración, y la plataforma sigue siendo monitoreada de cerca
  • Está en curso una investigación posterior al incidente (post-incident investigation) sobre la causa, cuyos resultados se publicarán más adelante
• Esta interrupción quedó registrada como un incidente que afectó a toda la red global

[GN⁺]

Comentarios de Hacker News

• Alguien compartió un comando con el que cualquiera que tenga un token de API de Cloudflare puede desactivar el proxy de CF
  Con curl se puede obtener el zone ID y los registros DNS, y luego hacer una petición PATCH para establecer "proxied": false
  Pero hay que tener cuidado con la pérdida de certificados SSL, la degradación de seguridad/rendimiento y el riesgo de exponer la IP del backend

  • Si solo tienes la antigua Global API Key, puedes usar los headers X-Auth-Email y X-Auth-Key
    Y si configuraste reglas para permitir solo tráfico de Cloudflare, también hay que desactivarlas temporalmente
  • Pensé que debería usar este método la próxima vez, pero como no había creado un token de API con anticipación, no me quedó otra que esperar
    Por suerte, ahora ya volvió a estar en línea
  • Yo lo resolví con el provider de Terraform, pero este método es útil para quienes no pueden acceder al dashboard
  • Buen tip. Como referencia, en curl las peticiones GET son el valor predeterminado, así que no hace falta -X GET
    Si usas -d, automáticamente pasa a ser POST, y para PATCH sí corresponde -X PATCH
  • Si activas Cloudflare WARP, algunos sitios vuelven a funcionar. 1.1.1.1 probablemente tenga un efecto parecido
    Aun así, incluso después del tunneling, algunos sitios seguían caídos parcialmente

• Según explicó el CTO de Cloudflare, un bug potencial en el sistema de bloqueo de bots se descontroló tras un cambio de configuración y provocó una caída en toda la red
  En la fuente explica que no fue un ataque, sino un problema interno

  • Sorprende que las grandes empresas todavía no desplieguen los cambios de configuración de forma gradual
    Tanto el código como la configuración son datos, y se sigue repitiendo el patrón de desplegar todo globalmente de una vez y causar caídas masivas
  • Ojalá esta información clave hubiera estado al principio de los comentarios. Fue difícil encontrarla entre todas las especulaciones sobre un ciberataque
  • Por un solo cambio de configuración, la acción de CF cayó 4%. Me da curiosidad el impacto económico que este tipo de incidentes tiene sobre toda la industria

• Un colega vino corriendo de repente y dijo que, justo después de cambiar una configuración de Cloudflare, el sitio se cayó, así que se asustó pensando que él lo había roto
  Dijo que al ver esta publicación se sintió aliviado

  • Le hice la broma de: “es peor que eso, tú tumbaste todo Cloudflare”
  • Aunque, ¿y si de verdad sí? Antes ya pasó algo parecido con la gran caída de Fastly, así que la sospecha sigue ahí
  • Me pregunto si existe una palabra exacta para esa extraña sensación de alivio al saber que no fue por culpa de alguien
  • Tal vez ese colega sí era empleado de Cloudflare
  • A mí también me llegaron decenas de mensajes de clientes diciendo que el sitio no funcionaba, y como ayer había cambiado una configuración, me entró el pánico
    Cuando vi el mensaje “Cloudflare down”, sentí un alivio genuino

• Revisándolo desde Países Bajos, casi todos los servicios estaban caídos
  Tampoco se podía entrar al dashboard de Cloudflare, y lo mismo pasaba con el dashboard de Betterstack
  Irónicamente, la página de estado sí seguía viva, así que no podían avisarles a los clientes

  • Me pasó lo mismo. La razón por la que HN seguía funcionando es que no usa Cloudflare
    Escribí un post que dice: “si no lo necesitas, no lo pongas detrás de Cloudflare”
  • Cada año recordamos lo riesgoso que es depender demasiado de AWS o Cloudflare, pero no es fácil reemplazarlos
    Aun así, cuando ocurre una caída grande como esta, los clientes suelen mostrarse sorprendentemente comprensivos
  • No es que el dashboard de Cloudflare estuviera completamente muerto, sino que si insistías lo suficiente podías desactivar el proxy
    Me tomó unos minutos, pero separé hcker.news de CF
  • Viendo este tipo de situaciones, parece que habría una oportunidad de negocio para un servicio que aloje páginas de estado en un VPS local
  • En mi side project Total Real Returns,
    puse abajo un widget de disponibilidad en tiempo real enlazado a una página de estado externa
    Puedes tomar como referencia el SVG de estado y la página de estado externa

• Cuando Cloudflare o AWS se caen, da cierta satisfacción ver que mis servicios self-hosted siguen funcionando perfectamente
  En este momento soy más estable yo que su disponibilidad de 99.999%

  • Incluso mi humilde sitio personal siguió vivo durante las caídas de AWS, Azure y Cloudflare
    Ahora me dieron ganas de ponerle un uptime tracker
  • Mi sitio self-hosted sí se cayó por culpa del proxy de Cloudflare. Qué bajón
  • Las empresas tradicionales están viendo que sistemas como Oracle o SAP siguen funcionando, mientras que solo se detienen los nuevos servicios basados en la nube
    Es una lección que las startups de SaaS deberían aprender
  • Mucha gente pregunta cómo manejar el DNS. Yo también estoy alojando en una Raspberry Pi, y justo había migrado el DNS a Cloudflare, así que
    me da risa, pero también una rara satisfacción, que mi pequeño sitio se haya caído

• Últimamente parece que los grandes incidentes de infraestructura están aumentando mucho. Tanto AWS como Cloudflare están quedando muy por debajo de su SLA

  • Coincide con el momento en que las grandes empresas hicieron despidos masivos y dijeron que los reemplazarían con IA
  • Este tipo de caídas te hace ver que la cantidad de ‘9’ del SLA no significa nada
    No es tiempo real de disponibilidad, sino solo una cifra definida arbitrariamente por la empresa
  • Alguien lo llama “vibe code theory”. Es una teoría medio en broma que dice que, mientras más código hecho por intuición haya, más bugs y caídas habrá
  • También hay análisis que apuntan a una cultura de desplegar con prisas, por la combinación entre la congelación de despliegues de fin de año y la presión por cumplir objetivos de Q4
  • O una visión más conspirativa: que quizá sea un ciberataque a nivel estatal

• Si Cloudflare o AWS se caen, se detiene la mitad de la web, y el problema de la centralización es grave

  • A los usuarios tampoco parece importarles demasiado. Como sienten que “se cayó internet”, cada servicio individual puede evadir responsabilidad
    Esa es una de las razones por las que esta estructura no cambia
  • En la defensa contra DDoS operan economías de escala. Cuantos más clientes tienes, más ancho de banda y mayor capacidad defensiva acumulas
    A los CDN pequeños les cuesta competir, y al final se forma una estructura de monopolio natural
    Que Cloudflare ofrezca un plan gratuito fue una estrategia para aprovechar ese efecto de red
  • Más que un punto único de falla, preocupa que esta centralización pueda distorsionar el futuro de los estándares web y del hosting autónomo
    Además, también podría convertirse en un objetivo concentrado para la censura gubernamental
  • Let's Encrypt también representa un riesgo potencial.
    Dos tercios de la web dependen de él, la vida útil de los certificados se acorta cada vez más, y si hubiera un hackeo o una caída, toda la web podría quedar paralizada
    Hoy es una organización bienintencionada, pero no hay que olvidar que en su momento también se pensaba eso de Google
  • Después del boom de AWS, los desarrolladores pasaron a depender solo de la nube en lugar de servidores dedicados
    Hay muchos respaldos a nivel software, pero se perdió el sentido común de hacer multi-hosting a nivel de infraestructura

• Irónicamente, DownDetector también usa Cloudflare Turnstile, así que se cayó junto con lo demás

  • También se dispararon los reportes de caída de AWS, pero probablemente sean falsos positivos
  • Yo también vi ese comportamiento

• Fue llamativo el mensaje visual de disculpa de Cloudflare: “Your browser: Working / Host: Working / Cloudflare: Error”

  • Es la primera vez que veo esa pantalla. Aunque en mi caso el “Host” era Cloudflare Pages, así que el significado era ambiguo
  • Da un poco de risa que, si haces clic en “Cloudflare”, todavía te diga que el problema es del servidor del cliente
  • Me gustó que el mensaje fuera honesto, aunque los usuarios solo respondían con cosas como “arréglenme el wifi”
  • Aun así, al menos permitía entender claramente la situación y actuar en consecuencia. Si hacía falta, se podía desactivar el proxy para minimizar el impacto en el servicio
  • Yo también pasé una hora revisando logs antes de darme cuenta de que el problema no era mi servidor

• Los sitios que usan Cloudflare Challenge (“I’m not a robot”) también se detuvieron con errores HTTP 500
  Aparecía el mensaje “desbloquea challenges.cloudflare.com”

  • Últimamente el manejo de errores es demasiado deficiente. Las empresas intentan evadir responsabilidad culpando al usuario
    o solo muestran pantallas de carga infinitas. En realidad, el backend devuelve errores claros, pero el frontend los oculta
    Hace poco incluso vi un caso donde un error de contraseña demasiado larga se mostraba como “ese correo ya está en uso”
  • Por esta caída también se detuvo la búsqueda con IA de chat.bing.com (GPT5)
    Irónicamente, terminó siendo una situación en la que había que demostrarle a la IA que uno era humano
  • Algunos sitios, como pinkbike, mostraban el mensaje “you have been blocked”
  • O sea, no solo bloquearon a los robots, también a la gente real /s
  • Parece que el frontend interpreta erróneamente que el usuario bloqueó el dominio por DNS o con alguna extensión
    Da risa esa negación estilo /s de que Cloudflare Captcha jamás podría caerse