Whaller Outage History

Started Oct 02, 2026, 02:10 PM UTC· resolved Oct 02, 2026, 03:01 PM UTC

1. identified Oct 02, 2026, 02:10 PM UTC

   Notre hébergeur a actuellement un problème d'interconnexion avec Orange, ce qui ralentit les accès à Whaller. Vous trouverez les détails ici : https://network.status-ovhcloud.com/incidents/jqxcrgr138b4

2. monitoring Oct 02, 2026, 02:45 PM UTC

   A fix has been implemented and we are monitoring the results.

3. resolved Oct 02, 2026, 03:01 PM UTC

   This incident has been resolved.

4. postmortem Oct 06, 2026, 05:59 PM UTC

   # Indisponibilité des plateformes Whaller du 2 octobre 2026 ## Résumé Le 2 octobre 2026, entre 15h17 et 16h41 \(CEST\), une partie des utilisateurs n'a plus pu accéder aux plateformes Whaller. L'incident ne venait pas de l'infrastructure Whaller. Il était lié à un problème d'interconnexion réseau \(peering\) entre notre hébergeur, OVHcloud, et l'opérateur Orange. Les utilisateurs dont le trafic passait par ce lien ne pouvaient plus joindre nos services. Le service a été rétabli à 16h41 après une intervention de l'hébergeur et de l'opérateur. L'incident a été clôturé à 17h01. Aucune donnée n'a été perdue. ## Chronologie des événements Toutes les heures sont en CEST \(heure de Paris\). * **2 octobre 2026, 15h17** : des clients signalent des problèmes de connexion à Whaller. Les équipes techniques lancent l'analyse. * **15h17 – 15h33** : les équipes techniques analysent l'activité des serveurs et redémarrent, par précaution, un serveur frontal et le serveur du site public. Des messages publics sur les réseaux sociaux évoquent des problèmes de résolution DNS, ce qui oriente les recherches vers un problème réseau externe. * **15h33** : les équipes techniques contactent l'hébergeur et ouvrent un ticket de support. L'hébergeur confirme un problème de peering entre son réseau et celui d'Orange. Un incident est publié sur la page de statut. * **16h41** : l'hébergeur annonce la fin de l'incident. Le service est rétabli pour l'ensemble des utilisateurs. * **17h01** : après vérification du bon fonctionnement des plateformes, les équipes techniques clôturent l'incident. ## Difficultés rencontrées * **Symptômes trompeurs** : les premiers signalements ressemblaient à une panne de nos serveurs ou à un problème DNS. Il a fallu écarter ces pistes avant d'identifier la vraie cause. * **Impact partiel** : seuls les utilisateurs passant par le réseau concerné étaient touchés. Depuis d'autres réseaux, les plateformes restaient accessibles, ce qui a compliqué le diagnostic. * **Cause hors de notre périmètre** : le problème se situait entre deux opérateurs tiers. Les équipes techniques ne pouvaient pas le corriger directement et dépendaient de l'intervention de l'hébergeur et de l'opérateur. ## Cause de l'incident Sur la session de peering entre l'hébergeur et Orange, le nombre maximal de routes réseau \(préfixes\) autorisé a été atteint. Cette limite de protection a coupé la session d'échange de routes. Le trafic entre les deux réseaux, dont celui des utilisateurs Orange vers Whaller, n'était donc plus acheminé correctement. L'hébergeur a travaillé avec Orange pour relever cette limite et rétablir un fonctionnement normal. ## Perte de données Aucune perte de données. L'incident concernait uniquement l'accès réseau aux plateformes. Les serveurs, les bases de données et les contenus hébergés n'ont pas été touchés.

Read the full incident report →

Started Aug 16, 2026, 01:30 PM UTC· resolved Aug 17, 2026, 01:36 PM UTC

1. resolved Aug 19, 2026, 08:02 AM UTC

   We are currently investigating this issue.

