Historial de interrupciones de Fortrabbit undefined

1. 27 de julio de 2026 a las 7:05 UTCinvestigating

   Desde ~08:00 vemos problemas con varias aplicaciones alojadas en la región de la UE. Son alrededor de 70 aplicaciones y en lo que podemos ver, hay un ataque DDoS en marcha. Es muy extendido y por lo tanto difícil de controlar.

2. 27 de julio de 2026 a las 7:48 UTCinvestigating

   Estamos trabajando en una solución, pero por desgracia no es tan fácil contenerla.

3. 27 de julio de 2026 a las 10:10 UTCmonitoring

   Todavía estamos trabajando en ello, pero ETA todavía. La mayoría de las aplicaciones ya están en línea. Pero seguimos monitoreando.

4. 27 de julio de 2026 a las 20:07 UTCresolved

   El problema no se resuelve al 100%. Todavía estamos monitoreando. Como la mayoría de las aplicaciones (excepto una) están en línea de nuevo, cerramos este incidente por ahora.

Traducido automáticamente desde la actualización oficial del incidente.

1. 7 de julio de 2026 a las 6:00 UTCresolved

   Mejoraremos los sistemas subyacentes para el Dashboard y almacenamiento de objetos en la plataforma antigua. El Dashboard y el almacenamiento de objetos podrían estar disponibles durante unos minutos.

Traducido automáticamente desde la actualización oficial del incidente.

1. 1 de julio de 2026 a las 17:00 UTCinvestigating

   Tenemos que hacer algunos arreglos de seguridad para la región de la UE. Espere un tiempo de inactividad de 30 minutos por App, en algún lugar dentro del marco de tiempo señalado. El servicio de despliegue tendrá tiempo de inactividad adicional. Gracias por su comprensión.

2. 1 de julio de 2026 a las 19:11 UTCresolved

   Mantenimiento terminado

Traducido automáticamente desde la actualización oficial del incidente.

1. 1 de julio de 2026 a las 6:00 UTCresolved

   Tenemos que hacer algunos arreglos de seguridad para la región de Estados Unidos. Espere un tiempo de inactividad de 30 minutos por App, en algún lugar dentro del marco de tiempo señalado. El servicio de despliegue tendrá tiempo de inactividad adicional. Gracias por su comprensión.

Traducido automáticamente desde la actualización oficial del incidente.

1. 24 de junio de 2026 a las 17:00 UTCresolved

   Estamos actualizando todas las bases de datos a MySQL 8.4. Esto causará hasta una hora de tiempo de inactividad para cada aplicación. No podemos darle tiempos exactos para cuando específicamente su aplicación estará baja, sólo podemos decir que va a estar por algún tiempo durante esta ventana de mantenimiento. Para más detalles, consulte nuestro blog: https://blog.fortrabbit.com/mysql-8-4-upgrade-plan

Traducido automáticamente desde la actualización oficial del incidente.

1. 24 de junio de 2026 a las 7:00 UTCresolved

   Estamos actualizando todas las bases de datos a MySQL 8.4. Esto causará hasta una hora de tiempo de inactividad para cada aplicación. No podemos darle tiempos exactos para cuando específicamente su aplicación estará baja, sólo podemos decir que va a estar por algún tiempo durante esta ventana de mantenimiento. Esta ventana de mantenimiento adicional actualizará las aplicaciones universales restantes que no teníamos tiempo para terminar ayer. Para más detalles ver nuestro blog post: https://blog.fortrabbit.com/mysql-8-4-upgrade-plan

Traducido automáticamente desde la actualización oficial del incidente.

1. 23 de junio de 2026 a las 7:00 UTCresolved

   Estamos actualizando todas las bases de datos a MySQL 8.4. Esto causará hasta una hora de tiempo de inactividad para cada aplicación. No podemos darle tiempos exactos para cuando específicamente su aplicación estará baja, sólo podemos decir que va a estar por algún tiempo durante esta ventana de mantenimiento. Para más detalles, consulte nuestro blog: https://blog.fortrabbit.com/mysql-8-4-upgrade-plan

Traducido automáticamente desde la actualización oficial del incidente.

