Is Wisembly Down Right Now? Check if there is a current outage ongoing.

Suite à la migration, un service de remontée de statistique d'envoi d'email n'a pas été correctement remonté : les statistiques des campagnes envoyées entre le 28 aout et le 4 septembre inclus sont malheureusement perdues. Rassurez-vous, il s'agit uniquement des statistiques, tous les emails ayant bien été envoyés. De plus, il semblerait que certains templates d'email comportant des émojis aient subis un souci d'encodage. Merci de vérifier que vos mails sont conforme à vos programmations d'avant le 28 aout. En nous excusant pour ces désagréments

Les statistique d'envoi de vos campagnes d'emails sont momentanément indisponibles. Dû à un très grand nombre d'envois en cette rentrée, nos systèmes sont submergés de requêtes. Nous mettons tout en oeuvre pour accélérer la récupération de statistiques et faire en sorte que les "gros" événements ne pénalisent pas les plus petits.

L'incident est résolu. Une forte affluence sur un événement public couplé avec des requêtes spam ont entrainé un mini DDOS de notre infrastructure durant près d'une heure. Nos équipes analysent encore les logs afin de prendre les mesures nécessaires pour permettre de prévenir et mitiger ce genre d'incident assez rare.

L'application n'est plus accessible. Les serveurs frontaux présentent d'importantes annomalies de charge et de CPU. Nos équipes et celles de notre hébergeur investiguent pour résoudre la situation au plus vite.

Le souci a été réglé. Le code fautif a été corrigé et les images restituées d’après la dernière sauvegarde.

Nous avons constaté la disparition des images de bannière des pages d'événement. Après investigation, un side-effect indésirable sur le code serveur a par mégarde supprimé le dossier contenant ces images. Nous procédons à une récupération du dernier backup afin de restituer la majorité de ces images (depuis notre dernier point de sauvegarde valide). Nous vous tiendrons informés ici de l'avancement de cette restitution. Entre temps, il vous est toujours possible de ré-uploader ces images afin de minimiser la gêne occasionnée sur vos pages, cela n'aura pas d'incidence avec la restitution du backup.

Nous avons été alerté du fait que les replays vidéo des sessions n'étaient pas disponibles sur l'application une fois celles-ci terminées, ni depuis la zone de téléchargement. Après investigation, le déploiement d'un nouveau provider vidéo Blastream a eu un effet de bord sur la récupération des replays (Blastream, Vonage). L'incident a été fixé jeudi 29 septembre à 19h30. Les replays non récupérés automatiquement par Wisembly ont été récupérés manuellement pour la majeure partie d'entre eux. Il se peut malheureusement que certains replays du provider Vonage non récupérés sous 72h aient été définitivement perdus (1 seul à notre connaissance et d'après les logs). Nous nous excusons d'avance pour la gêne occasionnée.

This incident has been resolved.

As our DNS provider OVH is investigating the problem, we decided 1h ago do disable DNSSEC validation of our domain to avoid this temporary issue. We observe the propagation of this setting on the ICANN registry and this should fix the problem for our users. Our Pingdom probes are green again. We'll keep this configuration until next Thursday to ensure OVH properly address the issue before enabling it back. Sorry again for the inconvenience

OVH has identified the root cause and escalated the issue to the right team. This hopefully should be fixed in the upcoming minutes...

We experience a DNSSEC problem in our DNS Zone. The *.wisembly.com DNS are not reachable for some of our users. We are currently investigating with our DNS provider OVH to fix this issue. We'll update this ticket when we have news from them.

We are up again since 12:44 (Paris Time). We are waiting for a post mortem from our housing provider.

Investigations are still ongoing, but it appears now that our provider IT backbone is at fault.

We are currently down, due to a problem on our hosting provider Claranet side. They are investigating.

