Historique des pannes de Fortrabbit undefined

1. 27 juillet 2026 à 07:05 UTCinvestigating

   Depuis ~08:00 nous voyons des problèmes avec un certain nombre d'applications hébergées dans la région de l'UE. C'est environ 70 Apps et pour autant que nous puissions voir, il y a une attaque DDoS en cours. C'est très répandu et donc difficile à maîtriser.

2. 27 juillet 2026 à 07:48 UTCinvestigating

   Nous travaillons sur une solution, mais malheureusement ce n'est pas si facile de la contenir.

3. 27 juillet 2026 à 10:10 UTCmonitoring

   Nous y travaillons encore, mais l'ETA. La plupart des applications sont déjà en ligne. Mais nous continuons à surveiller.

4. 27 juillet 2026 à 20:07 UTCresolved

   Le problème n'est pas résolu à 100 %. Nous continuons de surveiller. Comme la plupart des applications (sauf une) sont à nouveau en ligne, nous fermons cet incident pour le moment.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 7 juillet 2026 à 06:00 UTCresolved

   Nous mettrons à niveau les systèmes sous-jacents pour le tableau de bord et le stockage des objets sur l'ancienne plateforme. Le tableau de bord et le stockage d'objets pourraient ne pas être disponibles pendant quelques minutes.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 1 juillet 2026 à 17:00 UTCinvestigating

   Nous devons mettre en place des correctifs de sécurité pour la région de l'UE. Attendez-vous à un temps d'arrêt de 30 minutes par application, quelque part dans le délai indiqué. Le service de déploiement aura des temps d'arrêt supplémentaires. Merci de votre compréhension.

2. 1 juillet 2026 à 19:11 UTCresolved

   Entretien terminé

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 1 juillet 2026 à 06:00 UTCresolved

   Nous devons mettre en place des correctifs de sécurité pour la région américaine. Attendez-vous à un temps d'arrêt de 30 minutes par application, quelque part dans le délai indiqué. Le service de déploiement aura des temps d'arrêt supplémentaires. Merci de votre compréhension.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 24 juin 2026 à 17:00 UTCresolved

   Nous mettons à jour toutes les bases de données vers MySQL 8.4. Cela causera jusqu'à une heure d'arrêt pour chaque application. Nous ne pouvons pas vous donner des heures précises pour quand spécifiquement votre application sera en panne, nous pouvons seulement dire que ce sera en panne pendant cette fenêtre de maintenance. Pour plus de détails, consultez notre billet de blog: https://blog.fortrabbit.com/mysql-8-4-upgrade-plan

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 24 juin 2026 à 07:00 UTCresolved

   Nous mettons à jour toutes les bases de données vers MySQL 8.4. Cela causera jusqu'à une heure d'arrêt pour chaque application. Nous ne pouvons pas vous donner des heures précises pour quand spécifiquement votre application sera en panne, nous pouvons seulement dire que ce sera en panne pendant cette fenêtre de maintenance. Cette fenêtre de maintenance supplémentaire permettra de mettre à niveau les applications universelles restantes que nous n'avons pas eu le temps de terminer hier. Pour plus de détails, consultez notre blog: https://blog.fortrabbit.com/mysql-8-4-upgrade-plan

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 23 juin 2026 à 07:00 UTCresolved

   Nous mettons à jour toutes les bases de données vers MySQL 8.4. Cela causera jusqu'à une heure d'arrêt pour chaque application. Nous ne pouvons pas vous donner des heures précises pour quand spécifiquement votre application sera en panne, nous pouvons seulement dire que ce sera en panne pendant cette fenêtre de maintenance. Pour plus de détails, consultez notre billet de blog: https://blog.fortrabbit.com/mysql-8-4-upgrade-plan

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 10 juin 2026 à 05:00 UTCresolved

   Nous déploierons des correctifs de sécurité pendant la fenêtre de maintenance. Cela n'affectera pas les changements de version du logiciel face au client. Le temps d'arrêt prévu par application est inférieur à une minute. Nous l'avons fait en lots pour les régions américaines et européennes.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 2 juin 2026 à 08:41 UTCinvestigating

   Nous examinons des problèmes pour les certificats de Encryptage qui ont été créés ou renouvelés récemment.