1. 10 de junio de 2026 a las 5:00 UTCresolved

   Enrollaremos algunos parches de seguridad durante la ventana de mantenimiento. Esto no afectará a los cambios de la versión de software del cliente. El tiempo de inactividad esperado por aplicación es bajo un minuto. Dirigimos esto en lotes para ambas regiones EE.UU. y UE.

Traducido automáticamente desde la actualización oficial del incidente.

1. 2 de junio de 2026 a las 8:41 UTCinvestigating

   Estamos buscando problemas para los certificados de Encrypt que han sido recientemente creados o renovados.

2. 2 de junio de 2026 a las 12:11 UTCresolved

   Creemos haber resuelto el número de certificados. Estaba relacionado con un cambio en el certificado de cadena raíz de Encrypt. Esto es algo, que no está sucediendo de forma regular, por lo que no fue incluido con la vigilancia general de la seguridad de las fuentes externas. Afectó sólo un pequeño número de certificados recién creados o actualizados recientemente. Póngase en contacto con nosotros si sigue viendo problemas SSL.

Traducido automáticamente desde la actualización oficial del incidente.

1. 29 de mayo de 2026 a las 7:20 UTCinvestigating

   Estamos investigando problemas de entrega web para alrededor de 30 aplicaciones alojadas en la región de la UE de la antigua plataforma. Los problemas pueden haber comenzado alrededor de las 06:00 UTC. No todas las aplicaciones están bajas, sólo algunas, devuelven errores aleatorios o timeouts.

2. 29 de mayo de 2026 a las 7:52 UTCinvestigating

   Las aplicaciones deben estar de vuelta por ahora. Pero todavía estamos investigando.

3. 29 de mayo de 2026 a las 11:16 UTCresolved

   Post mortem Aplicaciones Universal ejecutan sistemas de host compartidos. Estos sistemas de host tienen - por supuesto - almacenamiento limitado de archivos. Inicialmente aplicamos cuotas de sistema de archivos duros, pero un fallo subyacente en BTRFS causó problemas con eso. Así que levantamos los límites difíciles y permitimos superar los límites del sistema de archivos incluidos. Para las aplicaciones universales, no hay escalado automático, por lo que la solución es realmente mejor para los clientes también. Nos almacenamos en exceso, aproximadamente por el factor de tres, lo que permitiría a los clientes utilizar el doble de almacenamiento que el plan Uni más grande. Comprobamos regularmente aplicaciones que superan los límites y escriben correos. Últimamente tenemos que hacerlo más a menudo. Más comúnmente, el uso excesivo de almacenamiento de archivos se atribuye a la configuración errónea de código/config. La mayoría de las veces encuentra muchos archivos de respaldo locales antiguos (quizás algún plugin?), pero también muchos archivos de caché. Específicamente el más tarde está recibiendo un problema cada vez más. Tal vez debido a bots más agresivo arrastrando sitios web, que ofrecen un número ilimitado de páginas posibles. Tenemos controles de salud en su lugar, alertando sobre problemas de almacenamiento. En este caso, el almacenamiento se llena rápidamente, causando todo tipo de errores aleatorios. Eliminamos proactivamente las carpetas de caché, que causaron mayor carga en el sistema host, cuando las aplicaciones rellenó los caches. Por supuesto, esta arquitectura no es prefecta. Es una de las muchas razones por las que decidimos crear una nueva plataforma desde cero. La nueva plataforma resuelve esto en varios niveles: - Planes de almacenamiento más grandes - Opcional "Autoscaling": ya sea capped, o actualización Después de la vigilancia, consideramos la cuestión ahora resuelta.

Traducido automáticamente desde la actualización oficial del incidente.

1. 12 de mayo de 2026 a las 5:00 UTCresolved

   Enrollaremos algunos parches de seguridad durante la ventana de mantenimiento. Esto no afectará a los cambios de la versión de software del cliente. El tiempo de inactividad esperado por aplicación es bajo un minuto. Dirigimos esto en lotes para ambas regiones EE.UU. y UE. BTW: Hemos migrado nuestra herramienta de estado y limpiado un poco. Así que esta notificación puede parecer diferente ahora.

Traducido automáticamente desde la actualización oficial del incidente.