Whaller Outage History

Started Mar 24, 2025, 09:33 AM UTC· resolved Mar 25, 2025, 02:51 PM UTC

1. investigating Mar 24, 2025, 09:33 AM UTC

   We are currently investigating this issue.

2. monitoring Mar 24, 2025, 10:31 AM UTC

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

3. resolved Mar 25, 2025, 02:51 PM UTC

   This incident has been resolved.

Read the full incident report →

Started Mar 12, 2025, 07:08 PM UTC· resolved Mar 12, 2025, 09:44 PM UTC

1. investigating Mar 12, 2025, 07:08 PM UTC

   Les fichiers sur la production sont inaccessibles. A première vue il s'agit d'un incident de notre hébergeur OVHcloud. Nous vous tenons informés.

2. investigating Mar 12, 2025, 07:18 PM UTC

   L'incident est lié à notre hébergeur OVHcloud, voici l'URL de suivi de son incident dont Whaller dépend : https://public-cloud.status-ovhcloud.com/incidents/9myc4g6tfvlb

3. resolved Mar 12, 2025, 09:44 PM UTC

   This incident has been resolved.

4. postmortem Mar 12, 2025, 09:44 PM UTC

   # Postmortem : Fichiers inaccessibles ## Résumé Le 12 mars 2025, une indisponibilité des fichiers a été constatée sur Whaller SaaS. Cet incident était dû à un problème chez notre hébergeur OVHcloud, qui a rencontré un dysfonctionnement de son service Keystone API à partir de **18:15 UTC** \(19:15 heure locale\). L'indisponibilité a duré **3 heures et 10 minutes**, le problème ayant été résolu à **21:25 UTC** \(22:25 heure locale\). Durant cette période, les fichiers hébergés sur Object Storage étaient inaccessibles, sauf ceux mis en cache \(images\). Le service a été rétabli après la résolution de l'incident par OVHcloud et une vérification de notre côté. ## Chronologie des événements * **18:15 UTC \(19:15 heure locale\)** : Début de l'incident chez OVHcloud, affectant le service Keystone API. * **19:59** : Détection d'un problème d'affichage de fichiers et de logos dans l'annuaire sur Whaller. * **20:08** : Déclaration de l'incident sur StatusPage par les équipes techniques de Whaller. * **20:12** : Création d'un incident chez OVHcloud pour suivi. * **20:18** : Confirmation que l'incident est lié à OVHcloud, suivi de l'incident sur leur plateforme. * **21:25 UTC \(22:25 heure locale\)** : OVHcloud annonce la résolution du problème. * **22:40** : Clôture de l'incident chez OVHcloud après vérification du retour à la normale. * **22:43** : Vérification de l'accès aux fichiers et clôture de l'incident sur Whaller. ## Difficultés rencontrées ### Côté OVHcloud : * Une panne du service Keystone API a rendu l’authentification impossible pour les services Object Storage utilisés par Whaller * Le diagnostic initial a pris du temps, allongeant la durée de l’incident. ### Côté Whaller : * Aucune action technique directe possible, la dépendance à OVHcloud limitant les capacités d’intervention. * Le manque d’informations précises au début de l’incident a retardé la confirmation de l’origine du problème mais n'a pas impacté la résolution en temps que telle ## Cause de l'incident Un dysfonctionnement du service Keystone API d’OVHcloud a entraîné une impossibilité d’authentification aux services de stockage, impactant la disponibilité des fichiers Whaller SaaS stockés sur Object Storage. ## Perte de données Aucune perte de données n’a été constatée. L’accès aux fichiers a été rétabli dès la résolution de l’incident. ## Source Voici le lien vers le postmortem OVHcloud : [https://public-cloud.status-ovhcloud.com/incidents/9myc4g6tfvlb](https://public-cloud.status-ovhcloud.com/incidents/9myc4g6tfvlb)

Read the full incident report →

Started Mar 12, 2025, 08:30 AM UTC· resolved Mar 12, 2025, 09:41 AM UTC

