Français

postmortem

Postmortem : panne du service d'authentification Logto

Le 12 juin 2025, les services Logto sur `logto.app` ont été brièvement perturbés par une panne de Cloudflare affectant le routage des requêtes. Le problème a été rapidement résolu, sans impact sur la sécurité des données ni sur les services principaux.

Gao

Founder

6/13/2025

Arrêtez de perdre des semaines sur l'authentification des utilisateurs

Lancez des applications sécurisées plus rapidement avec Logto. Intégrez l'authentification des utilisateurs en quelques minutes et concentrez-vous sur votre produit principal.

Commencer

Résumé de l'incident

Entre 18:07 et 18:58 UTC le 12 juin 2025, les utilisateurs accédant aux services Logto via le domaine logto.app (y compris les domaines personnalisés) ont rencontré des erreurs. La perturbation était due à une panne de Cloudflare Workers KV, qui a impacté notre couche de routage. Les services Logto Cloud et la console Logto, qui utilisent une résolution DNS directe et ne dépendent pas des Cloudflare Workers, n'ont pas été affectés. Le service a été restauré en moins d'une heure, sans impact sur la sécurité des données.

Chronologie (UTC)

18:07 : Les API du service d'authentification Logto ont commencé à renvoyer des erreurs 500 pour les requêtes via logto.app.
18:24 : L'enquête a confirmé que le backend Azure était sain et que le problème était isolé aux Cloudflare Workers et KV.
18:48 : Cloudflare a officiellement reconnu un incident affectant Workers et KV.
18:58 : Nous avons déployé une solution temporaire en supprimant la logique de mise en cache, ce qui a permis de rétablir le service avec une possible légère dégradation des performances.
21:00 : Après la stabilisation des services Cloudflare, nous avons redéployé la logique de cache avec un repli gracieux. Les performances complètes ont été restaurées et le service est désormais résilient face à des pannes KV similaires.

Cause racine

Cet incident a été déclenché par une indisponibilité du Cloudflare Workers KV. Notre Cloudflare Worker achemine les requêtes vers la bonne région Logto pour chaque locataire ou domaine afin d'assurer la résidence et la conformité des données. Pour améliorer les performances, le Worker utilise KV pour mettre en cache ces correspondances de région. Lorsque KV est devenu indisponible, les opérations de cache ont échoué et le Worker a généré des erreurs au lieu d'adopter un comportement sans cache, entraînant une interruption du service.

Les services Logto Cloud et la console Logto n'ont pas été affectés car ils reposent sur une résolution DNS directe et n'utilisent pas les Cloudflare Workers pour le routage.

Résolution et améliorations

Suppression de la dépendance à la mise en cache du Worker, ce qui a rétabli le service.
Après la reprise du service KV de Cloudflare, redéploiement de la logique de cache avec un repli gracieux. Si le cache est indisponible, le service continue en utilisant le routage direct sans interruption.
Améliorations continues de l'infrastructure pour augmenter encore la résilience et la disponibilité.

Impact

Les utilisateurs accédant à Logto via logto.app ont rencontré des erreurs pendant environ 50 minutes.
Aucune donnée client n'a été perdue ou compromise.
Les services Logto Cloud et la console Logto sont restés pleinement opérationnels.

Prochaines étapes

Nous allons revoir et améliorer la gestion des erreurs dans notre infrastructure en périphérie.
Nous allons envisager l'utilisation de plusieurs fournisseurs pour l'infrastructure en amont afin d'éviter les points de défaillance uniques.

Merci pour votre patience et votre soutien.

Résumé de l'incident

Chronologie (UTC)

18:07 : Les API du service d'authentification Logto ont commencé à renvoyer des erreurs 500 pour les requêtes via logto.app.

18:24 : L'enquête a confirmé que le backend Azure était sain et que le problème était isolé aux Cloudflare Workers et KV.

18:48 : Cloudflare a officiellement reconnu un incident affectant Workers et KV.

18:58 : Nous avons déployé une solution temporaire en supprimant la logique de mise en cache, ce qui a permis de rétablir le service avec une possible légère dégradation des performances.

21:00 : Après la stabilisation des services Cloudflare, nous avons redéployé la logique de cache avec un repli gracieux. Les performances complètes ont été restaurées et le service est désormais résilient face à des pannes KV similaires.

Cause racine

Les services Logto Cloud et la console Logto n'ont pas été affectés car ils reposent sur une résolution DNS directe et n'utilisent pas les Cloudflare Workers pour le routage.

Résolution et améliorations

Suppression de la dépendance à la mise en cache du Worker, ce qui a rétabli le service.

Après la reprise du service KV de Cloudflare, redéploiement de la logique de cache avec un repli gracieux. Si le cache est indisponible, le service continue en utilisant le routage direct sans interruption.

Améliorations continues de l'infrastructure pour augmenter encore la résilience et la disponibilité.

Résumé de l'incident#

Chronologie (UTC)#

Cause racine#

Résolution et améliorations#

Impact#

Prochaines étapes#

Résumé de l'incident#

Chronologie (UTC)#

Cause racine#

Résolution et améliorations#

Impact#

Prochaines étapes#

Résumé de l'incident

Chronologie (UTC)

Cause racine

Résolution et améliorations

Impact

Prochaines étapes

Résumé de l'incident

Chronologie (UTC)

Cause racine

Résolution et améliorations

Impact

Prochaines étapes