2. postmortem Aug 19, 2026, 08:09 AM UTC

   # Postmortem — Indisponibilité des résultats de recherche ## Résumé Le 17 août 2026, entre 15 h 36 et 17 h 15 CEST, un incident a affecté le service de recherche et certaines fonctionnalités d’analyse. Durant cette période, les requêtes adressées au moteur de recherche échouaient et les interfaces concernées ne retournaient aucun résultat. L’incident a été détecté à la suite de signalements du client. Les équipes techniques ont identifié une incompatibilité introduite lors de la mise à jour d’une dépendance logicielle, puis déployé une correction. Le service a été entièrement rétabli à 17 h 15 CEST. ## Chronologie des événements * **17 août 2026 à 15 h 36 CEST** : début de l’incident. Les requêtes adressées au moteur de recherche commencent à échouer. * **À partir de 15 h 36 CEST** : l’absence de résultats devient visible dans les interfaces concernées et fait l’objet de signalements du client. * **16 h 26 CEST** : les équipes techniques prennent en charge l’incident et lancent les investigations. * **17 h 08 CEST** : les équipes techniques déploient une première correction. * **17 h 13 CEST** : le déploiement est terminé et les tests confirment le rétablissement du fonctionnement attendu. * **17 h 15 CEST** : la correction est mise en production et l’incident est déclaré résolu. La durée totale de l’incident a été de **1 heure et 39 minutes**. ## Difficultés rencontrées L’incident résultait d’un effet indirect lié à l’évolution d’une dépendance partagée entre plusieurs composants logiciels. La modification n’affectait pas directement la logique métier du moteur de recherche. Elle concernait une option technique de connexion devenue incompatible avec le client HTTP désormais utilisé. Cette incompatibilité a rendu l’origine de l’incident moins immédiatement identifiable. Par ailleurs, l’incident a d’abord été détecté grâce aux signalements du client et à l’absence visible de résultats dans les interfaces. ## Cause de l’incident Une mise à jour de dépendances a entraîné l’utilisation d’un nouveau client HTTP par le composant chargé de communiquer avec le moteur de recherche. Les composants de recherche et d’analyse lui transmettaient encore une option de délai de connexion propre à l’ancien client HTTP. Cette option n’étant pas reconnue par le nouveau composant, les appels au moteur de recherche échouaient systématiquement. La correction a consisté à remplacer cette option par son équivalent compatible avec le nouveau client HTTP. Ce changement ne modifie pas le comportement fonctionnel du service : il maintient uniquement la limite prévue pour l’établissement de la connexion au moteur de recherche. ## Perte de données Aucune perte ni altération de données n’a été constatée. Pendant l’incident, les données sont restées enregistrées, mais les fonctionnalités affectées ne permettaient plus de les retrouver ou de les afficher correctement dans les résultats de recherche et d’analyse. ## Mesures de remédiation Les équipes techniques ont mis en œuvre les actions suivantes : * correction de l’option de connexion utilisée par les composants de recherche et d’analyse ; * déploiement et validation de la correction sur les différents composants concernés ; * vérification du rétablissement des résultats de recherche après la mise en production. --- # Post-mortem — Search results unavailable ## Summary On 17 August 2026, between 15:36 and 17:15 CEST, an incident affected the search service and certain analytics features. During this period, queries sent to the search engine failed and the affected interfaces returned no results. The incident was detected following reports from the client. The technical teams identified an incompatibility introduced during the update of a software dependency and subsequently deployed a fix. The service was fully restored at 17:15 CEST. ## Timeline of events * **17 August 2026 at 15:36 CEST**: start of the incident. Requests sent to the search engine began to fail. * **From 15:36 CEST**: the absence of results became apparent in the affected interfaces and was reported by customers. * **16:26 CEST**: the technical teams took charge of the incident and began investigations. * **17:08 CEST**: the technical teams deploy an initial fix. * **17:13 CEST**: the deployment is complete and tests confirm that the system is functioning as expected. * **17:15 CEST**: the fix is put into production and the incident is declared resolved. The total duration of the incident was **1 hour and 39 minutes**. ## Challenges encountered The incident resulted from an indirect effect linked to a change in a dependency shared between several software components. The change did not directly affect the search engine’s business logic. It concerned a technical connection option that had become incompatible with the HTTP client now in use. This incompatibility made the cause of the incident less immediately identifiable. Furthermore, the incident was first detected thanks to reports from users and the visible absence of results in the user interfaces. ## Cause of the incident An update to dependencies led to the component responsible for communicating with the search engine using a new HTTP client. The search and analysis components were still passing it a connection timeout option specific to the old HTTP client. As this option was not recognised by the new component, calls to the search engine consistently failed. The fix involved replacing this option with its equivalent, which is compatible with the new HTTP client. This change does not alter the functional behaviour of the service: it merely maintains the intended limit for establishing the connection to the search engine. ## Data loss No data loss or corruption was observed. During the incident, the data remained stored, but the affected functionalities were no longer able to retrieve it or display it correctly in the search and analysis results. ## Remedial measures The technical teams implemented the following actions: * correction of the connection option used by the search and analysis components; * deployment and validation of the correction across the various components concerned; * verification that search results had been restored following the production roll-out.

Read the full incident report →

Started Jul 07, 2026, 03:41 PM UTC· resolved Jul 07, 2026, 06:02 PM UTC

1. investigating Jul 07, 2026, 03:41 PM UTC

   Certains utilisateurs rencontrent des déconnexions intempestives de leur compte. Nous investiguons le problème. --- Some users are experiencing unexpected logouts from their accounts. We are investigating the issue.

2. monitoring Jul 07, 2026, 04:17 PM UTC

   Le problème a été identifié, c'est dû à une mise à jour d'une librairie interne. Nous sommes revenus en arrière et la plateforme semble être revenue à la normale. --- The problem has been identified; it was caused by an update to an internal library. We have rolled back the update and the platform appears to be back to normal.