1. identified Mar 12, 2025, 08:30 AM UTC

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

2. identified Mar 12, 2025, 09:19 AM UTC

   Nous avons désactivé temporairement l'édition en ligne des fichiers office en raison du problème initial, en effet les fichiers édités paraissent vides et enregistrent ainsi des versions vides des fichiers. Si vous avez été dans ce cas, nous vous invitons à restaurer la version précédente du fichier pour le retrouver. Le téléchargement fonctionne.

3. resolved Mar 12, 2025, 09:41 AM UTC

   Nous avons identifié le problème et corrigé. L'édition des fichiers en ligne a été restauré. Si des fichiers que vous auriez édité pendant la période de l'incident sont vides, nous vous invitons à simplement restaurer une version précédente via "Historique des versions". Les données n'ont pas été perdues.

4. postmortem Mar 12, 2025, 05:17 PM UTC

   Le 12 mars 2025 entre 7:50 et 10:45, un incident a affecté l'éditeur et la visionneuse de documents, affichant des fichiers vides lors de l'édition ou de la visualisation en ligne. Les équipes techniques ont rapidement identifié et résolu le problème. Aucune perte de données n'a été constatée. ## Chronologie des événements * **07:50** : Début de l'incident. * **09:16** : Découverte de l'incident. Les documents apparaissent vides dans l'éditeur et la visionneuse. * **09:20** : Les équipes techniques commencent l'investigation pour comprendre l'origine du problème. * **09:37** : Identification d'une erreur de communication entre Whaller365 et le serveur de fichiers. * **10:18** : Déploiement d'un correctif pour bloquer l'édition en ligne, afin de ne pas créer de documents vides. * **10:20** : Redémarrage des serveurs Whaller365. * **10:42** : Déploiement d'un correctif pour rétablir l'édition en ligne et résolution de l'incident. * **12:24** : Fin de la vérification globale des fichiers, aucune perte de données constatée. ## Difficultés rencontrées * Identification de la cause racine due à la complexité de l'interaction entre Whaller365 et le serveur de fichiers. * Gestion des effets de bord imprévus lors de l'enregistrement des fichiers. ## Cause de l'incident L'incident a été causé par une erreur de communication entre Whaller365 et le serveur de fichiers, résultant en des fichiers vides lors de l'édition et la visualisation en ligne. ## Perte de données Aucune perte de données n'a été constatée. Les fichiers ont été vérifiés et sont intacts. ## Mesures de remédiation * Déploiement de correctifs pour stabiliser l'édition en ligne. * Amélioration des mécanismes de surveillance pour détecter rapidement les erreurs de communication entre les services.

Read the full incident report →

Started Feb 20, 2025, 08:08 AM UTC· resolved Feb 20, 2025, 08:47 AM UTC

1. identified Feb 20, 2025, 08:08 AM UTC

   Des ralentissements peuvent être observés sur l'envoi des emails

2. resolved Feb 20, 2025, 08:47 AM UTC

   This incident has been resolved.

Read the full incident report →

Started Feb 10, 2025, 09:29 AM UTC· resolved Feb 10, 2025, 09:35 AM UTC

1. identified Feb 10, 2025, 09:29 AM UTC

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

2. resolved Feb 10, 2025, 09:35 AM UTC

   This incident has been resolved.

Read the full incident report →

Started Feb 06, 2025, 08:08 AM UTC· resolved Feb 06, 2025, 08:57 AM UTC

1. investigating Feb 06, 2025, 08:08 AM UTC

   Nous subissons un problème sur le mécanisme d'authentification SSO qui est impossible sur les sites en marque blanche. Nos équipes sont mobilisées pour résoudre ce problème au plus vite.

2. identified Feb 06, 2025, 08:18 AM UTC

   Le problème a été identifié, c'est un problème de librairie de code. Nos équipes techniques sont en train de réparer.

3. resolved Feb 06, 2025, 08:57 AM UTC

   L'incident est résolu, l'authentification SSO fonctionne à nouveau. Nous publierons un postmortem dans la journée.

