Historique des pannes de Gatewayapi

1. 25 octobre 2026 à 09:42 UTCmonitoring

   Nous sommes actuellement confrontés à des problèmes vers Telia Suède. Les rapports d'exécution peuvent être retardés. Le trafic sera surveillé de près alors que nous nous attendons à une mise à jour et que le service fonctionnera comme prévu.

2. 25 octobre 2026 à 13:01 UTCresolved

   La question de Telia Suède a été résolue. Les rapports de livraison (DLR) sont retournés comme prévu. Tout DLR retardé de la période de l'incident aurait dû être livré. Si vous voyez encore des DLR manquants ou retardés pour Telia Suède, veuillez contacter notre équipe de support.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 22 octobre 2026 à 14:24 UTCidentified

   Nous sommes actuellement en retard dans les rapports de livraison (DLR) pour les messages envoyés à TDC Danemark. La livraison des messages n'est pas affectée. Tous les messages sont livrés aux destinataires comme d'habitude, mais les rapports de livraison correspondants peuvent arriver plus tard que d'habitude. Nous travaillons avec TDC pour résoudre le problème et publierons une mise à jour dès que nous en saurons plus.

2. 22 octobre 2026 à 14:42 UTCresolved

   Cette question a été résolue. Les rapports de livraison (DLR) pour les messages envoyés à TDC Danemark sont à nouveau livrés comme d'habitude. Tous les messages ont été envoyés aux destinataires tout au long de l'incident. Seuls les rapports de livraison et les messages d'invitation ont été retardés. Merci de votre patience.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 20 octobre 2026 à 08:45 UTCidentified

   Nous sommes actuellement en retard dans les rapports de livraison (DLR) pour les messages envoyés à TDC Danemark. La livraison des messages n'est pas affectée. Tous les messages sont livrés aux destinataires comme d'habitude, mais les rapports de livraison correspondants peuvent arriver plus tard que d'habitude. Nous travaillons avec TDC pour résoudre le problème et publierons une mise à jour dès que nous en saurons plus.

2. 20 octobre 2026 à 10:15 UTCresolved

   Cette question a été résolue. Les rapports de livraison (DLR) pour les messages envoyés à TDC Danemark sont à nouveau livrés comme d'habitude. Tous les messages ont été envoyés aux destinataires tout au long de l'incident. Seuls les rapports de livraison et les messages d'invitation ont été retardés. Merci de votre patience.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 9 octobre 2026 à 14:06 UTCmonitoring

   Nous surveillons actuellement les retards dans l'exécution du rapport à l'égard de ICE Norway. Les utilisateurs peuvent connaître un retard dans la réception des rapports de livraison. Le trafic MT n'est pas affecté. Nous vous tiendrons au courant.

2. 9 octobre 2026 à 15:22 UTCresolved

   Les rapports de livraison sont de retour à la normale vers ICE Norvège. Nous continuerons de surveiller pour une bonne mesure.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 8 octobre 2026 à 09:12 UTCidentified

   Nous avons actuellement des problèmes avec Tele2 Suède. Le trafic sera surveillé de près alors que nous nous attendons à une mise à jour et que le service fonctionnera comme prévu. Merci de votre compréhension et nous nous excusons pour les inconvénients causés par cela.

2. 8 octobre 2026 à 10:06 UTCresolved

   Trafic vers Tele2 La Suède est maintenant de retour à la normale. Nous continuerons de surveiller pour une bonne mesure. Merci de votre compréhension et nous nous excusons pour les inconvénients causés par cela.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 29 septembre 2026 à 20:08 UTCinvestigating

   Nous rencontrons des problèmes avec GatewayAPI.EU et nous enquêtons actuellement sur la cause profonde. Nous travaillons actuellement à résoudre ce problème. La configuration .COM fonctionne toujours comme prévu. Nous vous tiendrons au courant.

2. 29 septembre 2026 à 20:27 UTCresolved

   Nous voyons les services sur GatewayAPI. L'UE est de nouveau pleinement opérationnelle. Le trafic et les services seront surveillés pour une bonne mesure. Merci de votre patience et nous nous excusons pour les désagréments causés par cela.