3. resolved Jul 07, 2026, 06:02 PM UTC

   This incident has been resolved.

4. postmortem Jul 08, 2026, 07:41 AM UTC

   # Post-mortem — Déconnexions intempestives sur la plateforme ## Résumé Le 7 juillet 2026, la plateforme Whaller a rencontré un incident de production provoquant des déconnexions intempestives de certains utilisateurs. Le symptôme observé était le suivant : après authentification, l’interface semblait charger normalement, puis l’utilisateur était renvoyé vers la page de connexion. L’incident a été traité en priorité critique par les équipes techniques. Après investigation et déploiement d’un correctif, le service est revenu à un fonctionnement normal. ## Chronologie des événements Le 7 juillet 2026, en fin d’après-midi, les équipes techniques constatent un premier cas de déconnexion forcée après authentification. Peu après, un client confirme un comportement similaire : tentative de connexion, chargement de l’interface, puis retour automatique vers la page de connexion. Une première analyse oriente les investigations vers une évolution applicative récemment mise en production. Un correctif est préparé et déployé afin de revenir en arrière sur cette évolution. Un premier correctif est mis en production, sans résoudre complètement la situation. Les équipes techniques poursuivent alors l’analyse et identifient plus précisément le composant applicatif à l’origine du problème. Un second correctif est ensuite déployé. Après cette mise en production, les déconnexions intempestives ne sont plus constatées. ## Difficultés rencontrées L’incident a présenté plusieurs difficultés d’analyse. Le symptôme visible côté utilisateur était simple à décrire, mais sa cause pouvait provenir de plusieurs couches techniques différentes : gestion des sessions, évolution applicative récente, traitement de maintenance ou infrastructure de base de données. Les équipes techniques ont donc dû investiguer plusieurs pistes en parallèle avant d’isoler la cause réelle. Enfin, un premier correctif a été déployé sur la base de l’hypothèse la plus probable à ce moment-là, mais cette correction n’a pas suffi à résoudre durablement l’incident. Un second correctif a été nécessaire après identification plus précise du composant concerné. ## Cause de l’incident L’incident a été causé par une régression introduite dans une mise à jour récente d’un composant applicatif lié aux discussions. Cette régression provoquait, dans certaines conditions, une instabilité de la session utilisateur après authentification. L’utilisateur pouvait donc réussir à se connecter, puis être immédiatement renvoyé vers la page de connexion. ## Perte de données Aucune perte de données n’a été identifiée. L’incident a affecté l’accès à la plateforme et la stabilité des sessions utilisateur, mais il n’a pas entraîné de suppression, d’altération ou de corruption de données. ## Mesures de remédiation Les équipes techniques ont déployé un correctif permettant de revenir à une version stable du composant applicatif concerné. À la suite de cet incident, les mesures suivantes sont engagées : * analyse détaillée du composant applicatif concerné afin d’identifier précisément le changement ayant provoqué la régression ; * surveillance renforcée après déploiement des correctifs liés à l’authentification, aux discussions et aux mécanismes de reconnexion. Les équipes techniques restent mobilisées afin de prévenir la réapparition de ce type d’incident. --- # Post-mortem — Unexpected logouts on the platform ## Summary On 7 July 2026, the Whaller platform experienced a production incident causing some users to be unexpectedly logged out. The symptom observed was as follows: after logging in, the interface appeared to load normally, but the user was then redirected back to the login page. The incident was treated as a critical priority by the technical teams. Following an investigation and the deployment of a fix, the service returned to normal operation. ## Timeline of events On 7 July 2026, in the late afternoon, the technical teams noted the first instance of a forced logout following authentication. Shortly afterwards, a customer confirmed similar behaviour: an attempt to log in, the interface loading, then an automatic return to the login page. An initial analysis pointed the investigation towards an application update that had recently been put into production. A patch was prepared and deployed to roll back this update. An initial patch was put into production, but this did not fully resolve the issue. The technical teams then continued their analysis and identified more precisely the application component causing the problem. A second patch was then deployed. Following this deployment, the unexpected logouts were no longer observed. ## Challenges encountered The incident presented several challenges for analysis. The symptom visible to the user was simple to describe, but its cause could have stemmed from several different technical layers: session management, a recent application update, maintenance operations or the database infrastructure. The technical teams therefore had to investigate several lines of inquiry in parallel before isolating the actual cause. Finally, an initial fix was deployed based on the most likely hypothesis at that time, but this fix was not sufficient to resolve the incident permanently. A second fix was required following a more precise identification of the component concerned. ## Cause of the incident The incident was caused by a regression introduced in a recent update to an application component related to chat functionality. Under certain conditions, this regression caused user sessions to become unstable after authentication. As a result, users could successfully log in, only to be immediately redirected back to the login page. ## Data loss No data loss was identified. The incident affected access to the platform and the stability of user sessions, but did not result in any data being deleted, altered or corrupted. ## Remedial measures The technical teams deployed a patch to revert to a stable version of the affected application component. Following this incident, the following measures have been implemented: * a detailed analysis of the affected application component to precisely identify the change that caused the regression; * enhanced monitoring following the deployment of patches relating to authentication, chat and reconnection mechanisms. The technical teams remain on high alert to prevent this type of incident from recurring.