Nous avons constaté une impossibilité de finaliser une inscription à un Wiz depuis la landing page de ce dernier. En effet, l'inscription est bien prise en compte, mais un souci de génération d'email (celui de confirmation avec l'.ics en pièce jointe) bloque la fin du processus. L'équipe travaille à la résolution de cet incident.

The monitoring showed no more problems, the delay observed resorbed itself after some time, once all events where correctly de-queued.

We currently experience delay for some push events, probably related with the previous backend incident. We're investigating

Nos alertes automatiques nous ont remonté des soucis **le mercredi 16 septembre à 11h43** \(heure de Paris\). Soucis mineurs dans un premier temps, donnant lieu à une simple alerte de routine auprès de notre hébergeur. \(dumps Redis trop longs\) Ces erreurs se sont intensifiés au retour de la pause déjeuner \(**vers 13h54**\). Nous avions des dump Redis désormais impossible, et ayant des effets de bord sur MySQL. Nous avons ce coup-ci escaladé l'issue précédente en souci "majeur". Vers 14h30, après investigation de l'équipe tech et de Claranet, nous avons constaté un trop gros usage RAM de Redis pour les sauvegardes automatiques toutes les 2 minutes. Nous avons décidé à **14h39**, première action de notre part, de limiter la taille des dump Redis, quitte à tronquer les anciennes valeurs, afin de préserver l'intégrité de la base principale MySQL. Les sondes de performances indiquent : * une dégradation des temps de réponse de l'application à partir de 12h43 \(passage de 120ms temps moyen en haute activité à 209ms sur la période\) * une augmentation du taux d'erreur à partir de cette même heure, passant de 0,0812% à 2,39% L'action faite à 14h39 n'a malheureusement pas suffit à endiguer l'escalade de l'usage de la RAM des serveurs backend qui ont fini par lâcher à **14h49**. Les équipes Claranet ont été informées dans la minute de l'incident, étant déjà en ligne pour les soucis de RAM sus-mentionnés. Après enquête sommaire, et avoir escaladé en interne chez eux l'incident, il a été décidé de forcer la bascule du backend sur le serveur slave et de redémarer le master, en y ajoutant 10Gb de RAM. Une fois ceci effectué, le trafic a été re-basculé sur le master, puis ce fut au tour du slave de redémarer avec plus de RAM. A **15h09** précisément, 90% de l'infrastructure était à nouveau disponible et opérationnelle. Le serveur de temps réel était impacté par ces opérations et diffusait les événements live en long polling \(toutes les 60 secondes\). Nous avons été alerté de ceci vers 15h19 \(10 minutes après la fin de l'avarie majeure\), et avons effectué les mesures nécessaires sur cet élément à 15h27. Les symptômes de cette avarie ont été les suivants: * tout participant déjà sur Wisembly ne pouvait que consulter le contenu déjà présent, et ne pouvait pas en ajouter de nouveau * tout animateur/administrateur de Wiz ne pouvait pas lancer de sondage/passer un document/changer de slide * en revanche, les solutions Visio collab et Live event n'ont pas été affectée par ce souci, tout comme les intégrations tierces parties \(Zoom, Webex, etc..\). **=> Pour les participants en cours de réunion, cette avarie s'est traduite par une perte complète des fonctionalités d'interactivité, mais pas de flux audio/vidéo** **=> Pour les participants/administrateurs cherchant à rejoindre une réunion en cours ou à venir, ils ont été dans l'incapacité de le faire de 14h49 à 15h09** Cet incident, dû à une surconsomation de la RAM des serveurs de backend hébergeant les bases de données et queues de messages, a été réglé à court et moyen terme par une augmentation de 40% de la RAM de ces machines \+ redémarrage. Les équipes Wisembly et Claranet, de concert, dans les prochains jours, vont étudier en détail la consommation de la RAM de chacun des applicatifs de ces serveurs pour être plus efficient, et aboutir à une solution nominale pérenne à la vue de l'augmentation des usages de la plateforme Wisembly de ces derniers mois et des mois à venir. Veuillez contacter l'équipe Success si vous avez été impacté par cet incident et que cette dernière n'est pas déjà revenue vers vous. Nous avons des offres d'indemnisations à vous proposer.

We added more RAM (10Gb) to the concerned machines (bdd-01a, bdd-01b), and all is working back like a charm. We'll work in the upcoming weeks to reduce these databases footprint to rely less on the machines RAM.

The issue was provoked by one of our databases that could not make automatics dumps due to machine memory restriction. This instability grew up and provoked a major failure to other databases. We made a RAM increase and rebooted the faulty machine to brings all the systems operational again. We are investigating now the root of the automated backup failure.

As of today, 14h49 (Paris time), Wisembly application suffered a total outage, users and administrators being unable to access it. The team was immediately alerted and we escalated the issue to our hosting provider. At 15h09, after 5 minutes of investiguation, we decided to reboot the backend machines that were saturated, and the application went up again. We suffered a 20 minutes downtime. The team is actually investigating the issue, for further details. [EDIT] After more precise logs and performance investiguation, it appears that the application was heavily slowed down since 13h53 (Paris time), due to the previous failure that was growing at that time and consuming more and more resources before crashing.

Between 2:35pm and 3:02pm this day, we were unable to process uploaded documents on Wisembly in order to present them. Our media converter automatic https certificate renewal mechanism failed for a yet unknown reason. We manually renewed the certificate when a customer contacted our support at 2:40pm. It took us 17 minutes to investigate an find the problem, 4 minutes more to manually run the script and re-launch pending conversions. We'll identify in the next days the reasons of this failure and will prevent it in the future. Best

De 14h à 14h20 les utilisateurs connectés ont rencontré diverses erreurs applicatives, comme des difficultés pour naviguer sur les Wiz, modérer ou réagir à des messages. Le souci a été trouvé à 14h10, il s'agit d'une librairie 3rd party de NPS qui a brusquement changé et produit ces erreurs, affectant partie de l'application. Le temps de retirer cette librairie et de le propager sur les différents serveurs, les soucis se sont estompés dès 14h15 pour complètement disparaitre à 14h20. Nous avons contacté le support de ce 3rd party pour comprendre comment cela a pu se produire, et éviter ces soucis à l'avenir lorsque nous le réactiverons. Désolé pour la gène occasionnée.

# 20151506 App down incident #### What happened Today at 04:46:50pm GMT+1 our application went down, for 11 minutes. Our team has been alerted few minutes later by automated probes and error logs. We went into our servers to see the problem. We found an important RAM consumption by our MySQL process, threatening the overall system RAM, preventing REDIS backup daemon to perform its regular backup snapshots. This problem affected some REDIS enabled API endpoints that made our PHP-FPM processes going wild. #### What we did We restarted MySQL process in order clear the buffer cache in RAM and make some room for other processes, especially REDIS automated backups. It was not sufficient, we had to restart PHP-FPM too to cool things down a bit. Once done, all system went green again #### How to avoid that in the future We looked into our server configuration with our backend team and housing provider, and clearly showed that the allowed RAM for MySQL was a bit edgy and could lead to what happened. We reduced so the allowed buffer size by 75%, leaving us enough room to cache all the needed things and leave enough space for all the other processes on the backed servers. We restarted again MySQL to take the configuration into account, and closely monitoring it performances in the near future.

All systems are up again. We'll write shortly a post-mortem explaining what happened, what we've done and how to prevent that to happen again.

Application is up now, we restarted crippled processes. We're investigating further to understand what happened and keep you informed. Sorry for the trouble.

We currently have a major app outage. We are investigating and trying our best to make the thins up again.

Migration had been stopped because it was taking too much time. We will plan it again probably during the end of the year holidays to avoid any disturbance. Sorry for that

Maintenance is ongoing. It may take a little bit longer than expected, migration is still in progress to crypted backend partition. Application still in read-only mode, expect full downtime when switching around 8:10am GMT+1 for 5 minutes. Sorry for the inconvenience

We plan to activate full backend drives encryption for more security on our platform. The application will be in read-only mode (only accessing the data) during 7:30am to 7:50am (Paris Time) and probably unavailable from 7:50am to 8:00am. We'll inform you during the process. Thanks for your comprehension.

This incident has been resolved.

We deployed a new config for our logging system and we'll see if it improves performances and limit messages queue size. If so, we will roll out this new config on production environments in a few days.

Our log manager system rsyslog appeared to have filled up all its buffer while experiencing difficulties to send logs to our various log visualisation tools. It freezed the network stack of our frontals servers, making our solution unreachable until the buffer pool empties. We are monitoring now closely rsyslog and considering updating its version to a newer and more robust one or using other ways to collect and send our logs, in a non-blocking way.

We had a service disruption from 2:25pm to 2:37pm (12 minutes). We suspect an internal logging system that caused a system overflow on the network stack, making our application unreachable during this time. We'll post here more info as we investigate further. Sorry for the inconvenience.

All systems are now operational.

Our hosting provider was experiencing a DDOS Attack and it seems it is starting to mitigate it. We'll watch closely the performances in the next couple minutes and update this incident once closed. Sorry again for the inconvenience.

We currently have an issue with our housing provider on its infrastructure. It appears that the various applications hosted there encounter difficulties to respond in a timely fashion. Their teams are investigation, we'll keep you informed. Sorry for the inconvenience.

Difficulties to deploy an update with our server provider.

We currently have a major app outage. We are investigating and trying our best to fix it.

This incident has been resolved.

Our housing provider is currently under DDOS attack and all the hosted services like Wisembly under their firewalls are currently unreachable. They are trying to mitigate the attack, Wisembly will be up and running again once they do that. Sorry for the inconvenience

Le souci provient de notre hébergeur et de l'infrastructure cloud hébergeant notre application. Un souci d'hyperviseur et de latence au niveau de la baie de stockage a bloqué notre application ces quelques minutes. Notre hébergeur investigue plus en détail pour comprendre l'origine de ce souci.

L'application est de nouveau disponible. Nous investiguons auprès de notre hébergeur pour trouver les causes de l'incident.

L'application est momentanément indisponible. Nous investiguons avec nos équipes et notre hébergeur.

Notre hébergeur a résolu l'incident. L'accès à l'application est désormais rétabli.

Notre hébergeur Oxalide rencontre des soucis de pare-feux rendant l'accès à Wisembly impossible.

Un souci d'infrastructure a ce week end durant 2 heures empêché partiellement ou totalement l'accès à certains Wiz en cours. Une consommation inhabituelle de RAM sur le serveur principal a entrainé l'incapacité à effectuer les sauvegardes continues des Wiz actifs, provoquant des soucis d'accès à ces derniers, le temps que les équipes d'astreintes redémarrent le service fautif.

Un de nos fournisseurs de SMS rencontre actuellement des soucis et ne reçoit pas tous les SMS.