Caída de Cloudflare: qué pasó, a quién afectó y cómo prepararte para la próxima

Ayer internet sonó a cortocircuito. Esa fue exactamente la sensación: pestañas recargando sin fin, aplicaciones que no iniciaban sesión y un desfile de 5xx recordándonos lo frágil que es todo cuando un proveedor clave tose. No fue “la web” entera; fue una pieza de infraestructura que muchos damos por descontada hasta que deja de estar—y de pronto medio ecosistema se queda sin respiración. Si alguna vez te preguntaste “¿qué pasaría si falla el CDN/WAF/DNS que tengo delante de todo?”, ya tuviste un spoiler.

Te dejo una guía completa sobre qué es CloudFlare y cómo funciona

Lo más relevante no fue solo el alcance (servicios enormes degradados a la vez), sino lo que pone en evidencia: el patrón de dependencia concentrada. Muchas empresas concentran CDN, WAF, Bot Management y DNS en el mismo proveedor por eficacia operativa y coste. Funciona genial… hasta que una actualización cruza mal con límites muy terrenales: RAM, cuotas, timeouts. Cuando ese engranaje se traba, el resto del mecanismo intenta compensar, se saturan colas, se disparan reintentos y lo que era un fallo puntual se convierte en una ola de errores acumulados.

Para los usuarios finales, los síntomas fueron claros: páginas que tardaban demasiado, retos de “estás seguro de que eres humano” que no terminaban, flujos de login rotos, APIs que devolvían 5xx, y apps populares reportando intermitencias. Para los equipos, el tablero de alertas explotó por latencia, tasa de errores y disponibilidad. Si estabas detrás de una capa anti-bots o de un WAF con inspección profunda, lo sufriste más: el camino hacia tu contenido era más largo y cada paso extra era un punto de quiebre.

¿Por qué esto importa? Porque una caída así no es “un rayo en cielo despejado”; es un recordatorio práctico de que la fiabilidad es una función de diseño, no un deseo. La diferencia entre drama y anécdota no está en el incidente, sino en cuánto tardas en mostrar algo útil, cobrar y explicar con calma qué pasa. Ahí se mide la madurez de un stack… y de un equipo.

Causa técnica sin rodeos: del “feature file” a los 5xx (explicado fácil)

La explicación corta: un cambio aparentemente menor en cómo se alimentaba de señales la capa de Bot Management desencadenó un crecimiento inesperado de un archivo/estructura (“feature file”) que el sistema usa para decidir si alguien es bot o humano. Ese crecimiento empujó límites de memoria y degradó componentes que, a su vez, alimentan otras piezas de la red. Resultado: efecto dominó. La IA que protege, si no está bien acotada, también puede tirar del hilo equivocado y deshacer el jersey.

Desgranándolo sin jerga innecesaria: los sistemas anti-bots combinan heurísticas, modelos y pipelines que procesan huellas del navegador, patrones de tráfico, retos de JavaScript y scores de reputación. Todo eso se resume en “features” que se consultan al vuelo. Si un despliegue cambia la cardinalidad o el volumen de esas features (por ejemplo, añadiendo campos, elevando granularidad o perdiendo limpieza de entradas), el archivo de referencia puede crecer más de la cuenta, invalidar cachés, forzar rehidrataciones y abrir una cascada de lecturas/escrituras. ¿Te suena a teoría? Ayer dejó de serlo.

En entornos distribuidos, los problemas raras veces se quedan en un solo sitio. Un microservicio que va al 100% de CPU empuja la cola, la cola obliga a reintentos, los reintentos multiplican las peticiones, las peticiones presionan al balanceador, el balanceador recalienta el edge… y así. La solución no es “quitar la IA” (sería ingenuo): es poner guardarraíles. Límites duros, cuotas por tenant, watchdogs que maten funciones cuando el ratio de errores excede umbrales, y circuit breakers que abran cuando determinada dependencia provoca más daño que beneficio.

Moraleja: si una característica “de seguridad” puede, en el peor caso, impedir servir contenido legítimo, entonces necesitas un modo degradado seguro (hablo de esto más abajo) que mantenga el sitio respirando aunque con menos defensas, antes que un apagón total.

Servicios afectados y cronología (horas clave y síntomas típicos)

La jornada dejó un patrón común en muchas plataformas:

• Inicio del incidente: subida de latencias y picos de 4xx/5xx intermitentes. Usuarios experimentando bucles de verificación humana, timeouts en logins y APIs que no respondían.
• Fase de impacto amplio: degradación visible en webs de alto tráfico, apps sociales, servicios de IA y juegos online. El síntoma más frecuente: páginas que “parecen vivas” pero no completan acciones críticas (checkout, login, pagos).
• Comunicaciones y mitigación: anuncios de incidencia, actualizaciones parciales, y—curiosamente—status pages de algunos servicios también con problemas, señal de que estaban dentro del mismo perímetro afectado.
• Recuperación progresiva: primero restablecimiento del tráfico en regiones, luego normalización del challenge/scoreo, después descenso de errores 5xx. Finalmente, nota de “monitoring” mientras se estabilizaban colas y repoblaciones de caché.

Si operabas un eCommerce, el golpe típicamente se tradujo en carritos que no avanzaban y callbacks de pago fallidos. En SaaS, soporte saturado y clientes preguntando si “les habían hackeado”. En medios, peaks de visitas a páginas estáticas que sí cargaban (home cacheada) y caída de rutas más dinámicas. En todos los casos, quedó claro que seguimos construyendo ciudades enteras sobre dos o tres autopistas: cuando una se corta, no basta con pitar; hay que tener desvíos señalizados.

Mi consejo para la próxima: documenta tu propia cronología interna. Hora exacta del primer síntoma, primeras métricas afectadas, hipótesis inicial, decisión de activar degradación, mensajes enviados y tiempos de recuperación. Ese “postmortem de bolsillo” vale oro para ajustar alertas y respuestas.

Lo que nos enseñó el incidente: dependencias invisibles y blast radius

Primera lección: dependencias invisibles. Muchos descubrieron que todo pasaba por el mismo túnel: CDN, WAF, DNS, Bot Management… Comodísimo hasta que no. No se trata de “huir” del proveedor, sino de diseñar pensando en fallos parciales. ¿Tienes rutas de escape? ¿Puedes degradar funciones sin apagar el sitio entero? ¿Tu DNS y tu status page viven fuera de la misma jaula?

Segunda: el blast radius. Si un ajuste en señales para un modelo puede desbordar memoria, necesitas feature flags de verdad, no solo booleanos simpáticos en un panel. Meter una función detrás de un flag sin límites es como poner una puerta giratoria en una autopista: si se atasca, te llevas por delante todo el tráfico. Los guardarraíles que sí funcionan: límites de QPS por servicio, colas con tamaños máximos y rechazo elegante, tasas de retry con backoff exponencial y jitter, y breakers que abran circuitos antes de colapsar.

Tercera: el dilema de la seguridad que cae. Paradójico pero real: el módulo hecho para proteger contra scraping y automatización termina empujando a los buenos al abismo. La solución no es “apagamos seguridad y a correr”, sino un modo ámbar: reglas mínimas de defensa (listas de bloqueo conocidas, rate limits conservadores, validaciones básicas) que permitan servir contenido durante la tormenta. Prefiero un sitio parcialmente expuesto durante minutos con límites estrictos, a un ecommerce muerto una hora en pleno pico.

Y cuarta: comunicación. Si tu status page cae con el proveedor, no tienes status page. Necesitas redundancia fuera del mismo perímetro y un canal sincronizado (newsletter, X, LinkedIn, email a clientes enterprise). Decir la verdad, pronto y con precisión, reduce tickets y salva reputación.

De la teoría a la práctica: tu plan de degradación en 7 pasos

1. Página estática fuera de banda. Mantén una landing estática cacheada en un origen alternativo (otro proveedor o un bucket público con CDN distinto). Debe explicar que hay incidencia, incluir el mínimo de SEO y ofrecer acciones útiles (contacto, estado, acceso a documentación offline).
2. Rutas críticas sin JS pesado. Ten versiones “ligeras” de /login, /checkout y /status que no dependan de recursos de terceros. HTML+CSS+un poco de JS vanilla es suficiente para sobrevivir.
3. Banner y UX de contingencia. No ocultes el problema: un banner claro reduce rebotes y evita que usuarios repitan acciones que van a fallar.
4. Toggle de features non-core. Conmutadores para apagar recomendaciones, personalización agresiva o terceros que no sean esenciales para cobrar o servir contenido.
5. Controles de caché y TTL sensatos. TTL más largos para assets inmutables; “stale-while-revalidate” para contenido semiestático; y bypass controlado para rutas dinámicas críticas.
6. Kill-switch independientes. Deben funcionar incluso si el panel principal está caído. Scripts o endpoints internos que fuerzan reglas mínimas o apagan módulos problemáticos.
7. Runbook de comunicación. Plantillas de mensajes para clientes, status y redes, con métricas concretas (qué afecta, qué no, ETA de la próxima actualización, vías alternativas).