Read the full incident report →

Started Jun 23, 2026, 12:25 PM UTC· resolved Jun 23, 2026, 08:44 PM UTC

1. investigating Jun 23, 2026, 12:25 PM UTC

   We are currently investigating this issue.

2. investigating Jun 23, 2026, 12:25 PM UTC

   We are continuing to investigate this issue.

3. resolved Jun 23, 2026, 08:44 PM UTC

   Nous avons identifié et corrigé le problème. La plateforme est de nouveau accessible. Nous produirons un post mortem dans les heures suivantes. We have identified and resolved the issue. The platform is now accessible again. We will be publishing a post-mortem in the next few hours.

4. postmortem Jun 23, 2026, 09:34 PM UTC

   # Post-mortem — Incident de production du 23 juin 2026 ## Résumé Le 23 juin 2026, un incident de production a rendu la plateforme principale ainsi que les accès associés indisponibles pour les utilisateurs. L’incident a été détecté à la suite d’alertes de supervision indiquant une indisponibilité des services. Les équipes techniques ont immédiatement engagé les premières actions de diagnostic et de redémarrage sur les composants applicatifs et d’infrastructure concernés. L’analyse a montré que le mécanisme de vérification de disponibilité du répartiteur de charge ne parvenait plus à valider correctement les frontaux applicatifs. Ceux-ci répondaient avec un code HTTP 403 aux requêtes de contrôle, ce qui les faisait considérer comme indisponibles, entraînant l’interruption du service. Le service a été rétabli après ajustement temporaire de la validation côté infrastructure, puis correction de la cause ayant entraîné ces réponses 403. ## Chronologie des événements Le 23 juin 2026 en début d’après-midi, les alertes de supervision ont signalé l’indisponibilité de la plateforme principale et des accès associés. Les équipes techniques ont procédé aux premières vérifications et redémarrages des composants applicatifs concernés, notamment les services web et certains serveurs frontaux. Un ticket prioritaire a été ouvert auprès de notre fournisseur d’infrastructure afin d’analyser le comportement du répartiteur de charge et des composants réseau associés. Les investigations ont ensuite porté sur l’état des pools HTTPS du répartiteur de charge, les composants d’infrastructure réseau, les serveurs frontaux et les journaux applicatifs. En fin de journée, une cellule de crise a été ouverte avec le fournisseur d’infrastructure afin d’accélérer l’analyse. Les vérifications croisées ont permis d’identifier que les requêtes de contrôle de disponibilité recevaient des réponses HTTP 403, ce qui empêchait le répartiteur de charge de considérer les frontaux comme disponibles. Une mesure temporaire a été appliquée sur la configuration du répartiteur de charge afin de rétablir le service. Après rétablissement, les équipes techniques ont poursuivi l’analyse et confirmé qu’une adresse interne utilisée pour les contrôles de disponibilité avait été bloquée. Le blocage a été levé, les réponses attendues sont redevenues conformes, puis la mesure temporaire a été supprimée. ## Difficultés rencontrées L’identification de la cause a été rendue difficile par le fait que plusieurs couches techniques pouvaient être en cause : serveurs applicatifs, configuration web, répartiteur de charge, composants réseau et infrastructure d’hébergement. Les premiers symptômes laissaient penser à un dysfonctionnement du répartiteur de charge ou de la couche réseau, car les frontaux étaient considérés comme indisponibles alors que certains services applicatifs continuaient à répondre localement. La corrélation entre le blocage d’une adresse interne et l’incident n’a été établie que tardivement, après recoupement des journaux applicatifs et des contrôles effectués pendant la cellule de crise. L’analyse a également nécessité l’intervention de plusieurs niveaux de support côté fournisseur d’infrastructure, ce qui a rallongé le temps de diagnostic. ## Cause de l’incident La cause de l’incident est le blocage d’une adresse interne utilisée par le mécanisme de contrôle de disponibilité du répartiteur de charge. À la suite de ce blocage, les requêtes de contrôle adressées aux serveurs frontaux recevaient des réponses HTTP 403 au lieu des réponses attendues. Le répartiteur de charge a alors considéré les frontaux comme indisponibles et n’a plus correctement distribué le trafic vers les services applicatifs. Cette situation a entraîné l’indisponibilité de la plateforme pour les utilisateurs. ## Perte de données Aucune perte de données n’a été constatée. L’incident a concerné l’accessibilité au service, mais n’a pas affecté l’intégrité des données stockées. ## Mesures de remédiation Les équipes techniques ont levé le blocage de l’adresse interne utilisée par les contrôles de disponibilité. Les équipes techniques ont vérifié le retour à un comportement nominal des serveurs frontaux et du répartiteur de charge. Les équipes techniques ont supprimé la mesure temporaire appliquée pendant l’incident une fois la cause corrigée. Les équipes techniques vont renforcer la supervision des contrôles de disponibilité afin de détecter plus rapidement les cas où un composant est considéré indisponible à cause d’un rejet applicatif ou réseau. Les équipes techniques vont revoir les règles de filtrage internes afin de mieux identifier les adresses techniques nécessaires au bon fonctionnement de l’infrastructure. Les équipes techniques vont documenter plus précisément les dépendances entre les contrôles de disponibilité, les serveurs frontaux et les règles de sécurité internes, afin de réduire le temps de diagnostic en cas d’incident similaire. Les équipes techniques vont améliorer les procédures d’escalade et de diagnostic avec le fournisseur d’infrastructure afin d’accélérer l’analyse lorsque plusieurs couches techniques sont susceptibles d’être impliquées.

