Durante años, la promesa de Cloudflare ha sido casi invisible para el usuario final: acelerar webs, frenar ataques y hacer que Internet “simplemente funcione”. Precisamente por eso, cuando la compañía falla, el impacto se siente como un apagón raro y desconcertante: páginas en blanco, errores 5xx, servicios que “no cargan” y una cascada de quejas en redes sociales.

Ese efecto volvió a repetirse el viernes 19 de diciembre de 2025, cuando múltiples sitios empezaron a devolver errores 502 (Bad Gateway) y el problema se extendió a escala global. En España, medios tecnológicos como El Chapuzas Informático relataron cómo la incidencia arrancó a media tarde y se prolongó durante horas, afectando tanto a webs como a servicios online que dependen de la red de la compañía.

Lo llamativo es que, ese mismo 19 de diciembre, Cloudflare publicó un artículo poco habitual por el tono: directo, autocrítico y con un mensaje claro de urgencia. La empresa anunció una iniciativa interna a la que ha puesto nombre de “emergencia”: “Code Orange: Fail Small” (“Código Naranja: fallar pequeño”). Es decir, asumir que los errores ocurren, pero evitar que se conviertan en una caída global.

Dos incidentes previos y una semana “caliente” en la red

El contexto importa. Cloudflare venía de dos incidentes graves en pocas semanas:

• 18 de noviembre de 2025: la red sufrió fallos significativos durante aproximadamente 2 horas y 10 minutos. Según el post-mortem, el origen estuvo en un error en la generación de un archivo de funcionalidades asociado a Bot Management, que acabó afectando a numerosos servicios. El síntoma para el usuario fue el clásico: páginas que devolvían errores y tráfico que no llegaba a su destino.
• 5 de diciembre de 2025: el segundo golpe llegó con una interrupción más breve (en torno a 25 minutos), pero con un dato que encendió todas las alarmas: afectó aproximadamente a un 28 % del tráfico HTTP servido por Cloudflare. Esta vez el desencadenante estuvo relacionado con un cambio de seguridad aplicado con urgencia en el contexto de una vulnerabilidad crítica en el ecosistema React.

Con ese historial tan reciente, la incidencia del 19 de diciembre no se percibió como “una mala tarde”, sino como una señal de que algo estructural debía cambiar: menos velocidad de despliegue a ciegas, más control… aunque eso suponga renunciar a parte del “instantáneo”.

Qué significa “Code Orange” en Cloudflare

Cloudflare describe “Code Orange” como un estado de máxima prioridad interna: el trabajo para reforzar la resiliencia pasa por delante de casi cualquier otra cosa, permitiendo que equipos de distintas áreas colaboren sin fricciones y pausando iniciativas menos urgentes. La empresa subraya que solo había declarado algo similar en una ocasión anterior.

El objetivo de fondo se resume en una idea sencilla, casi de ingeniería civil aplicada a la red: si algo se rompe, que se rompa en pequeño. Que no se lleve por delante el plano de control, ni el panel de gestión, ni cientos de ciudades a la vez.

El punto crítico: los cambios de configuración que se propagan en segundos

La raíz que Cloudflare identifica como “patrón común” es especialmente incómoda, porque forma parte de su ADN: la capacidad de desplegar cambios de configuración globales en cuestión de segundos.

Según explica la compañía, su sistema interno (al que se refiere como Quicksilver) permite que un cambio —por ejemplo, una regla, un ajuste de seguridad o una configuración— llegue a la inmensa mayoría de servidores rápidamente. Esa velocidad es útil para reaccionar ante amenazas, pero también convierte un error en un problema mundial “a la velocidad de la luz”.

Y aquí aparece la primera gran promesa del “Fail Small”: tratar la configuración como si fuese código.

Cloudflare ya despliega versiones de software con un método controlado y monitorizado, con “puertas” (gates) que permiten frenar o revertir si algo se tuerce. Primero se prueba con tráfico interno, luego se amplía por fases y, si aparecen anomalías, el sistema puede hacer rollback sin que nadie tenga que improvisar a mano.

Lo que no hacía —y ahora se compromete a hacer— es aplicar ese mismo rigor a los cambios de configuración. La meta es que cualquier modificación que pueda afectar a cómo se sirve el tráfico pase por un proceso equivalente al de las actualizaciones de software, apoyándose en su marco de despliegue Health Mediated Deployments (HMD).

Fallar bien: “defaults” sensatos y degradación controlada

El segundo pilar del plan tiene menos glamour, pero suele marcar la diferencia entre una molestia y un desastre: definir modos de fallo razonables.