2. 2 juin 2026 à 12:11 UTCresolved

   Nous pensons avoir résolu la question du certificat. Il était lié à un changement dans le certificat de chaîne racine de Encrypt. C'est quelque chose, qui ne se produit pas sur une base régulière, donc il n'a pas été inclus dans le contrôle général de la sécurité des sources externes. Elle n'a touché qu'un petit nombre de certificats nouvellement créés ou récemment mis à jour. Contactez-nous si vous voyez toujours des problèmes SSL.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 29 mai 2026 à 07:20 UTCinvestigating

   Nous examinons les questions de livraison web pour environ 30 applications hébergées dans la région de l'UE de l'ancienne plateforme. Les problèmes ont peut-être commencé vers 06:00 UTC. Toutes les applications ne sont pas en panne, seulement certaines, elles renvoient des erreurs aléatoires ou des timeouts.

2. 29 mai 2026 à 07:52 UTCinvestigating

   Les applications devraient revenir pour le moment. Mais nous enquêtons encore.

3. 29 mai 2026 à 11:16 UTCresolved

   Post mortem Universal Apps exécute des systèmes d'accueil partagés. Ces systèmes hôtes ont - bien sûr - un stockage de fichiers limité. Au début, nous avons appliqué des quotas de système de fichiers durs, mais un bug sous-jacent dans BTRFS a causé des problèmes avec cela. Nous avons donc levé les limites dures et permis de dépasser les limites du système de fichiers inclus. Pour Universal Apps, il n'y a pas d'échelle automatique, donc cette solution est en fait mieux pour les clients aussi. Nous surbookons le stockage, en gros par le facteur de trois, ce qui permettrait aux clients d'utiliser autant que le plus grand plan Uni. Nous vérifions régulièrement les applications qui dépassent les limites et écrivons des mails. Dernièrement, nous devons le faire plus souvent. Le plus souvent, l'utilisation excessive du stockage de fichiers est attribuée à la mauvaise configuration de code/configuration. Le plus souvent trouver beaucoup d'anciens fichiers de sauvegardes locales (peut-être un plugin?), mais aussi beaucoup de fichiers cache. Plus précisément, plus tard, un problème se pose de plus en plus. Peut-être à cause des robots plus agressivly ramper sites Web, qui offrent un nombre illimité de pages possibles. Nous avons des contrôles de santé en place, nous alertant sur les problèmes de stockage. Dans ce cas, le stockage rempli rapidement, provoquant toutes sortes d'erreurs aléatoires. Nous avons pro-activement enlevé les dossiers cache, ce qui a causé une charge plus élevée sur le système hôte, lorsque les applications ont rempli les caches. Cette architecture n'est évidemment pas préfet. C'est l'une des nombreuses raisons pour lesquelles nous avons décidé de créer une nouvelle plateforme à partir de zéro. La nouvelle plate-forme résout cela sur plusieurs niveaux : - Plans de stockage plus grands - Option "Autoscalage" : soit plafonné, soit mis à niveau Après la surveillance, nous examinons la question maintenant résolue.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 12 mai 2026 à 05:00 UTCresolved

   Nous déploierons des correctifs de sécurité pendant la fenêtre de maintenance. Cela n'affectera pas les changements de version du logiciel face au client. Le temps d'arrêt prévu par application est inférieur à une minute. Nous l'avons fait en lots pour les régions américaines et européennes. BTW: Nous avons migré notre outil de statut et nettoyé un peu. Donc cette notification peut sembler différente maintenant.

Traduit automatiquement depuis la mise à jour officielle de l'incident.