Read the full incident report →

Started May 13, 2026, 06:41 AM UTC· resolved May 13, 2026, 06:56 AM UTC

1. investigating May 13, 2026, 06:41 AM UTC

   We are currently investigating this issue.

2. resolved May 13, 2026, 06:56 AM UTC

   This incident has been resolved.

Read the full incident report →

Started May 12, 2026, 02:49 PM UTC· resolved May 12, 2026, 03:27 PM UTC

1. identified May 12, 2026, 02:49 PM UTC

   The issue has been identified and a fix is being implemented.

2. identified May 12, 2026, 03:08 PM UTC

   We are continuing to work on a fix for this issue.

3. resolved May 12, 2026, 03:27 PM UTC

   This incident has been resolved.

4. postmortem May 13, 2026, 09:07 AM UTC

   ## Résumé Entre 15h41 et 15h55, plusieurs services de la plateforme sont devenus inaccessibles \(Discussions, accès aux fichiers\). Une perturbation a également affecté les box de fichiers, rendant impossible la navigation dans l'arborescence et la visualisation ou modification des fichiers. Les équipes techniques ont diagnostiqué et résolu l'ensemble des problèmes entre 16h49 et 17h27. ## Chronologie des événements * **15:41** — Déclenchement des premières alertes de supervision * **15:55** — Retour à la normale pour les services supervisés \(alertes OK\). * **~16h** — Remontées clients signalant l'inaccessibilité des box de fichiers \(navigation dans les dossiers, visualisation et modification de fichiers\). * **16:33** — Prise en compte officielle de l'incident par les équipes techniques. * **16:49** — Ouverture d'une page de statut. Début des actions correctives * **~17h15** — Services de nouveau pleinement opérationnels. * **17:27** — Fermeture de la page de statut. Clôture des tickets clients. ## Difficultés rencontrées * L'incident a touché plusieurs composants indépendants, ce qui a nécessité un diagnostic multi-couches. * La cause principale n'était pas immédiatement visible et a dû être corrélée avec les données de supervision. * Une erreur de permissions sur un fichier système a bloqué le redémarrage du moteur de recherche et a dû être corrigée manuellement avant de pouvoir rétablir le service. ## Cause de l'incident L'incident a été provoqué par le redémarrage inopiné de plusieurs serveurs d'infrastructure. ## Perte de données Aucune perte de données n'a été constatée. L'incident était de nature disponibilité uniquement.

Read the full incident report →

Started Apr 29, 2026, 04:33 AM UTC· resolved Apr 29, 2026, 05:40 AM UTC

1. investigating Apr 29, 2026, 04:33 AM UTC

   Un incident est actuellement en cours sur Whaller365. L’affichage et l’édition en ligne des fichiers Office sont indisponibles ou fortement perturbés. Les équipes techniques sont mobilisées pour identifier l’origine du problème et rétablir le service dans les meilleurs délais. Les autres fonctionnalités de Whaller restent accessibles. Nous publierons une mise à jour dès que nous disposerons de nouveaux éléments.

2. identified Apr 29, 2026, 05:33 AM UTC

   La cause de l'incident est identifiée. C'est une cause logicielle : une mise à jour hier soir a provoqué un dysfonctionnement sur OnlyOffice. La correction est en cours de déploiement.

3. resolved Apr 29, 2026, 05:40 AM UTC

   La correction logicielle a été passée en production. Nous vous prions de bien vouloir nous excuser pour la gêne occasionnée.