Cloudflare admite que, en incidentes recientes, un error en una pieza del sistema terminó afectando a una parte enorme de su stack, incluso al plano de control que usan los clientes para operar. En un ejemplo muy concreto, la compañía explica que si un módulo (como el de gestión de bots) falla, el comportamiento por defecto no debería ser “bloquear tráfico” o “romper”, sino degradar: usar valores por defecto validados, permitir el paso del tráfico con una clasificación menos precisa y evitar el pánico interno (“panics”) que derriba servicios.

Es una filosofía clásica en sistemas críticos: cuando todo va mal, mejor un servicio imperfecto que un servicio caído.

“Break glass” y dependencias circulares: cuando ni el cliente puede entrar

El tercer bloque apunta a un punto que muchos administradores han sufrido alguna vez: cuando hay una emergencia, lo peor es que los propios mecanismos de seguridad te impidan arreglarla.

Cloudflare habla de sus procedimientos “break glass” (literalmente, “romper el cristal”), un mecanismo que permite elevar privilegios de forma controlada para resolver situaciones críticas. Reconoce que, durante los incidentes, tardaron demasiado en resolver parte del problema porque algunas capas de seguridad y dependencias internas dificultaban el acceso a herramientas necesarias.

Además, cita un caso especialmente delicado: durante la incidencia del 18 de noviembre, Turnstile (su solución anti-bots sin CAPTCHA) dejó de funcionar, y como Cloudflare lo utiliza en el flujo de login del panel, algunos clientes no pudieron acceder al dashboard justo cuando más lo necesitaban.

Parte del plan consiste en eliminar dependencias circulares, facilitar accesos de emergencia bajo control y aumentar la frecuencia de simulacros internos para que, cuando llegue el siguiente incidente, no se descubran los problemas “en producción”.

Por qué el debate es mayor que Cloudflare

La relevancia de estas caídas no se entiende sin una realidad de fondo: Cloudflare es una pieza enorme del Internet moderno. La propia compañía ha señalado en informes públicos que ayuda a servir y proteger cerca del 20 % de los sitios web. Cuando algo así falla, no se cae una app: se tambalea una capa entera.

Y, mientras los usuarios se informan de caídas en X, Telegram o Reddit, en España también se aprecia un fenómeno paralelo: el auge de medios de nicho centrados en tecnología, redes sociales y Inteligencia Artificial. Webs como Noticias Inteligencia Artificial (noticias.ai) o RevistaCloud.com muestran cómo la audiencia busca explicaciones rápidas y especializadas cuando “Internet se rompe”, aunque sea tímidamente frente a gigantes mediáticos.

Cloudflare, por su parte, intenta cerrar el círculo: pide disculpas, admite estar “avergonzada” por el impacto y promete cambios medibles en el corto plazo. Su objetivo declarado es que, antes de que termine el primer trimestre de 2026, los sistemas críticos queden cubiertos por despliegues monitorizados de configuración, mejores modos de fallo y procedimientos de emergencia más eficaces.

La cuestión que queda en el aire no es si volverá a haber incidentes —en redes de este tamaño, sería ingenuo negarlo—, sino si el próximo error quedará contenido… o volverá a convertirse en un trending topic global.

---

Preguntas frecuentes

¿Qué es el error 502 (Bad Gateway) y por qué aparece cuando falla Cloudflare?
Suele indicar que el servidor intermediario (gateway) no ha podido obtener una respuesta válida del servidor de origen o de un componente intermedio. En una caída o degradación de red, puede manifestarse como errores 502/5xx o páginas en blanco.

¿Qué significa “Code Orange: Fail Small” y cómo puede afectar a los usuarios de webs?
Es un plan de resiliencia para que los fallos no se propaguen globalmente: despliegues por fases de cambios de configuración, reversión automática si hay anomalías y comportamientos por defecto que prioricen mantener el tráfico funcionando.

¿Cómo puede prepararse un medio digital o un ecommerce ante caídas de un CDN o proveedor de seguridad?
Con planes de continuidad: monitorización independiente, páginas de contingencia, estrategias multi-proveedor (cuando sea viable), procedimientos internos para cambios urgentes y acceso preparado (tokens/API) para actuar incluso si el panel principal falla.

¿Por qué cada vez se habla más de “centralización” cuando hay una caída de Cloudflare?
Porque muchas webs y servicios concentran rendimiento y seguridad en pocos proveedores. Eso mejora eficiencia, pero amplifica el impacto cuando una pieza clave tiene un problema.

vía: blog.cloudflare