Resumen
- Cloudflare abrió el incidente pgcdxsjxkl0q a las 11:51:07 UTC como menor y bajo investigación.
- Al corte fijo de las 11:53:12, Analytics figuraba degradado y no había mensaje de recuperación.
- El aviso inicial advirtió de errores en el Dashboard y en API relacionadas.
- Cloudflare dijo que los archivos en caché del CDN y otras funciones de seguridad Edge no estaban afectados.
- Las actualizaciones posteriores incorporaron API, Dashboard y luego compilaciones de Pages y Workers; la vigilancia empezó a las 12:43:57.
- El caso se resolvió a las 13:01:59 sin explicación de causa, número de clientes ni alcance geográfico.
El primer dato fue una investigación, no un diagnóstico
Solo transcurrieron dos minutos y cinco segundos entre el inicio y el cierre de la ventana de este informe. En ese punto, el registro oficial mostraba impacto menor, Analytics degradado y estado de investigación.
La corrección y la resolución llegaron después. Una cronología rigurosa añade esos hitos con su hora, sin fingir que ya se conocían al comienzo.
El orden permite distinguir la detección del entendimiento.
El borde y el control soportaron estados distintos
Cloudflare declaró que la entrega de caché por el CDN y otras protecciones Edge continuaban. A la vez, solicitudes del Dashboard y de API relacionadas podían fallar o mostrar errores.
Un usuario final podía cargar un sitio mientras el equipo responsable no conseguía observarlo o cambiarlo. Esa diferencia desaconseja resumir el evento como “Cloudflare caído”.
Tampoco hay base para afirmar que DNS o toda la seguridad dejaron de funcionar.
La ampliación del alcance tuvo horas concretas
A las 12:25:44, API y Dashboard aparecieron degradados. A las 12:37:35, Cloudflare informó de impacto adicional en compilaciones de Pages y Workers.
El registro no asigna a esas compilaciones un inicio retroactivo a las 11:51. Solo demuestra cuándo la empresa publicó el nuevo alcance.
Respetar los tiempos evita exagerar la duración de cada componente afectado.
Los fallos de compilación afectan al siguiente cambio
Una aplicación ya desplegada puede seguir operativa aunque falle una nueva compilación. El coste aparece cuando el equipo necesita lanzar una función, corregir una vulnerabilidad o revertir una versión.
Por ello, dos clientes con el mismo proveedor pueden experimentar riesgos muy distintos durante el mismo intervalo.
No se publicaron tasas de error, número de compilaciones fallidas ni segmentos de cuenta afectados.
Volver a “operativo” no explica el mecanismo
Cloudflare comunicó una corrección bajo vigilancia a las 12:43:57 y una segunda nota de observación a las 12:46:20. La resolución llegó a las 13:01:59.
Analytics, API, Dashboard, Pages y Workers volvieron a figurar operativos. El registro final no describe la causa técnica ni acciones necesarias para los clientes.
El cierre demuestra recuperación del estado, no transparencia sobre el origen.
Prepararse exige separar continuidad pública y capacidad de cambio
Configuración versionada, métricas críticas fuera del panel y procedimientos para aplazar cambios reducen la dependencia del plano de control.
Los equipos también necesitan criterios distintos para una avería del borde y para una avería administrativa. Redirigir tráfico sano porque el panel no responde puede añadir daño.
Un informe posterior debería aportar causa, errores por minuto, compilaciones afectadas y tratamiento de datos retrasados. Con la evidencia actual, la conclusión precisa es más estrecha: hubo unos setenta minutos de degradación administrativa y de construcción, mientras el proveedor mantuvo fuera del impacto la caché CDN y otras funciones Edge.