4. postmortem Feb 07, 2025, 04:26 PM UTC

   # Post-mortem : Incident de connexion SSO sur les sites en marque blanche ## Résumé Le 6 février 2025, un incident a rendu impossible la connexion via SSO sur les sites en marque blanche. L'incident a été signalé par un client et confirmé par les équipes techniques. La cause principale était une constante manquante dans le code d'une librairie tierce. Une correction a été déployée en production à 10h56, rétablissant le service. ## Chronologie des événements * **08:43** : Réception d'un e-mail client signalant l'impossibilité de se connecter. * **08:52** : Les équipes techniques sont alertées. * **08:54** : Prise en charge de l'incident. * **09:09** : Création d'une page StatusPage indiquant l'incident. * **09:12** : Identification de la cause : une constante absente dans le code. * **09:36** : Soumission d'une correction pour un problème lié au SSO. * **09:48** : Mise en production d'une première correction générique * **10:56** : Mise en production d'une seconde correction spécifique à une marque blanche particulière, rétablissant pleinement le service. ## Difficultés rencontrées * Identification tardive du lien avec le problème rencontré la veille. * Déploiement de plusieurs corrections distinctes pour résoudre l'ensemble des problèmes liés au SSO. ## Cause de l'incident Une constante essentielle pour l'authentification SSO était absente dans le code d'une librairie tierce récemment mise à jour, empêchant le bon fonctionnement de la connexion. ## Perte de données Aucune perte de données n'a été constatée. L'incident a uniquement impacté l'accès au service. ## Mesures de remédiation * Mise en place d'une surveillance renforcée des connexions SSO pour anticiper les défaillances. * Documentation du processus de gestion des incidents pour une meilleure réactivité en cas de problème similaire à l'avenir.

Read the full incident report →

Started Feb 04, 2025, 08:27 AM UTC· resolved Feb 04, 2025, 09:22 AM UTC

1. identified Feb 04, 2025, 08:27 AM UTC

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

2. monitoring Feb 04, 2025, 09:11 AM UTC

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

3. resolved Feb 04, 2025, 09:22 AM UTC

   This incident has been resolved.

Read the full incident report →

Started Jan 17, 2025, 11:00 PM UTC· resolved Jan 17, 2025, 11:00 PM UTC

1. resolved Jan 20, 2025, 09:28 AM UTC

   Durant le week-end du 18/19 janvier 2025, l'accès aux fichiers a pu être indisponible pour certains utilisateurs. Ceci était lié à un matériel physique défaillant sur l'infrastructure qui supporte la passerelle donnant l'accès aux fichiers. Nous avons résolu les erreurs lundi matin 9:30. Aucune perte de données n’a été constatée durant l’incident.

2. postmortem Jan 20, 2025, 09:50 AM UTC

   Durant le week-end du 18/19 janvier 2025, l'accès aux fichiers a pu être indisponible pour certains utilisateurs. Ceci était lié à un matériel physique défaillant sur l'infrastructure qui supporte la passerelle donnant l'accès aux fichiers. Nous avons résolu les erreurs lundi matin 9:30. Aucune perte de données n’a été constatée durant l’incident.

Read the full incident report →

Started Jan 17, 2025, 04:32 PM UTC· resolved Jan 17, 2025, 05:38 PM UTC

1. investigating Jan 17, 2025, 04:32 PM UTC

   We are currently investigating this issue.

2. monitoring Jan 17, 2025, 04:35 PM UTC

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

3. resolved Jan 17, 2025, 05:38 PM UTC

   This incident has been resolved.

