Whaller Status
Real-time updates of Whaller issues and outages
Whaller status is Operational
Whaller Main application
You're checking on Whaller - but is your own site converting?
Outages aren't the only thing that costs you visitors.
Get a visual audit that shows exactly where your site loses conversions.
Free, takes 2 minutes.
Active Incidents
We are currently investigating this issue.
Postmortem: # 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.
Post-mortem — Production incident of 23 June 2026
Summary
On 23 June 2026, a production incident rendered the main platform and associated access points unavailable to users.
The incident was detected following monitoring alerts indicating that services were unavailable. The technical teams immediately began initial diagnostic checks and restarted the affected application and infrastructure components.
Analysis revealed that the load balancer’s availability check mechanism was no longer able to correctly validate the application front-ends. These were responding to check requests with an HTTP 403 code, which caused them to be treated as unavailable, resulting in the service interruption.
The service was restored following a temporary adjustment to the infrastructure-side validation, followed by the correction of the cause leading to these 403 responses.
Timeline of events
In the early afternoon of 23 June 2026, monitoring alerts indicated that the main platform and associated access points were unavailable.
The technical teams carried out initial checks and restarted the affected application components, notably the web services and certain front-end servers.
A high-priority ticket was raised with our infrastructure provider to analyse the behaviour of the load balancer and associated network components.
Investigations then focused on the status of the load balancer’s HTTPS pools, the network infrastructure components, the front-end servers and the application logs.
At the end of the day, a crisis task force was set up with the infrastructure provider to speed up the analysis. Cross-checks revealed that availability check requests were receiving HTTP 403 responses, which prevented the load balancer from recognising the front-end servers as available.
A temporary fix was applied to the load balancer’s configuration to restore the service.
Once service had been restored, the technical teams continued their analysis and confirmed that an internal address used for availability checks had been blocked. The block was lifted, the expected responses returned to normal, and the temporary fix was then removed.
Challenges encountered
Identifying the cause was made difficult by the fact that several technical layers could have been involved: application servers, web configuration, load balancer, network components and hosting infrastructure.
The initial symptoms suggested a malfunction in the load balancer or the network layer, as the front-end servers were considered unavailable whilst some application services continued to respond locally.
The link between the blocking of an internal address and the incident was only established at a late stage, after cross-referencing application logs and checks carried out during the crisis response.
The analysis also required the involvement of several levels of support from the infrastructure provider, which prolonged the diagnosis time.
Cause of the incident
The cause of the incident was the blocking of an internal address used by the load balancer’s availability monitoring mechanism.
As a result of this blocking, monitoring requests sent to the front-end servers received HTTP 403 responses instead of the expected responses. The load balancer then deemed the front-end servers to be unavailable and ceased to distribute traffic correctly to the application services.
This situation resulted in the platform being unavailable to users.
Data loss
No data loss was observed.
The incident affected access to the service but did not affect the integrity of the stored data.
Remedial measures
The technical teams unblocked the internal address used by the availability checks.
The technical teams verified that the front-end servers and the load balancer had returned to normal operation.
The technical teams removed the temporary measure applied during the incident once the cause had been rectified.
The technical teams will strengthen the monitoring of availability checks in order to detect more quickly instances where a component is deemed unavailable due to an application or network rejection.
The technical teams will review the internal filtering rules in order to better identify the technical addresses necessary for the infrastructure to function correctly.
The technical teams will document the dependencies between availability checks, front-end servers and internal security rules in greater detail, in order to reduce the time taken to diagnose a similar incident.
The technical teams will improve escalation and diagnostic procedures with the infrastructure provider in order to speed up analysis when several technical layers are likely to be involved.
Resolved: 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.
Investigating: We are continuing to investigate this issue.
Investigating: We are currently investigating this issue.
Recently Resolved Incidents
No recent incidents
Whaller Outage Survival Guide
Whaller Components
Whaller Main application
We are currently investigating this issue.
Postmortem: # 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.
Post-mortem — Production incident of 23 June 2026
Summary
On 23 June 2026, a production incident rendered the main platform and associated access points unavailable to users.
The incident was detected following monitoring alerts indicating that services were unavailable. The technical teams immediately began initial diagnostic checks and restarted the affected application and infrastructure components.
Analysis revealed that the load balancer’s availability check mechanism was no longer able to correctly validate the application front-ends. These were responding to check requests with an HTTP 403 code, which caused them to be treated as unavailable, resulting in the service interruption.
The service was restored following a temporary adjustment to the infrastructure-side validation, followed by the correction of the cause leading to these 403 responses.
Timeline of events
In the early afternoon of 23 June 2026, monitoring alerts indicated that the main platform and associated access points were unavailable.
The technical teams carried out initial checks and restarted the affected application components, notably the web services and certain front-end servers.
A high-priority ticket was raised with our infrastructure provider to analyse the behaviour of the load balancer and associated network components.
Investigations then focused on the status of the load balancer’s HTTPS pools, the network infrastructure components, the front-end servers and the application logs.
At the end of the day, a crisis task force was set up with the infrastructure provider to speed up the analysis. Cross-checks revealed that availability check requests were receiving HTTP 403 responses, which prevented the load balancer from recognising the front-end servers as available.
A temporary fix was applied to the load balancer’s configuration to restore the service.
Once service had been restored, the technical teams continued their analysis and confirmed that an internal address used for availability checks had been blocked. The block was lifted, the expected responses returned to normal, and the temporary fix was then removed.
Challenges encountered
Identifying the cause was made difficult by the fact that several technical layers could have been involved: application servers, web configuration, load balancer, network components and hosting infrastructure.
The initial symptoms suggested a malfunction in the load balancer or the network layer, as the front-end servers were considered unavailable whilst some application services continued to respond locally.
The link between the blocking of an internal address and the incident was only established at a late stage, after cross-referencing application logs and checks carried out during the crisis response.
The analysis also required the involvement of several levels of support from the infrastructure provider, which prolonged the diagnosis time.
Cause of the incident
The cause of the incident was the blocking of an internal address used by the load balancer’s availability monitoring mechanism.
As a result of this blocking, monitoring requests sent to the front-end servers received HTTP 403 responses instead of the expected responses. The load balancer then deemed the front-end servers to be unavailable and ceased to distribute traffic correctly to the application services.
This situation resulted in the platform being unavailable to users.
Data loss
No data loss was observed.
The incident affected access to the service but did not affect the integrity of the stored data.
Remedial measures
The technical teams unblocked the internal address used by the availability checks.
The technical teams verified that the front-end servers and the load balancer had returned to normal operation.
The technical teams removed the temporary measure applied during the incident once the cause had been rectified.
The technical teams will strengthen the monitoring of availability checks in order to detect more quickly instances where a component is deemed unavailable due to an application or network rejection.
The technical teams will review the internal filtering rules in order to better identify the technical addresses necessary for the infrastructure to function correctly.
The technical teams will document the dependencies between availability checks, front-end servers and internal security rules in greater detail, in order to reduce the time taken to diagnose a similar incident.
The technical teams will improve escalation and diagnostic procedures with the infrastructure provider in order to speed up analysis when several technical layers are likely to be involved.
Resolved: 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.
Investigating: We are continuing to investigate this issue.
Investigating: We are currently investigating this issue.