Webflow experimentó una interrupción prolongada en la disponibilidad del Designer, el Dashboard, el Marketplace y los registros de usuarios entre el 28 y el 31 de julio.
Aunque los sitios alojados permanecieron activos, algunas funciones principales de la plataforma no estuvieron disponibles. Hemos restaurado la fiabilidad y aquí te contamos cómo lo logramos. Para una reflexión más amplia sobre cómo afectó esto a nuestros clientes y qué estamos cambiando como empresa, lee la publicación de nuestra CEO, Linda, aquí. A continuación, presentamos un desglose técnico del incidente desde una perspectiva de ingeniería.
Resumen
Las dos primeras fases de la interrupción fueron causadas por un atacante malintencionado que generó una carga sostenida en nuestros sistemas y puntos finales de API específicos, lo que resultó en una mayor latencia e interrupciones intermitentes del servicio. Estos ataques se mitigaron mediante protecciones de firewall, bloqueo de IP e investigación de la infraestructura backend.
La tercera y más disruptiva fase fue provocada por el tráfico de ataque continuo, agravado por una degradación del rendimiento tras escalar un clúster de base de datos backend crítico con una arquitectura de hardware de CPU de doble socket para proporcionar margen operativo. Aunque el mayor tamaño del clúster de base de datos demostró tener un mayor rendimiento, más tarde descubrimos que la arquitectura de CPU de un solo socket funciona mejor para nuestros servicios.
La cuarta fase comenzó con otro ataque malintencionado, que provocó que un clúster de base de datos crítico experimentara una grave latencia de escritura y retraso en la replicación. Esta fase se mitigó mediante dos cambios de configuración independientes: primero por parte de nuestro proveedor de base de datos y, posteriormente, escalando el clúster de base de datos mediante una arquitectura de CPU de un solo socket de mayor capacidad.
La estabilidad total se restableció después de estos cambios y no se han observado más interrupciones desde entonces. Durante las cuatro fases del incidente, todos los sitios web alojados en Webflow mantuvieron una disponibilidad del 100 por ciento.
Resumen del incidente
- Hora de inicio: 28 de julio de 2025 a las 1:27 PM UTC
- Hora de finalización: 31 de julio a las 4:00 PM UTC
- Duración total: 3 días, 2 horas y 33 minutos
- Impacto: Webflow Designer, Dashboard, Marketplace y los registros de usuarios experimentaron una mayor latencia, interrupciones parciales y una degradación del rendimiento en cuatro fases distintas
- Causas principales:
- Atacante malintencionado dirigido que generó una carga sostenida en nuestros sistemas
- Problemas de rendimiento tras el escalado de un clúster de base de datos backend crítico
- Problemas de configuración y un error de software conocido en un clúster de base de datos crítico
Qué sucedió
Tráfico malintencionado y mitigación inicial
El 28 de julio a las 1:27 PM UTC, comenzamos a recibir informes internos y externos sobre un aumento en la latencia al cargar el Webflow Designer y el Dashboard. Algunos clientes experimentaron largos tiempos de espera para publicar sitios y errores al intentar cargar partes fundamentales de la plataforma.
Identificamos a un atacante malintencionado que generaba una carga sostenida en nuestros sistemas, por lo que implementamos protecciones de firewall para aplicaciones web, bloqueamos rangos de direcciones IP sospechosas y abrimos un caso de alta prioridad con nuestro proveedor de bases de datos externo. También tomamos medidas para mejorar la eficiencia de la base de datos. Estos ataques fueron mitigados a las 4:55 PM UTC y el servicio volvió a la normalidad.
A las 9:03 AM UTC del 29 de julio, detectamos una segunda serie de ataques dirigidos a puntos de conexión de API similares. La latencia en el Designer y el Dashboard aumentó de nuevo. Se aplicaron protecciones de firewall adicionales y bloqueos de IP, y continuamos con las investigaciones de la base de datos backend. Para las 10:59 AM UTC, el Webflow Designer y el Dashboard volvieron a estar totalmente estables y con una respuesta rápida.
Cambios en el sistema que aumentaron la carga bajo presión
La tercera fase comenzó a las 12:13 PM UTC del 29 de julio. Mientras el tráfico malintencionado continuaba, también empezamos a notar la carga normal de un día laborable. Para aumentar el margen operativo, escalamos un clúster de base de datos backend crítico a una nueva arquitectura de hardware de CPU de doble socket utilizando la automatización de nuestro proveedor. Esta acción, completada a las 2:50 PM UTC, provocó rápidamente una grave latencia de escritura y un retraso en la replicación de 300 y 500 veces por encima de lo habitual, respectivamente.
La disponibilidad del Designer y el Dashboard fue intermitente durante las siguientes ocho horas. Para reducir la carga en el sistema, desactivamos los flujos de datos, inhabilitamos SCIM, pausamos los registros de nuevos usuarios y apagamos varias funciones recién lanzadas. Todo el resto del trabajo de ingeniería y operaciones se detuvo para centrarnos en el incidente.
A las 8:00 PM UTC, nuestro proveedor de bases de datos recomendó reducir el clúster a una arquitectura de CPU de un solo socket más pequeña. Esta operación se completó a las 10:09 PM UTC. El Designer y el Dashboard recuperaron un rendimiento estable inmediatamente después.
Recuperación final y validación de la solución
La cuarta fase del incidente comenzó a las 9:32 AM UTC del 30 de julio, cuando un ataque malintencionado al Webflow Marketplace provocó una mayor latencia de escritura en la base de datos y degradó el rendimiento en el Designer y el Dashboard. Mitigamos el problema desconectando el Marketplace, inhabilitando los registros de nuevos usuarios, optimizando las operaciones de lectura y trabajando en estrecha colaboración con nuestro proveedor de bases de datos externo. Realizamos una conmutación por error del clúster de la base de datos a las 10:18 AM UTC. El proveedor también identificó un error conocido de recuento de sesiones y recomendó cambios de configuración, incluida la reducción del registro de consultas lentas y, posteriormente, la desactivación de la desconfirmación agresiva de memoria, lo cual contribuyó a la recuperación del sistema. Para garantizar la resiliencia a largo plazo, actualizamos el clúster de base de datos crítico a una arquitectura de CPU de un solo socket de mayor capacidad. Este paso final devolvió al sistema a una estabilidad total a las 5:59 PM UTC, observándose mejoras sostenidas a partir de entonces.
Por precaución, dada la larga duración y las múltiples fases de este incidente, mantuvimos nuestra monitorización continua, videollamadas con nuestro proveedor de bases de datos y permanecimos en alerta máxima hasta las 4:00 PM UTC del 31 de julio.
Lo que salió bien
- Mitigamos dos ataques iniciales rápidamente mediante reglas de firewall, bloqueo de IP y análisis de backend.
- Los sitios web alojados en Webflow permanecieron totalmente operativos y sin afectaciones durante todo el incidente.
- Los equipos de ingeniería y operaciones se coordinaron para reducir la carga del backend y minimizar la presión sobre el sistema.
- Las sesiones de video chat en vivo con nuestro proveedor de bases de datos aseguraron una buena comunicación y debate sobre las medidas de mitigación.
- Todos los recursos disponibles fueron redirigidos a resolver el incidente durante la tercera fase.
Donde nos quedamos cortos
- Nuestra infraestructura no contaba con disyuntores ni límites de tasa para evitar la tensión en cascada durante la recuperación.
- Funciones clave fueron desactivadas durante el incidente sin previo aviso a los clientes o socios.
- El escalado a la arquitectura de hardware de CPU de doble socket introdujo problemas de rendimiento inesperados relacionados con la latencia de escritura y el retraso en la replicación.
- El proveedor de la base de datos no resolvió su error de recuento de sesiones en un plazo que ayudara con la mitigación.
Lo que hemos cambiado
Desde el incidente, hemos completado las siguientes mejoras:
- Añadimos un índice a una colección en el clúster de base de datos afectado para aumentar la eficiencia de las consultas y reducir la carga de la base de datos
- Implementamos una limitación de tasa más estricta en nuestros sistemas de registro de usuarios para mitigar mejor los picos de tráfico
- Aumentamos las protecciones de limitación de tasa en nuestro firewall de aplicaciones web para bloquear el tráfico malicioso en áreas específicas
- Introdujimos disyuntores para los flujos de tráfico clave que generan una carga significativa en el clúster de base de datos afectado
- Mejoramos la monitorización para garantizar alertas más fiables cuando surjan problemas de latencia en la base de datos
- Actualizamos nuestro clúster de base de datos crítico a una arquitectura de CPU de un solo zócalo con mayor capacidad
En lo que seguimos trabajando
- Reprocesar los envíos de formularios perdidos para todos los formularios de clientes (completado el 8 de agosto)
- Ajustar las configuraciones de latido para mejorar el estado de los grupos de conexiones de la base de datos (completado el 1 de agosto)
- Ajustar los programas de copias de seguridad y snapshots para evitar la carga durante las horas de mayor uso (completado el 4 de agosto)
- Evaluar y posiblemente trasladar consultas adicionales de solo lectura a una réplica dedicada (completado el 4 de agosto)
- Evaluar el uso de un sistema de colas para solicitudes de escritura no críticas para permitir la consistencia eventual (completado el 4 de agosto)
- Finalizar el análisis interno de la causa raíz con acciones de seguimiento adicionales (completado el 4 de agosto)
- Completar un análisis detallado de la causa raíz con nuestro proveedor de base de datos para obtener recomendaciones de rendimiento (previsto para el 1 de agosto, retrasado por el proveedor hasta el 25 de agosto)
- Actualizar los clústeres de base de datos a la última versión de software (iniciado, con finalización prevista para todos los clústeres el 5 de septiembre)
- Implementar la corrección del error de recuento de sesiones identificado por nuestro proveedor de base de datos cuando esté disponible (sin fecha por parte del proveedor)
Conclusión
Entendemos la confianza que depositan en nosotros para realizar trabajos de gran importancia. Sabemos que esta vez no cumplimos con esa expectativa, y estamos aplicando cada lección aprendida de este incidente para construir un Webflow más fuerte y resistente. Seguimos supervisando el rendimiento de cerca y compartiremos actualizaciones a medida que avancemos en nuestro trabajo.
-Allan
CTO de Webflow
Si quieres conocer todos los detalles, tienes a tu disposición un análisis técnico más profundo aquí.