3. 30 septembre 2026 à 19:12 UTCpostmortem

   **Résumé: Traitement différé des messages le** [**GatewayAPI.eu**](http://GatewayAPI.eu) **- 29 septembre 2026** Le 29 septembre 2026, entre 18:24 et 20:05 UTC \(20:24–22:05 CEST\), [GatewayAPI.eu](http://GatewayAPI.eu) a connu un retard de 101 minutes dans le traitement des messages. Notre plateforme [GatewayAPI.com](http://GatewayAPI.com) n'a pas été affectée. Toutes les API entrantes, y compris l'API de messagerie mobile, l'API REST et SMPP, sont restées disponibles tout au long de l'incident et ont continué à accepter les messages. Cependant, les messages acceptés étaient en attente plutôt que traités et envoyés. Les rapports de livraison \(DLR\) ont été retardés pour la même raison. **Aucun message n'a été perdu.** Une fois le traitement rétabli, tous les messages en attente ont été livrés, avec des retards allant jusqu'à 101 minutes. Les clients n'ont pas besoin de renvoyer les messages soumis pendant cette période. Nous avons détecté quelques messages qui ont été livrés deux fois - cela ne comptera qu'une fois sur l'utilisation facturée. **Ce qui s'est passé** Une quantité exceptionnellement importante de messages a été reçue et transmise au service interne chargé du traitement des messages sortants. Le traitement de ce volume a nécessité plus de mémoire que le service n'a été autorisé à utiliser, de sorte que la plate-forme l'a automatiquement arrêté. Lorsque le service a redémarré, il a récupéré le même arriéré important et a été arrêté à nouveau. Ceci répété dans une boucle, et pendant ce temps aucun message ne pouvait être traité. ** Cause de la mort** La mémoire allouée à notre service de traitement de messages n'a pas été dimensionnée pour traiter une charge globale de cette ampleur. En conséquence, une seule grande explosion de trafic était suffisante pour mettre le service dans une boucle de redémarrage au lieu d'être traité progressivement. **Détection** Nous n'avions pas d'alerte automatique en place sur [GatewayAPI.eu](http://GatewayAPI.eu) pour ce scénario spécifique, où nos API continuent d'accepter les messages pendant que le traitement s'arrête. Pour cette raison, l'incident n'a pas été détecté par notre surveillance, et il nous a fallu plus de temps qu'il n'aurait fallu pour réagir. Nous prenons l'entière responsabilité de cette lacune. **Résolution** Nos ingénieurs ont identifié la boucle de redémarrage, augmenté la mémoire disponible pour le service de traitement de messages, et l'ont ramené en ligne. Le service a ensuite réglé l'arriéré en attente, et tous les messages en attente et les rapports de livraison ont été traités. **Ce que nous faisons pour éviter que cela ne se reproduise** * ** Surveillance améliorée :** Nous avons ajouté une alerte à [GatewayAPI.eu](http://GatewayAPI.eu) qui déclenche lorsque le trafic traité diminue de façon inattendue. * ** Capacité accrue :** Le service de traitement de messages a maintenant une allocation de mémoire plus élevée, ce qui réduit le risque qu'il soit arrêté sous de grandes charges. * ** Amélioration de la gestion de la charge \(en cours\):** Nous travaillons déjà sur des améliorations à notre file d'attente de message interne, qui permettra à la plate-forme d'absorber des pics similaires avec plus de grâce à l'avenir. Nous savons combien la livraison en temps opportun est importante pour votre entreprise, et nous nous excusons pour le retard causé. Si vous avez des questions sur l'incidence de cet incident sur votre compte, veuillez contacter notre équipe de soutien.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 23 septembre 2026 à 03:56 UTCinvestigating

   Nous connaissons actuellement des problèmes de trafic MT sur notre API REST. C'est seulement sur notre COM-setup. Nous travaillons actuellement à identifier la cause profonde et à résoudre le problème. Nous vous tiendrons au courant.

2. 23 septembre 2026 à 04:27 UTCresolved

   Cet incident a été résolu. Le trafic MT sur notre API REST (com-setup) fonctionne comme prévu. Merci de votre patience.

3. 23 septembre 2026 à 13:38 UTCpostmortem

   **Résumé: Perturbation des messages sortants sur** [**GatewayAPI.com**](http://GatewayAPI.com) **- 23 septembre 2026** Le 23 septembre 2026, entre 03:38 et 04:20 UTC \(05:38–06:20 CEST\), [GatewayAPI.com](http://GatewayAPI.com) a connu une perturbation de 42 minutes dans le traitement des messages. Toutes les API de service public ont été touchées, y compris l'API de messagerie mobile et l'API REST. Notre mise à jour initiale du statut ne faisait référence qu'à l'API REST; nous nous excusons de sous-déclaration de la portée. Le tableau de bord client et notre plateforme européenne \([GatewayAPI.eu](http://GatewayAPI.eu)\ n'ont pas été affectés. Les messages soumis pendant l'incident ont été rejetés par l'API et devaient être ressentis. **Ce qui s'est passé** Notre plateforme fonctionne sur un service Kubernetes géré. Lors d'une mise à niveau automatique de routine effectuée par notre fournisseur de cloud, un service interne qui coordonne le traitement des messages n'est pas revenu en ligne. Chaque fois qu'il a commencé, le bilan de santé automatisé de la plate-forme l'a redémarré avant que le démarrage ne soit terminé, le laissant dans une boucle de redémarrage. ** Cause de la mort** Kubernetes contrôles de santé \("sondes"\) redémarrer un service si un contrôle dépasse sa limite de temps configurée. Dans les versions précédentes, cette limite n'a pas été strictement appliquée pour notre type de contrôle de santé, qui a caché le fait que notre limite était plus courte que les besoins de service pendant le démarrage. Notre fournisseur de cloud avait annoncé ce changement et mis en pause les mises à niveau automatiques pour les grappes qu'il a identifiées comme affectées, mais notre grappe n'a pas été identifiée, donc la mise à niveau a commencé. Nous assumons l'entière responsabilité de la configuration de nos services. **Résolution** Nos ingénieurs ont analysé les exigences de démarrage du service touché et augmenté le délai de contrôle sanitaire avec un tampon sûr. Le service a alors commencé normalement, et le traitement des messages a repris. (en milliers de dollars) Nous savons à quel point la messagerie fiable est importante pour votre entreprise et nous vous excusons pour la perturbation. Si vous avez des questions sur l'incidence de cet incident sur votre compte, veuillez contacter notre équipe de soutien.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 2 septembre 2026 à 19:59 UTCidentified

   Nous sommes actuellement en retard vers Tele2 Suède. Le trafic sera surveillé de près alors que nous nous attendons à une mise à jour et que le service fonctionnera comme prévu. Merci de votre compréhension et nous nous excusons pour les inconvénients causés par cela.

2. 2 septembre 2026 à 20:06 UTCresolved

   Trafic vers Tele2 La Suède est maintenant de retour à la normale. Nous continuerons de surveiller pour une bonne mesure. Merci de votre compréhension et nous nous excusons pour les inconvénients causés par cela.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 24 août 2026 à 09:01 UTCidentified

   Nous surveillons actuellement les délais de publication des rapports sur notre plateforme européenne. Les utilisateurs peuvent connaître un retard dans la réception des rapports de livraison. Le trafic MT n'est pas affecté. Nous vous tiendrons au courant.

2. 24 août 2026 à 13:48 UTCresolved

   Les retards dans l'exécution de notre plate-forme européenne ont été résolus. Tous les rapports de retard de livraison ont été traités et sont livrés normalement. Le trafic MT n'a été affecté à aucun moment pendant l'incident. Nous nous excusons pour tout désagrément causé. Si vous constatez toujours que les rapports de livraison sont manquants ou retardés, veuillez contacter notre équipe de soutien.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 19 août 2026 à 19:40 UTCidentified

   Nous sommes actuellement en retard vers T-Mobile Allemagne. Le trafic sera surveillé de près alors que nous nous attendons à une mise à jour et que le service fonctionnera comme prévu. Merci de votre compréhension et nous nous excusons pour les inconvénients causés par cela.

2. 19 août 2026 à 20:09 UTCresolved

   Le trafic vers T-Mobile Allemagne est maintenant de retour à la normale. Nous continuerons de surveiller pour une bonne mesure. Merci de votre compréhension et nous nous excusons pour les inconvénients causés par cela.

Traduit automatiquement depuis la mise à jour officielle de l'incident.

1. 10 juillet 2026 à 18:12 UTCidentified

   We are currently experiencing issues with delays towards Swisscom & Sunrise in Switzerland. The traffic will be closely monitored whilst we expect an update and for the service to be functioning as intended again. Thank you for your understanding and we apologize for the inconvenience caused by this.

2. 10 juillet 2026 à 22:08 UTCresolved

   Traffic is now back to normal towards Swisscom & Sunrise in Switzerland. We will continue to monitor for good measure. Thank you for your understanding and we apologize for the inconvenience caused by this.

1. 2 juillet 2026 à 07:36 UTCidentified

   We are currently seeing a lot of rejected and enroute with the SMS service of TDC Denmark. The traffic will be closely monitored whilst we expect an update. Thank you for your understanding and we apologize for the inconvenience caused by this.

2. 2 juillet 2026 à 07:49 UTCmonitoring

   Traffic to TDC Denmark has recovered and rejected and enroute rates are back to normal. We are monitoring closely to confirm stability. Thank you for your patience, and we apologise for the inconvenience.

3. 2 juillet 2026 à 08:35 UTCresolved

   The traffic towards TDC Denmark/Nuuday is fully operational. We will continue to monitor the traffic for good measure. Thank you for your understanding and we apologize for the inconvenience caused by this.

1. 19 juin 2026 à 15:22 UTCmonitoring

   We are currently monitoring the Delivery Report issue reported by Telia Norway. Users may experience a delay receiving delivery reports on messages sent to Telia Norway recipients. Messages are delivered, it is only the status reports that are delayed.

2. 19 juin 2026 à 16:48 UTCresolved

   Delivery reports towards Telia Norway is now back to normal. We will keep monitoring for good measure. We are sorry for any inconveniences this may have caused.

1. 14 juin 2026 à 10:41 UTCidentified

   We are seeing an unscheduled issue towards the GatewayAPI EU Dashboard and are working on resolving it. You may experience issues when trying to access the dashboard. We will keep you updated.

2. 14 juin 2026 à 11:05 UTCidentified

   We are continuing to work on the issue with GatewayAPI EU Dashboard. You may currently experience delays in both MT and MO traffic. We will keep you updated and we apologize for the inconvenience caused by this.

3. 14 juin 2026 à 11:14 UTCresolved

   The GatewayAPI EU Dashboard is up and running again. MT and MO traffic is back to normal. A Postmortem will follow. We will continue to monitor for good measure and we apologize for the inconvenience caused by this.

4. 15 juin 2026 à 10:33 UTCpostmortem

   ## **GatewayAPI Incident Post-Mortem: Service Disruption on June 14, 2026** ‌ **Date of Incident:** June 14, 2026 **Duration:** 12:33 CEST – 13:05 CEST \(32 minutes\) **Services Impacted:** GatewayAPI EU SMS APIs & Customer Dashboard ‌ ### **Executive Summary** On June 14, 2026, between 12:33 CEST and 13:05 CEST, GatewayAPI experienced a service disruption that temporarily impacted our EU SMS APIs and the Customer Dashboard. The core issue originated from a localized network and infrastructure outage at our cloud provider, which unexpectedly isolated our main database cluster. While our core SMS services are architected to operate independently during database anomalies, the specific nature of this infrastructure failure triggered an unforeseen dependency that halted message-traffic processing. Our team intervened immediately, and services were fully restored within 32 minutes. ‌ ### **Root Cause Analysis** The disruption was initiated by a hardware and network-level incident within our cloud provider's infrastructure. This failure caused our primary database cluster to become unavailable. Although our message and SMS routing engine is designed with fail-safes to bypass database dependencies during outages, the unique state of this infrastructure failure prevented the seamless decoupling of these systems. This caused a temporary backlog, rendering both the Customer Dashboard and the EU SMS APIs unavailable during the affected window. ‌ ### **Actions Taken & Preventive Measures** We take platform reliability incredibly seriously and have already implemented several immediate improvements to ensure this specific scenario cannot happen again: * **Decoupling & Robustness Enhancements:** We have updated the message API and application routing mechanisms to ensure absolute independence from the primary database. In the event of a future database failure, core message and SMS routing will automatically fail back to decentralized, local mechanisms without interruption. * **Optimized Failover Routines:** We will refine and streamline our automated failover procedures to reduce the time it takes for secondary systems to assume control during infrastructure anomalies. * **Enhanced Monitoring & Alerting:** We will deploy additional high-fidelity alarms and alerting thresholds. This will grant our engineering team earlier visibility into underlying cloud provider infrastructure shifts before they impact user-facing services. ‌ **Our Commitment to You** We sincerely apologize for the disruption this caused to your operations. We are fully committed to providing a highly resilient business messaging platform, and we are using the insights gained from this incident to continuously harden our infrastructure. ‌ If you have any remaining questions regarding this incident, please feel free to reach out to our support team.

1. 29 mai 2026 à 12:21 UTCidentified

   We are currently experiencing issues with Delays towards Finland. The traffic will be closely monitored whilst we expect an update and for the service to be functioning as intended again. Thank you for your understanding and we apologize for the inconvenience caused by this.

2. 29 mai 2026 à 15:26 UTCresolved

   The traffic towards Finland is back to normal. We will keep monitoring for good measure. Thanks for your patience and sorry for any inconveniences this may have caused.

1. 26 mai 2026 à 04:59 UTCinvestigating

   We are experiencing issues with GatewayAPI.EU and are now investigating the root cause. All systems on GatewayAPI.EU are offline for the time being and we encourage you to stop all traffic on gatewayapi.eu until further notice. We are currently working on resolving the issue. The .COM setup is still working as intended. We will keep you updated.

2. 26 mai 2026 à 05:33 UTCresolved

   All systems are now back online for Gatewayapi.EU. We will keep monitoring for good measure. Thanks for your patience and understanding, we are sorry for any inconvenience this may have caused.

1. 19 mai 2026 à 06:30 UTCidentified

   We are currently experiencing issues with delays towards Hi3G Denmark. The traffic will be closely monitored whilst we expect an update and for the service to be functioning as intended again. Thank you for your understanding and we apologize for the inconvenience caused by this.

2. 19 mai 2026 à 09:33 UTCmonitoring

   The traffic towards Hi3G Denmark looks to be fully operational once again. We will continue to monitor the traffic for good measure. Thank you for your understanding and we apologize for the inconvenience caused by this.

3. 19 mai 2026 à 10:25 UTCresolved

   The traffic towards Hi3G Denmark looks stable. This incident has been resolved. Thank you for your understanding and we apologize for the inconvenience caused by this.

1. 15 mai 2026 à 15:09 UTCidentified

   We are currently experiencing issues towards Italy. The traffic will be closely monitored whilst we expect an update and for the service to be functioning as intended again. Thank you for your understanding and we apologize for the inconvenience caused by this.

2. 15 mai 2026 à 16:25 UTCresolved

   The traffic towards Italy is back to normal. We will keep monitoring for good measure. Thanks for your patience and sorry for any inconveniences this may have caused.

1. 8 mai 2026 à 08:17 UTCidentified

   We are currently experiencing issues with Delayed delivery reports towards ICE Norway. The traffic is being delivered at Normal rate. We will be closely monitored whilst we expect an update and for the service to be functioning as intended again. Thank you for your understanding and we apologize for the inconvenience caused by this.

2. 8 mai 2026 à 10:19 UTCresolved

   The traffic towards ICE Norway looks to be fully operational once again. We will continue to monitor the traffic for good measure. Thank you for your understanding and we apologize for the inconvenience caused by this.

1. 6 mai 2026 à 03:31 UTCinvestigating

   We are currently seeing some issues with the Traffic log. Users may experience issues when trying to access the Traffic log. We are currently working on resolving the issue. All traffic is still being delivered accordingly. We will keep you updated.

2. 6 mai 2026 à 04:40 UTCresolved

   The issue affecting the Traffic log has been resolved. Users should now be able to access the Traffic log again. Traffic delivery was unaffected throughout this incident.