4. postmortem Apr 29, 2026, 05:44 AM UTC

   ## Résumé Le 29 avril 2026 au matin, un incident de production a rendu indisponible l’affichage et l’édition des fichiers Office dans les espaces de stockage. Les utilisateurs ne pouvaient plus ouvrir leurs documents. L’incident a été détecté suite à un signalement utilisateur. Les équipes techniques ont rapidement identifié une régression introduite lors d’une mise en production la veille et ont déployé un correctif dans la matinée. Le service a été rétabli en moins de deux heures après détection. ## Chronologie des événements * **28 avril 2026 \(soir\)** : mise en production d’une version introduisant une régression. * **29 avril 2026 06:30** : signalement de l’incident par un utilisateur. * **07:07** : identification d’une cause probable d’origine logicielle par les équipes techniques. * **07:10** : création d’un ticket de suivi. * **07:28** : déploiement d’un correctif. * **07:38** : mise en production du correctif et validation du retour à la normale. ## Difficultés rencontrées * L’incident n’a pas été détecté automatiquement, mais uniquement via un signalement utilisateur. * La régression ne concernait qu’un cas spécifique non couvert par les mécanismes de supervision existants. * Le comportement en cause dépendait d’une interaction subtile entre le client et le serveur \(gestion d’un paramètre vide\), rendant l’identification initiale moins immédiate. ## Cause de l'incident L’incident est dû à une régression introduite lors d’une mise en production, liée à une évolution fonctionnelle. Un paramètre transmis par le client était interprété différemment par le serveur selon qu’il était vide ou nul. Dans certains cas, une valeur vide empêchait la résolution correcte de la version du document, entraînant la génération d’une configuration invalide pour le service d’édition Office, et donc l’impossibilité d’afficher les fichiers. ## Perte de données Aucune perte de données n’est à signaler. Les documents n’ont pas été altérés, et l’incident n’a impacté que leur affichage et leur édition temporaire. ## Mesures de remédiation * Correction immédiate du comportement côté serveur pour normaliser les paramètres reçus. * Déploiement d’un correctif en production dans les plus brefs délais. * Renforcement des contrôles sur les cas limites liés aux paramètres transmis par le client. * Amélioration des scénarios de tests pour couvrir ce type de situation. * Réflexion en cours sur l’amélioration des mécanismes de détection proactive afin de réduire le délai de détection en cas de régression similaire.

Read the full incident report →

Started Apr 28, 2026, 06:35 AM UTC· resolved Apr 28, 2026, 07:41 AM UTC

1. investigating Apr 28, 2026, 06:35 AM UTC

   We are currently investigating this issue.

2. monitoring Apr 28, 2026, 07:19 AM UTC

   A fix has been implemented and we are monitoring the results.

3. resolved Apr 28, 2026, 07:41 AM UTC

   This incident has been resolved.

4. postmortem Apr 30, 2026, 06:36 AM UTC

   **Résumé** Le 28 avril 2026, entre 08h17 et 09h18, le service Whaller365 a été indisponible suite à la suppression automatique de la configuration Nginx lors d'une mise à jour système non supervisée. La durée totale d'indisponibilité a été d'environ 1 heure. **Chronologie des événements** * **08h17** Une mise à jour automatique du paquet `` `nginx-common` `` efface la configuration Nginx, dont les fichiers spécifiques à OnlyOffice. Nginx tente de redémarrer et échoue immédiatement. * **08h18** Les équipes techniques reçoivent une alerte signalant l'indisponibilité du service. * **08h36** Les équipes techniques confirment l'origine de l'incident et engagent la procédure de restauration. * **09h18** La configuration Nginx est intégralement reconstruite et le service OnlyOffice est rétabli. **Difficultés rencontrées** La configuration Nginx d'OnlyOffice repose sur des fichiers et liens symboliques créés manuellement, en dehors du gestionnaire de paquets. Ces éléments n'ont pas été recréés automatiquement lors de la mise à jour, ce qui a rendu la restauration entièrement manuelle. La tentative de régénération automatique via les outils de reconfiguration OnlyOffice n'a pas suffi à restaurer l'ensemble des fichiers manquants, allongeant la durée d'intervention. **Cause de l'incident** À 08h17, le système de mise à jour automatique \(`` `unattended-upgrades` ``\) a appliqué une mise à jour du paquet `` `nginx-common` ``. Durant ce processus, dpkg a réinitialisé le répertoire de configuration `` `/etc/nginx/` ``, supprimant le fichier `` `nginx.conf` `` ainsi que les liens symboliques nécessaires au fonctionnement d'OnlyOffice. Ces fichiers, créés manuellement et non gérés par dpkg, n'ont pas été préservés. Nginx n'a pas pu redémarrer après la mise à jour, rendant OnlyOffice inaccessible. **Perte de données** Aucune perte de données utilisateur n'est à déplorer. Seule la configuration système du serveur a été affectée. **Mesures de remédiation** Reconstruction complète de la configuration Nginx et rétablissement du service

Read the full incident report →

