Title: Service Disruption 26th February 2026

Start of Service Disruption:   11:35 CEST

End of Service Disruption:     15:21 CEST

1.     Incident Details

At approximately 12:15 CET a maintenance operation was performed on a database server within the eSIMsmart core network.

The maintenance operation accidentally locked the database that grants octets to subscribers requesting data services. The CCA application continued attempting to write to the locked database, which used up all the CPU threads and caused the database cluster to become unresponsive.

This caused a significant number of devices to lose data allowance – the resulting experience being that customers devices appeared no longer connected to the internet.

During this period provisioning via APIs was also affected.

Engineers were engaged immediately and were able un-lock the database and clear down the CPU threads waiting to write to the database.

Once the database was responsive again, this left some subscribers connected to the PGWs in a “blocked” state, so a process was initiated to refresh those subscribers so they were granted the octets again and data service access was restored to all subscribers by 15:21 CET.

‌

1.1.Post Incident review

The maintenance operation was not properly planned, as to assess the impact by the engineering team. As a result unintended behaviour occurred as a consequence.

Proper planning would have meant the operation would have not been attempted during working hours, and also should not have been so impactful.

‌

1.1.Mitigating Actions

• There was already a project on going to move away from the CCA application to   a more modern OCS application (OCS was not impacted during this period) – this will now be expedited to reduce the risk of any re-occurrence.
• Add support in PGW configuration to be able to assume “positive” answer from OCS when received error from OCS. This can mitigate service disruption when OCS is un-reachable.
• Process improvement including additional peer checks for maintenance operations.

‌

Titre: Interruption du service : 26 février 2026

Début de la perturbation du service : 11:35 CEST

Interruption de fin de service :          15:21 CEST

‌

1.                 Détails de l'incident

Vers 12h15 CET, une opération de maintenance a été effectuée sur un serveur de base de données au sein du réseau central eSIMsmart.

L'opération de maintenance a accidentellement verrouillé la base de données qui accorde des octets aux abonnés demandant des services de données. L'application CCA continuait d'essayer d'écrire dans la base de données verrouillée, ce qui consommait tous les threads du processeur et rendait le cluster de base de données non réactif.

Cela a entraîné la perte de données d'un nombre important d'appareils – l'expérience résultant étant que les appareils des clients semblaient ne plus être connectés à Internet.

Durant cette période, le provisionnement via les API a également été affecté.

Les ingénieurs ont été immédiatement engagés et ont pu déverrouiller la base de données et vider les threads CPU en attente d'écriture dans la base de données.

Une fois la base de données réactive, certains abonnés connectés aux PGW étaient dans un état « bloqué », un processus a été lancé pour rafraîchir ces abonnés afin qu'ils obtiennent à nouveau les octets et l'accès aux services de données soit rétabli à tous les abonnés à 15h21 CET.

‌

1.1.    Revue post-incident

L'opération de maintenance n'a pas été correctement planifiée, afin d'évaluer l'impact par l'équipe d'ingénierie. En conséquence, un comportement non intentionnel s'est produit.

Une planification adéquate aurait signifié que l'opération n'aurait pas été tentée pendant les heures de travail, et n'aurait pas dû avoir autant d'impact.

1.1.1    Mesures d'atténuation

• Il y avait déjà un projet visant à passer de l'application CCA à une application OCS plus moderne (l'OCS n'a pas été affecté durant cette période) – cela sera désormais accéléré pour réduire le risque de récidive.
• Ajouter un support en configuration PGW pour pouvoir supposer une réponse « positive » d'OCS lors d'une erreur reçue d'OCS. Cela peut atténuer les perturbations du service lorsque l'OCS est injoignable.
• Amélioration des processus, incluant des vérifications supplémentaires par les pairs pour les opérations de maintenance.