El martes 18 de noviembre de 2025, la red de Cloudflare sufrió una interrupción significativa que afectó múltiples servicios y clientes a nivel mundial. En Jerrejerre, como empresa dedicada al desarrollo y mantenimiento de portales robustos (Drupal, WordPress) y soporte técnico permanente, consideramos que este tipo de incidentes son una oportunidad para reflexionar y reforzar las buenas prácticas. En esta entrada repasamos qué pasó, por qué importa, y cómo podemos aprovecharlo para fortalecer la disponibilidad de los sitios de nuestros clientes.
¿Qué ocurrió?
Cloudflare compartió un reporte oficial con la explicación completa de lo sucedido. Aquí ofrecemos una síntesis de los puntos principales de esa cronología:
- El incidente comenzó a las 11:20 UTC del 18 de noviembre, cuando su red empezó a experimentar fallos para entregar tráfico de red. A pesar de que inicialmente se pensó que había sido causado por un ataque externo, no se registró actividad maliciosa como origen directo del problema.
- El desencadenante fue un cambio en los permisos de uno de sus sistemas de base de datos (ClickHouse) que generó duplicados en un archivo de configuración (“feature file”) usado por su módulo de gestión de bots (Bot Management). Ese archivo se duplicó en tamaño, superó los límites del software en sus máquinas proxy, y provocó errores internos (HTTP 5xx) en el sistema de proxy central.
- Hubo fluctuaciones erráticas: el archivo defectuoso se propagó a distintos nodos, generando un comportamiento intermitente de recuperación/fallo, lo que complicó la identificación rápida del origen.
- A partir de las ~14:30 UTC empezaron a mitigar el problema: se detuvo la generación del archivo defectuoso, se desplegó una versión conocida buena, se reinició el proxy central. Para las ~17:06 UTC todos los sistemas estaban ya operando con normalidad.
- Cloudflare describe este como “su peor outage desde 2019” en términos de interrupción del tráfico central.
¿Por qué es relevante para nuestros clientes?
Como proveedor de desarrollo, soporte y mantenimiento de portales web (Drupal, WordPress) para empresas, lo que le sucede a un proveedor de infraestructura global como Cloudflare nos concierne directamente, por varias razones:
- Disponibilidad y confianza: Muchas de las web que gestionamos dependen, directa o indirectamente, de servicios de red, CDN, proxies o soluciones de seguridad como los que ofrece Cloudflare. Cuando dichos servicios fallan, el cliente final ve una página de error, el rendimiento se degrada o, peor aún, el sitio se cae. Hemos siempre tenido confianza en este proveedor y en nuestros más de 10 años de experiencia, este ha sido el único incidente grave que hemos experimentado con ellos a pesar de usar siempre el plan gratuito.
- Gestión de riesgos externos: Aun cuando nuestra arquitectura esté bien diseñada, siempre hay dependencias externas (infraestructura, proveedores de DNS/CDN, servicios de cache, etc.). Este incidente subraya que ningún proveedor es inmune y que debemos diseñar sistemas con “fallo” previsto.
- Comunicación con el cliente: Cuando ocurre algo como esto, muchas veces el responsable de soporte de la empresa afectada puede terminar recibiendo la llamada del cliente. En Jerrejerre tenemos que estar listos para explicar qué pasó, cuál es nuestro plan de contingencia y cómo minimizamos la exposición.
- Responsabilidad operativa: Nuestro servicio de mantenimiento va más allá de desarrollar y entregar un portal: incluye vigilancia, backups, revisión de dependencias y planes de recuperación. Incidentes como este refuerzan la necesidad de tener políticas de “resiliencia”.
Alternativas a Cloudflare
Hay servicios que ofrecen protección, CDN y mitigación de ataques similares a Cloudflare. Aquí una tabla útil para clientes que desean evaluar opciones adicionales o complementarias:
| Proveedor | Características principales | Precio aproximado mensual | Comparación con Cloudflare Free |
|---|---|---|---|
| Cloudflare Free | CDN global, WAF básico, DNS rápido | $0 | — |
| Akamai | CDN muy robusto, WAF empresarial, soluciones anti-DDoS | Desde $200–$400+ | Mucho más caro, nivel corporativo |
| Fastly | CDN de baja latencia, reglas VCL avanzadas | Desde $50–$150 | Mayor flexibilidad; costo moderado |
| Sucuri | WAF + CDN + monitoreo malware | Desde $25 | Económico y enfocado en seguridad |
| Imperva | Protección DDoS, WAF avanzado, Bot protection | Desde $75–$200 | Más seguridad avanzada que el plan gratuito |
| Bunny.net | CDN económico, firewall simple | Desde $1–$10 (dependiendo tráfico) | Muy barato, buena relación costo/beneficio |
| QUIC.cloud (para WordPress) | CDN optimizado para LiteSpeed Cache | Desde $5–$30 | Rendimiento optimizado para WP |
| Amazon CloudFront | CDN AWS, integración con WAF y Shield | Desde $20–$100 (según uso) | Requiere más configuración; potente |
Nota: los precios varían según tráfico, reglas de seguridad, ancho de banda y características extra. Están expresados como rangos típicos de proyectos medianos.
¿Qué estamos haciendo en Jerrejerre?
- Evaluación y monitoreo constante de dependencias críticas en cada portal gestionado, así como el estado de disponibilidad de cada uno de ellos.
- Configuración de alertas específicas para detectar errores en capas CDN/WAF.
- Documentación de planes de contingencia ante fallas de proveedores externos.
- Asesoría a clientes que dependen fuertemente de Cloudflare para verificar si necesitan redundancia o alternativas.
- Revisión técnica completa del incidente para integrar aprendizajes en nuestras mejores prácticas.
Conclusión
La caída de Cloudflare del 18 de noviembre nos recuerda que incluso los proveedores más grandes pueden experimentar fallos graves. En Jerrejerre usamos estos eventos para reforzar nuestra misión: crear sistemas resilientes, monitoreados, seguros y listos para soportar imprevistos.
Si deseas que evaluemos tus dependencias externas o te ayudemos a configurar redundancias o alternativas, estamos disponibles para ayudarte.