Started Nov 24, 2025, 08:36 AM UTC· resolved Nov 24, 2025, 08:15 PM UTC

1. identified Nov 24, 2025, 08:36 AM UTC

   The issue has been identified and a fix is being implemented.

2. resolved Nov 24, 2025, 08:15 PM UTC

   This incident has been resolved.

Read the full incident report →

Started Nov 21, 2025, 07:56 AM UTC· resolved Nov 21, 2025, 08:30 AM UTC

1. investigating Nov 21, 2025, 07:56 AM UTC

   Nous rencontrons actuellement des difficultés techniques affectant l'authentification et la navigation sur la plateforme. Nos équipes techniques travaillent activement à la résolution de ce problème. Nous vous tiendrons informés de l'avancement et vous présenterons nos excuses pour la gêne occasionnée.

2. identified Nov 21, 2025, 08:23 AM UTC

   Nous avons identifié le problème qui est lié aux serveurs de bases de données, nous corrigeons le problème.

3. monitoring Nov 21, 2025, 08:24 AM UTC

   Le service est revenu à la normale, nous surveillons les services et nous vous ferons part d'un post mortem détaillé.

4. resolved Nov 21, 2025, 08:30 AM UTC

   This incident has been resolved.

Read the full incident report →

Started Nov 12, 2025, 11:00 AM UTC· resolved Nov 12, 2025, 11:00 AM UTC

1. resolved Nov 13, 2025, 08:30 AM UTC

   Suite à une panne technique sur un disque hébergeant des données chez notre hébergeur, les accès à des fichiers ont pu être perturbés pour certains utilisateurs. L'incident a été résolu une fois le disque remis en service. L'incident chez notre hébergeur est disponible ici : https://hosted-private-cloud.status-ovhcloud.com/incidents/9j5l7jt7zgx8

Read the full incident report →

Started Nov 04, 2025, 09:00 AM UTC· resolved Nov 04, 2025, 09:00 AM UTC

1. resolved Nov 04, 2025, 10:52 AM UTC

   Le 4 novembre 2025, une anomalie matérielle sur un hôte VMware hébergé chez OVHCloud a entraîné une série d’alertes de supervision et une indisponibilité sur une partie de l’infrastructure. L’incident a été résolu après la mise en service d’un hôte de remplacement par OVHCloud. Chronologie des événements 10:16 : Les équipes techniques identifient, à la suite d’alertes envoyées par le système de supervision, qu’un hôte est en erreur, provoquant des alertes en continu. 10:22 : La direction technique est informée de la situation. 10:23 : OVH annonce la détection d’une anomalie matérielle sur l’hôte concerné et prévoit la livraison d’un hôte de remplacement. 11:13 : L’hôte de remplacement est livré par OVH. 11:15 : Fin de l’incident. Cause de l’incident L’incident a été causé par une anomalie matérielle sur un hôte VMware hébergé chez OVH, entraînant un comportement défaillant du nœud jusqu’à sa substitution. Perte de données Aucune perte de données n’a été constatée. Les services ont pu avoir des indisponibilités pendant la durée de l’incident.

Read the full incident report →

Started Sep 18, 2025, 07:35 AM UTC· resolved Sep 18, 2025, 09:45 AM UTC

1. identified Sep 18, 2025, 07:35 AM UTC

   The issue has been identified and a fix is being implemented.

2. resolved Sep 18, 2025, 09:45 AM UTC

   This incident has been resolved.

Read the full incident report →

Started Sep 01, 2025, 08:00 AM UTC· resolved Sep 01, 2025, 08:00 AM UTC

1. resolved Sep 01, 2025, 04:20 PM UTC

   Le 1er septembre 2025 entre 10:12 et 10:39, les utilisateurs d’une marque blanche hébergée sur Whaller ont pu connaître des problèmes d’authentification. Cela était lié à une indisponibilité du service de connexion suite à une perte de liaison avec notre cluster de données. Une fois la liaison rétablie, le service de connexion était de nouveau fonctionnel.

Read the full incident report →

Started Aug 20, 2025, 01:00 PM UTC· resolved Aug 20, 2025, 01:00 PM UTC

1. resolved Aug 20, 2025, 04:09 PM UTC

   Afin d'ajouter une couche supplémentaire de sécurité sur l'authentification via SSO, nous avons effectué une mise à jour de l'application. Une erreur de configuration a rendu indisponible l'authentification pendant 30 minutes de 15:00 à 15:30, heure à laquelle nous avons déployé un correctif.

Read the full incident report →

Started Aug 19, 2025, 07:49 AM UTC· resolved Aug 19, 2025, 12:53 PM UTC

1. identified Aug 19, 2025, 07:49 AM UTC

   The issue has been identified and a fix is being implemented.

2. resolved Aug 19, 2025, 12:53 PM UTC

   This incident has been resolved.

Read the full incident report →