Durante la incidencia, yo priorizo: mantener una cara pública útil (aunque sea básica), cobrar si es posible y capturar datos de contacto para retomar pedidos. Después, postmortem con foco en decisiones: ¿qué apagaste? ¿qué quedó activo? ¿qué métricas te hicieron actuar? Itera el runbook: el que no se prueba, no existe.

DNS, caché y “modo ámbar” de seguridad: servir algo antes que caer del todo

DNS. Si tu DNS está en el mismo proveedor que todo lo demás, ya sabes el riesgo. Configura al menos un plan de failover: zona replicada en un segundo proveedor (aunque sea activación manual), registros críticos listos para apuntar a un origen alternativo y TTL que te den margen (ni 5 segundos ni 1 día; piensa en minutos bien elegidos según tu tráfico). Automatiza lo que puedas, pero acepta que el “modo manual” es a veces el plan B más robusto.

Caché. La caché no es una capa mágica; es una decisión de producto. Identifica qué puedes servir en stale con seguridad: posts, fichas informativas, documentación, landing de precios. Define políticas “stale-if-error” y “stale-while-revalidate”. En un evento así, un 70% de tu tráfico puede quedar satisfecho con contenido viejo 5–30 minutos si se lo explicas bien al usuario.

Modo ámbar de seguridad. Establece por adelantado un set mínimo de reglas cuando la seguridad “inteligente” se vuelve un cuello de botella. Piensa en:

• Rate limits conservadores por IP/ASN para zonas críticas.
• Bloqueos de firmas conocidas (listas de reputación estáticas) que no dependan de modelos dinámicos.
• Desafíos livianos solo en endpoints sensibles, no en todo el sitio.
• Observabilidad reducida: si tus pipelines de logging/ML se ahogan, baja cardinalidad y conserva lo esencial.

Este modo debe activarse con un switch simple y revertirse igual de fácil. Documenta las condiciones de entrada/salida (por ejemplo: si error budget de la capa de seguridad se consume >X% en Y minutos, activa ámbar; cuando el p95 de latencia y la tasa de éxito vuelvan a límites, regresa a verde).

Observabilidad que salva: SLOs por presupuesto de errores y kill-switch reales

La observabilidad no es el mural bonito de la oficina, es tu sistema nervioso. Define SLOs (objetivos de nivel de servicio) basados en experiencia de usuario: tasa de éxito por ruta, latencia p95/p99, porcentaje de pedidos completados. A partir de ahí, calcula error budgets. Cuando un proveedor externo empieza a gastar ese presupuesto, la plataforma debe tomar decisiones automáticas: bajar un nivel de seguridad, reducir features, recortar tráfico no esencial.

Tres piezas prácticas:

• Alertas por síntoma, no por CPU. Menos spam de métricas internas; más señales de usuario (códigos de respuesta, latencias en el edge, conversiones).
• Circuit breakers. Si una dependencia dispara errores sostenidos, el breaker abre y devuelve respuestas degradadas o cacheadas sin seguir golpeando la dependencia.
• Rollbacks en frío. Versiones estables listas para entrar sin rebuilds. No confíes en que “ya compila rápido”. En crisis, lo rápido es lo que ya está.

Y, por favor, kill-switch reales. He visto demasiados toggles que dependen del mismo panel afectado. Necesitas un plan B: scripts firmados, CLI interna o un panel minimalista servido desde otra región/proveedor que permita apagar módulos peligrosos (por ejemplo, inspección avanzada de bots) sin contactar a medio mundo.

Checklist para simulacros y pruebas de caos (con métricas de salida)

• Ejercicio trimestral de degradación. Objetivo: en 10 minutos, levantar landing estática fuera de banda y banner global. Métrica de salida: tiempo hasta “algo útil” visible.
• Failover DNS manual. Cambiar registros críticos a un origen alterno. Métrica: TTL efectivo + tiempo humano < X minutos.
• Apagado controlado del WAF avanzado. Activar modo ámbar con reglas mínimas. Métrica: reducción de 5xx > Y% sin disparar abusos medibles.
• Chaos en horas valle. Cortar una dependencia (por ejemplo, motor de recomendaciones) y medir impacto real en conversión.
• Status fuera del perímetro. Verificar que la página de estado y el canal de comunicación externo siguen vivos cuando el principal no lo está.
• Postmortem corto. 1 página: qué pasó, qué hicimos, qué cambiaremos. Accionable, sin poesía.
• Formación cruzada. Que al menos dos personas por turno sepan ejecutar el runbook sin pedir permisos especiales.