4. postmortem Jan 22, 2025, 01:53 PM UTC

   ### Rapport de Postmortem - Incident du 16 au 19 janvier 2025 #### Résumé Un incident de performance a été détecté après la mise en production d'une nouvelle version du service Discussions, résultant en des temps de chargement excessifs lors de la création de discussions. Plusieurs tentatives de correction ont été menées sans succès avant qu’une solution définitive ne soit mise en place le 19 janvier 2025. #### Chronologie des événements * **16 janvier 2025 à 16:00** : Mise en production de la nouvelle version du service Discussions. * **17 janvier 2025 à 18:00** : Rollback d’un composant sans impact sur le problème. * **18 janvier 2025 à 18:00** : Mise en production d’un correctif ajoutant un throttle \(limitation du débit de traitement des messages\) sur la récupération des messages, sans effet. * **19 janvier 2025 à 14:00** : Mise en production d’un correctif final corrigeant le problème. #### Difficultés rencontrées * Difficulté à reproduire le problème sur les environnements de test. * Synchronisation défaillante entre les différents onglets du navigateur, provoquant une surcharge et un blocage du navigateur. #### Cause de l'incident Une mauvaise gestion de la communication entre onglets a entraîné une surcharge du navigateur. #### Perte de données Aucune perte de données utilisateur n’a été détectée. #### Mesures de remédiation * Correction de la gestion des onglets pour éviter les communications redondantes. * Amélioration de la gestion des débits de messages entrants. * Mise à jour du core pour stabiliser l’interface avec le serveur ejabberd.

Read the full incident report →

Started Dec 19, 2024, 04:00 PM UTC· resolved Dec 19, 2024, 04:00 PM UTC

1. resolved Dec 20, 2024, 08:55 AM UTC

   Whaller365 a été inaccessible jeudi 20 décembre 2024 de 18:10 à 18:50 suite à une erreur de configuration. Une fois la configuration corrigée, les services ont fonctionné de nouveau correctement. Il n'y a eu aucune perte de données sur cette période. Les utilisateurs ont uniquement rencontré une indisponibilité temporaire.

Read the full incident report →

Started Nov 08, 2024, 07:16 AM UTC· resolved Nov 08, 2024, 08:04 AM UTC

1. investigating Nov 08, 2024, 07:16 AM UTC

   Nous subissons des lenteurs sur la production mutualisée. Le site est cependant accessible, nous vous tenons informés. --- We are experiencing slowdowns in shared production. The site is still accessible, however, and we will keep you informed.

2. identified Nov 08, 2024, 07:52 AM UTC

   Nous avons identifié le problème, nous sommes en train de le corriger et redémarrer les services concernés. --- We have identified the problem and are in the process of correcting it and restarting the services concerned.

3. resolved Nov 08, 2024, 08:04 AM UTC

   Les services défaillants ont été redémarrés, la production a retrouvé une performance nominale.