Started Jul 18, 2025, 10:35 AM UTC· resolved Jul 18, 2025, 10:48 AM UTC

1. identified Jul 18, 2025, 10:35 AM UTC

   The issue has been identified and a fix is being implemented.

2. resolved Jul 18, 2025, 10:48 AM UTC

   This incident has been resolved.

Read the full incident report →

Started Jun 19, 2025, 08:09 AM UTC· resolved Jun 19, 2025, 08:49 AM UTC

1. investigating Jun 19, 2025, 08:09 AM UTC

   We are currently investigating this issue.

2. resolved Jun 19, 2025, 08:49 AM UTC

   This incident has been resolved.

3. postmortem Jun 19, 2025, 02:52 PM UTC

   ## Résumé Un incident de production a été détecté le 19 juin 2025, entraînant l’absence de marquage en non lus des nouveaux messages et commentaires \(puces et texte en gras\). L'incident a été résolu après identification de la cause et déploiement d'un correctif. ## Chronologie des événements * 19/06/2025 10:03 : Détection de l’incident. * 10:05 : Confirmation de l'incident. * 10:40 : Identification de la cause \(problème de routage du “queueing” interne\) * 10:47 : Déploiement et mise en prod du correctif * 11:50 : Fin du traitement des données en attente, fin de l'incident. ## Difficultés rencontrées * Gestion des files d'attente saturées et impact sur les services dépendants. ## Cause de l'incident La cause de l'incident a été identifiée comme étant un problème de routage du système de “queueing” interne \(traitement des instructions asynchrones\). ## Perte de données Aucune perte de données n'a été rapportée durant cet incident. ## Mesures de remédiation * Correctif déployé : Une nouvelle version a été déployée pour corriger le problème. * Surveillance renforcée : Les équipes techniques ont renforcé la surveillance des files d'attente pour détecter rapidement tout comportement anormal. * Amélioration des processus : Révision des processus de déploiement pour éviter des incidents similaires à l'avenir.

Read the full incident report →

Started Jun 02, 2025, 02:30 PM UTC· resolved Jun 02, 2025, 02:30 PM UTC

1. resolved Jun 02, 2025, 03:07 PM UTC

   Certaines pages ont été inaccessibles pendant quelques instants suite à une modification de la configuration des notifications. Vous pouvez maintenant choisir si vous désirez recevoir le son des notifications du service Discussions.

Read the full incident report →

Started May 23, 2025, 10:20 AM UTC· resolved May 23, 2025, 11:00 AM UTC

1. identified May 23, 2025, 10:20 AM UTC

   The issue has been identified and a fix is being implemented.

2. resolved May 23, 2025, 11:00 AM UTC

   This incident has been resolved.

Read the full incident report →

Started May 20, 2025, 08:30 AM UTC· resolved May 20, 2025, 12:07 PM UTC

1. identified May 20, 2025, 08:30 AM UTC

   The issue has been identified and a fix is being implemented.

2. monitoring May 20, 2025, 10:21 AM UTC

   A fix has been implemented and we are monitoring the results.

3. monitoring May 20, 2025, 11:59 AM UTC

   We are continuing to monitor for any further issues.

4. resolved May 20, 2025, 12:07 PM UTC

   This incident has been resolved.

Read the full incident report →

Started May 09, 2025, 09:00 AM UTC· resolved May 09, 2025, 09:00 AM UTC

1. resolved May 09, 2025, 01:58 PM UTC

   La plateforme a été inaccessible quelques instants suite à une indisponibilité de notre cluster de données. L'équipe technique a résolu rapidement cette inaccessibilité.

Read the full incident report →

Started Apr 23, 2025, 09:08 AM UTC· resolved Apr 23, 2025, 09:21 AM UTC

1. identified Apr 23, 2025, 09:08 AM UTC

   Le module de messagerie instantanée est momentanément indisponible. Nous ajoutons des ressources aux machines concernées. Le service sera rétabli d'ici quelques minutes.

2. resolved Apr 23, 2025, 09:21 AM UTC

   Le services "Discussions" est à nouveau disponible. Merci de votre compréhension.

Read the full incident report →

Started Apr 23, 2025, 06:30 AM UTC· resolved Apr 23, 2025, 06:30 AM UTC

1. resolved Apr 23, 2025, 07:33 AM UTC

   Certains utilisateurs ont pu avoir des problèmes d'accès à Whaller, suite à une défaillance technique de notre hébergement. -- Ce ticket sera complété au fur et à mesure de nos investigations

Read the full incident report →

Started Apr 23, 2025, 06:00 AM UTC· resolved Apr 23, 2025, 06:00 AM UTC

1. resolved Apr 23, 2025, 06:53 AM UTC

   Nous subissons actuellement un incident sur le service principal de Whaller. La cause est identifiée et nos équipes sont en train de tout faire pour rétablir la situation.

Read the full incident report →