Si te suena mucho trabajo, piensa en el costo de una hora de caída en pico. No se trata de paranoia: se trata de aceptar que la próxima caída llegará—de éste u otro proveedor—y decidir si te pilla con el plan impreso o con el meme del “internééé…” en bucle.

Preguntas frecuentes: errores “challenges”, 5xx y más

¿Por qué veo retos infinitos de verificación humana?
Porque la capa que decide si eres humano o bot está estresada o inconsistentes sus señales. Si el score no llega o llega tarde, te deja en un limbo. En modo ámbar, limita esos retos a endpoints sensibles y sirve el resto con reglas mínimas.

¿Cómo reduzco el impacto si dependo de un único proveedor?
Con duplicación inteligente: DNS alterno (aunque sea manual), origen de emergencia, landing estática fuera de banda, TTL razonables, caché “stale-if-error”, y un runbook claro para apagar funciones no esenciales.

¿Qué hago si mi status page también cae?
Tener una segunda, fuera del mismo proveedor, con actualizaciones rápidas. Añade un listado de lo que funciona y lo que no, y un feed que puedas actualizar con baja fricción.

¿Se debe apagar la seguridad cuando hay incidencia?
No. Se debe degradar inteligentemente: listas estáticas, rate limits, menos inspección avanzada. Sirve contenido y vigila métricas de abuso. Cuando el tráfico y los errores se normalicen, vuelves a verde.

¿Cómo explico esto a negocio sin tecnicismos?
Con tres datos: tiempo hasta mostrar algo útil, porcentaje de transacciones completadas durante la incidencia y tiempo total hasta recuperar la normalidad. Son métricas que entienden y que guían inversión en resiliencia.

Sobre la caída de cloudflare

Ayer fue un recordatorio brutal de que la resiliencia no es un botón, es una arquitectura con criterio. Mi lectura práctica: diseña para fallos parciales, limita tu blast radius, y prepara un modo ámbar que te permita seguir vendiendo y comunicando mientras arreglas lo roto. Porque sí, seguimos construyendo ciudades enteras sobre pocas autopistas; pero los desvíos bien señalizados hacen que un martes negro se quede en anécdota y no en titular.

Opinión Personal

Ayer muchos sentimos que Internet se quedó sin pulso. No fue “la red” entera: fue una pieza crítica de infraestructura que, al fallar, nos recordó lo frágiles que somos cuando apostamos todo a un solo proveedor. Y aquí va mi opinión: la resiliencia no se delega. Ni en Cloudflare, ni en ningún otro. Se diseña.

Celebro que existan plataformas que nos permiten ir más rápido, más seguros, más baratos. Pero confundir comodidad con estrategia es un error caro. Si un ajuste en un módulo de bots puede dejar en jaque a medio ecosistema, la lección es simple: diversifica, degrada, comunica. Diversifica proveedores y rutas de salida. Diseña degradación para servir “algo” útil cuando la capa inteligente se atora. Comunica con transparencia, y hazlo desde un canal que no dependa de la misma jaula.

Lo más incómodo de aceptar es que la seguridad también puede caerse. Por eso defiendo el modo ámbar: reglas mínimas, límite estricto y continuidad del servicio. Es mejor vender menos por 20 minutos que no vender nada durante una hora. ¿Riesgos? Sí. ¿Controlables? También. Lo contrario es tener una web “perfecta” que no carga.

Otro punto: la observabilidad. Si tus alertas hablan de CPU, vas tarde. Las alertas deben hablar de personas: tasa de éxito, latencia percibida, transacciones completadas. Cuando el presupuesto de error se consume, la plataforma debe decidir por sí sola: apagar funciones no esenciales, recortar complejidad, activar landing estática. Sin reuniones. Sin héroes. Con protocolos.

Y ya que hablamos de héroes: el mejor “incidente” es el que ensayaste. Prueba tu plan de caos en horas valle. Cambia DNS a mano. Mide tiempo hasta mostrar algo útil. Documenta. Repite. La próxima caída no es una posibilidad remota: es estadística. La diferencia entre titular y anécdota estará en qué tan rápido tu equipo puede seguir cobrando y explicando mientras arregla lo roto.

En resumen: admiro la innovación, pero mi lealtad está con la continuidad. Menos magia opaca, más arquitectura con criterio. Menos “todo en uno”, más opciones reales. Hoy no se trata de culpar; se trata de madurar.

Ahora quiero leerte a ti: ¿cómo viviste la caída?, ¿qué te funcionó y qué vas a cambiar en tu stack a partir de ahora? Déjame tus comentarios abajo y abramos el debate.