4. postmortem Nov 26, 2024, 10:40 AM UTC

   ### Postmortem Incident de Production - Lenteurs du 8 novembre 2024 #### Résumé Le 8 novembre 2024, des lenteurs importantes ont été constatées sur nos services de production, avec un temps de réponse moyen multiplié par deux et une hausse significative des erreurs. L’incident a été résolu après une série d’actions sur l’infrastructure, notamment la réactivation de services critiques. Ce document présente les événements, les causes et les mesures prises pour éviter toute récurrence. #### Chronologie des événements * **~00h00** : Début des anomalies \(suite à un remplacement de hosts sur l'infrastructure par OVHcloud\). * **07h08** : Les équipes techniques sont alertées suite aux notifications OVHcloud. * **08h11** : Confirmation de la dégradation de performance. Les équipes techniques identifient un taux d’erreur accru et un ralentissement général. * **08h16** : Une communication est publiée sur Statuspage pour informer les utilisateurs. * **08h26** : Redémarrage des processus ProxySQL sur les frontaux SaaS. * **08h45** : Inaccessibilité de certains services. * **08h57-09h01** : Réactivation des interfaces réseau et redémarrage des services. * **09h14** : Identification de VM avec des configurations réseau incorrectes \(non connectées au boot\). * **09h16** : Correction des configurations réseau sur les VM concernées. * **09h30** : Fin de l’incident #### Difficultés rencontrées 1. **Communication tardive des anomalies** : Les anomalies n’ont été identifiées qu’après plusieurs heures. 2. **Manque de redondance immédiate** : La dépendance à des configurations manuelles a retardé la résolution. 3. **Outils non opérationnels** : Certaines VM critiques n’étaient pas accessibles. #### Cause de l’incident L’incident a été causé par une mise à jour de l’infrastructure chez notre hébergeur \(remplacement de hosts physiques [\[RBX8\]\[Hosted Private Cloud\] - Racks R806L22/23/24](https://hosted-private-cloud.status-ovhcloud.com/incidents/fl439stlh482) \), qui a désactivé les interfaces réseau sur plusieurs machines virtuelles critiques. Cela a provoqué des dysfonctionnements dans des services essentiels. #### Perte de données Aucune perte de données n’a été constatée. Toutefois, certains traitements ont pu être retardés, entraînant des temps de réponse prolongés pour les utilisateurs. #### Mesures de remédiation 1. **Audit des configurations réseau** : Vérification de l’activation automatique des interfaces réseau sur toutes les VM. 2. **Automatisation des vérifications post-maintenance** : Déploiement d’outils pour détecter les anomalies après des opérations d’infrastructure. 3. **Amélioration de la supervision** : Renforcement des alertes sur les indicateurs de performance \(taux d’erreur et temps de réponse\). 4. **Plans de redondance** : Révision des mécanismes de basculement automatique pour limiter l’impact des incidents similaires.

Read the full incident report →

Started Oct 30, 2024, 01:30 AM UTC· resolved Oct 30, 2024, 01:30 PM UTC

1. resolved Oct 30, 2024, 02:43 PM UTC

   Suite à un incident chez notre hébergeur, la plateforme Whaller a été inaccessible durant 10 minutes entre 14:30 et 14:40. Pour plus d'informations : https://network.status-ovhcloud.com/incidents/qgb1ynp8x0c4

2. postmortem Nov 26, 2024, 01:15 PM UTC

   ### Postmortem Incident de Production - Inaccessibilité du 30 octobre 2024 #### Résumé Le 30 octobre 2024, le service a été temporairement inaccessible en raison d’un incident réseau chez notre hébergeur, OVHcloud. Le problème a été résolu rapidement, mais l’accès à notre plateforme a été perturbé pendant environ 9 minutes. #### Chronologie des événements * **14h16** : Début d’une mauvaise configuration sur un réseau pair \(Worldstream\), provoquant une saturation des liens de peering OVHcloud. * **14h30** : Nos équipes sont informées de l’inaccessibilité de notre plateforme. * **14h38** : OVHcloud met en place une mitigation. * **14h39** : Retour à la normale confirmé, incident clôturé côté Whaller. * **14h40** : L’incident est résolu côté OVHcloud. #### Difficultés rencontrées 1. **Dépendance à l’infrastructure réseau d’un fournisseur externe** : Les instabilités de réseau ont eu un impact direct sur l’accès à nos services. 2. **Temps limité pour réagir** : Bien que l’incident ait été résolu rapidement par OVHcloud, il a affecté nos utilisateurs avant que nous puissions intervenir. #### Cause de l’incident L’incident a été causé par une configuration défectueuse sur un réseau pair utilisé par OVHcloud. Cette configuration a conduit à une saturation des liens de peering, affectant la connectivité de plusieurs clients OVHcloud, y compris notre plateforme. #### Perte de données Aucune perte de données n’a été constatée. Les utilisateurs ont uniquement rencontré une indisponibilité temporaire. #### Mesures de remédiation 1. **Renforcement des alertes réseau** : Mise en place d’alertes pour détecter rapidement les dégradations réseau externes. 2. **Communication améliorée** : Collaboration étroite avec OVHcloud pour une notification proactive des incidents critiques. Nous vous remercions pour votre compréhension et votre patience lors de cet incident. Si vous avez des questions, n’hésitez pas à nous contacter.

Read the full incident report →