CLOUDFLARE

La selección automática y las restricciones de algoritmos tienen mandos distintos. Conservar una llamada antigua no conserva necesariamente su capacidad de control.

Cloudflare informó de errores 5xx y tiempos de espera elevados para algunos clientes cuyo tráfico circulaba entre orígenes de América del Norte y su centro de datos de Singapur. El intervalo fue de 01:06 a 01:54 UTC del 23 de agosto y quedó resuelto sin una causa pública.

Cloudflare informó de un problema de rendimiento de red en Asia-Pacífico y anunció una corrección 8 minutos y 36 segundos después. Sin embargo, el impacto estructurado siguió en `none` y el componente Network pasó de operativo a operativo: la narración registra un incidente que los campos de estado no cuantifican.

Cloudflare cerró el 4 de agosto dos incidentes distintos de Workers. Uno alteró silenciosamente el significado de una capacidad en tiempo de ejecución: `Temporal.Now` devolvía 1970. El otro impidió desplegar una combinación concreta de `nodejs_compat` y fecha de compatibilidad. No hay base para atribuirles una causa común. Sí la hay para revisar la cadena completa, desde la validación de una configuración hasta la semántica que recibe el código una vez desplegado.

Cloudflare declaró resuelto el 3 de agosto un incidente de una hora y 51 minutos en Workers Builds. La recuperación no fue instantánea: a las 15:38 UTC las compilaciones ya no fallaban, aunque los usuarios todavía podían sufrir demoras; después llegó la fase de monitorización y solo a las 16:12 se cerró el incidente. Esa escalera importa para el control de versiones: restablecer la capacidad de compilar no demuestra por sí solo que cada reintento produjo el artefacto correcto ni que cada despliegue pendiente terminó.

Cloudflare resolvió un incidente de Gateway que podía impedir el acceso a Internet público a clientes con direcciones IPv4 de salida dedicadas alojadas en Londres. El caso duró 2 horas, 17 minutos y 50 segundos desde su creación hasta el cierre. La precisión del aviso está en la cohorte de enrutamiento, no en su tamaño: no ofrece número de cuentas, tráfico afectado ni causa. Por eso, el análisis debe seguir la ruta nombrada y no convertirla en una interrupción de toda la ciudad o de toda la plataforma.

Dos eventos de enrutamiento distintos afectaron el 27 de junio de 2024 a la dirección del resolvedor público 1.1.1.1. El caso demuestra por qué los registros de recursos numéricos, las autorizaciones de origen y los colectores de rutas aportan pruebas esenciales, pero no sustituyen las políticas ejecutadas por routers, operadores, proveedores de tránsito y mecanismos de respuesta.

El incidente del 22 de enero de 2026 muestra por qué una modificación pequeña y sintácticamente válida puede ampliar de forma radical la autoridad de exportación de BGP. La cuestión central no es si existía automatización, sino si esa automatización podía demostrar, antes de emitir rutas, que una limpieza de configuración no había eliminado la última restricción que separaba una relación permitida de una fuga.

El incidente del 20 de febrero de 2026 mostró que la autoridad sobre un bloque de direcciones, la autorización criptográfica de su origen y su asociación con un servicio no garantizan que el prefijo siga anunciado ni que el tráfico llegue al destino previsto. La continuidad de BYOIP depende de reconciliar registros, intención operativa, configuración desplegada y observación externa.

La campaña de marzo de 2013 mostró cómo la recursión DNS expuesta, la falsificación de direcciones de origen y las rutas compartidas de interconexión podían convertir fallos locales aparentemente pequeños en un coste externo de gran escala. La responsabilidad depende de identificar qué operador controlaba cada tramo ejecutable y de demostrar que la reparación funcionó.

Un incidente menor de Cloudflare comenzó el 31 de julio a las 11:51:07 UTC y afectó primero a Analytics, el Dashboard y API relacionadas. Después alcanzó a las compilaciones de Pages y Workers. La empresa aplicó una corrección y pasó a vigilancia a las 12:43:57; cerró el caso a las 13:01:59. Cloudflare afirmó que la entrega de archivos en caché por el CDN y otras funciones de seguridad en el borde no se vieron afectadas. Fue una interrupción del plano de control y de parte del flujo de despliegue, no una caída total de la red.