Historique des pannes de Cycode

1. 27 octobre 2026 à 10:06 UTCinvestigating

   ** Résumé** Certaines intégrations de Bitbucket Cloud qui utilisent OAuth déconnecté après que le service d'authentification de BitbucketS a retourné des erreurs le 27 octobre 2026, à 03:45 UTC. **Impact** Pour les intégrations affectées, Cycode ne peut pas accéder à Bitbucket. Scans, synchronisations de dépôt et états de validation pour ces espaces de travail s'arrêtent jusqu'à ce que l'intégration soit à nouveau autorisée. Les intégrations qui utilisent des mots de passe app, des jetons API ou des jetons d'accès à l'espace de travail ne sont pas affectées. ** Dernière mise à jour** Notre enquête montre que Bitbucket a émis de nouvelles identifiants pour ces intégrations mais ne les a pas livrés à Cycode, parce que son service a retourné une erreur. Bitbucket n'accepte plus les identifiants précédents, de sorte que les intégrations ne peuvent pas récupérer automatiquement. Nous signalons le problème à Atlassian. ** Mesures à prendre** Si votre intégration Bitbucket s'affiche comme déconnectée, autorisez-le à nouveau dans la console Cycode sous [Paramètres > Intégrations > Bitbucket]. Cycode continue d'où il s'est arrêté, et aucun autre changement n'est nécessaire. Nous publierons une mise à jour lorsque nous aurons plus d'informations.

2. 27 octobre 2026 à 10:46 UTCmonitoring

   Nous avons identifié chaque intégration affectée et nous contactons maintenant directement leurs utilisateurs. Une intégration commence à fonctionner à nouveau dès que son utilisateur l'autorise à nouveau dans la console Cycode sous [Paramètres > Intégrations > Bitbucket]. Nous avons signalé l'erreur Bitbucket à Atlassian et afficherons une mise à jour lorsque nous aurons plus d'informations.

3. 27 octobre 2026 à 12:51 UTCresolved

   Toutes les intégrations Bitbucket Cloud touchées ont été identifiées, et leurs utilisateurs ont reçu des instructions pour les autoriser à nouveau. Les intégrations autorisées à nouveau fonctionnent normalement. La cause principale était une erreur de service Bitbucket le 27 octobre 2026, à 03:45 UTC, qui a invalidé les identifiants de certaines intégrations. Nous avons communiqué les détails à Atlassian pour leur enquête.

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

1. 20 octobre 2026 à 09:28 UTCinvestigating

   Nous avons identifié une cause potentielle des problèmes de flux de connexion et nous enquêtons davantage.

2. 20 octobre 2026 à 09:54 UTCinvestigating

   Nous avons résolu le problème du flux de connexion dans la région de l'UE.

3. 20 octobre 2026 à 10:04 UTCmonitoring

   La question a été résolue et nous continuons de surveiller le système pour assurer la stabilité.

4. 20 octobre 2026 à 15:43 UTCresolved

   L'incident a été entièrement résolu et nous ne voyons pas d'autres problèmes.

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

1. 18 octobre 2026 à 13:10 UTCinvestigating

   Nous enquêtons sur des erreurs dans l'application liées à la numérisation des PR et aux défaillances de charge de violation. Nous publierons d'autres mises à jour une fois que nous aurons trouvé la cause.

2. 18 octobre 2026 à 13:26 UTCidentified

   Nous avons eu un problème avec une de nos bases de données d'applications. La base de données est de retour à des opérations normales, mais elle est encore dégradée, et nous travaillons activement à la corriger. La plate-forme est de retour à des opérations normales, et les violations et les analyses des relations publiques devraient fonctionner normalement.

3. 18 octobre 2026 à 13:34 UTCmonitoring

   La base de données est de retour aux opérations normales. Nous veillons activement à ce qu'il n'y ait plus de problèmes.

4. 18 octobre 2026 à 14:40 UTCresolved

   L'incident a été entièrement résolu et nous ne voyons pas d'autres problèmes.

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

1. 13 octobre 2026 à 12:56 UTCmonitoring

   **Surveillance**: analyse de l'API (région américaine) Plus tôt aujourd'hui, notre système d'alerte a détecté que le service derrière l'API scans redémarrait plus souvent que prévu, ce qui a causé l'échec de certaines demandes pendant une courte période. Nous avons augmenté la mémoire disponible au service, et elle est stable depuis. Nous gardons le service sous surveillance étroite pendant que nous parvenons à une amélioration permanente.

2. 13 octobre 2026 à 13:01 UTCresolved

   **Résolu**: Brève ralentissement de l'API de balayage (région américaine) Le 13 octobre, 2026, entre 07:58 et 08:28 UTC, certaines demandes à l'API des scans dans la région américaine a échoué ou ont été lents. Les pages de numérisation dans l'interface utilisateur Cycode et le CLI Cycode ont peut-être montré des erreurs temporaires, et certaines requêtes de tirage sont arrivées quelques minutes plus tard que d'habitude. Nous avons augmenté la mémoire disponible pour le service, qui a entièrement résolu le problème à 08:34 UTC. Tous les scans en attente ont été effectués peu après, et aucune donnée n'a été perdue. Nous avons déterminé la cause et une amélioration permanente est en cours d'examen.

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

1. 13 octobre 2026 à 08:30 UTCinvestigating

   GitLab connaît actuellement une interruption de service qui peut avoir une incidence sur la connectivité de numérisation et d'intégration de Cycode PR. Le problème provient de l'infrastructure de GitLab et est hors du contrôle de Cycode. Nous surveillons la situation et fournirons des mises à jour au fur et à mesure que GitLab travaille à rétablir un service normal. Pour de plus amples renseignements, veuillez consulter la page d'état de GitLab : [https://status.gitlab.com/pages/incident/5b36dc6502d06804c08349f7/6acdd94de3aa7005ae52c614](https://status.gitlab.com/pages/incident/5b36dc6502d06804c08349f7/6acdd94de3aa7005ae52c614 "https://status.gitlab.com/pages/incident/5b36dc6502d06804c08349f7/6acdd94de3aa7005ae52c614")

2. 13 octobre 2026 à 08:47 UTCmonitoring

   GitLab a déplacé l'incident affectant le balayage des PR et la connectivité d'intégration à la phase de surveillance. GitLab a mis en place un correctif et surveille les résultats. Nous continuons de surveiller l'impact sur les intégrations de Cycode et fournirons d'autres mises à jour au besoin. Pour de plus amples renseignements, veuillez consulter la page d'état de GitLab : [https://status.gitlab.com/pages/incident/5b36dc6502d06804c08349f7/6acdd94de3aa7005ae52c614](https://status.gitlab.com/pages/incident/5b36dc6502d06804c08349f7/6acdd94de3aa7005ae52c614 "https://status.gitlab.com/pages/incident/5b36dc6502d06804c08349f7/6acdd94de3aa7005ae52c614")

3. 13 octobre 2026 à 11:27 UTCresolved

   GitLab a résolu l'incident affectant le balayage des PR et la connectivité d'intégration

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

1. 7 octobre 2026 à 14:22 UTCinvestigating

   L'équipe continue de travailler avec AWS, qui a intensifié la question à l'interne. En parallèle, nous travaillons à restaurer la fonctionnalité en passant à une autre base de données. Toute demande de tirage bloqué en attente de l'état Cycode peut être débloquée en supprimant les scans Cycode des vérifications prévues directement dans votre SCM (Source Code Management). Communiquez avec votre représentant Cycode pour vous aider à rationaliser le processus.

2. 7 octobre 2026 à 14:22 UTCinvestigating

   AWS a confirmé que l'instance de PostgreSQL est actuellement dans un état de récupération interne. La chute attendue de Multi-AZ n'a pas eu lieu comme prévu, et AWS étudie activement pourquoi. Parallèlement, nous poursuivons nos efforts pour restaurer les services touchés en utilisant un autre chemin de base de données pour accélérer la récupération

3. 7 octobre 2026 à 14:22 UTCinvestigating

   Nous voyons la base de données rétablir ses capacités opérationnelles. Nous voyons les premiers scans Pull Request en cours de traitement. Nous surveillons le système et augmentons le débit.

4. 7 octobre 2026 à 14:22 UTCinvestigating

   La base de données reste pleinement opérationnelle. Nous travaillons à accélérer le traitement au-delà des délais réguliers pour traiter tous les arriérés dès que possible.

5. 7 octobre 2026 à 14:22 UTCinvestigating

   Nous continuons d'étudier une dégradation majeure de la plateforme américaine causée par l'épuisement de la connexion PostgreSQLTM. Les clients peuvent connaître des temps de réponse lents, des erreurs élevées de 500 et des flux de travail plus lents et des scans CLI. Nous avons réduit la charge de la base de données sur plusieurs services et nous avons lancé une panne RDS. L'équipe travaille activement pour rétablir des performances normales.

6. 7 octobre 2026 à 14:22 UTCinvestigating

   Nous avons remarqué des performances dégradées chez prod-us Les flux comme la demande de tirage ou la numérisation CLI peuvent être plus lents que d'habitude

7. 7 octobre 2026 à 14:22 UTCinvestigating

   L'équipe travaille activement avec AWS et étudie ce qui semble être un problème de rupture de base de données affectant l'environnement américain. Nous allons partager une autre mise à jour dès que nous avons plus d'informations.

8. 7 octobre 2026 à 14:22 UTCinvestigating

   La plateforme américaine s'améliore à la suite de l'épuisement de la connexion RDS/PostgreSQL. AWS a confirmé que l'instance originale PostgreSQL est revenue à un état opérationnel, et nous voyons les scans PR être traités à nouveau. La principale dégradation restante est le retard dans le traitement sous l'impulsion de GitHub en raison d'un important arriéré de webhook, qui continue de s'épuiser. Nous allons continuer à surveiller la récupération et fournir une autre mise à jour que le traitement retourne à la normale

9. 7 octobre 2026 à 14:22 UTCinvestigating

   Le système est de nouveau pleinement opérationnel

10. 7 octobre 2026 à 14:22 UTCresolved

    (2/2) • Les charges de travail qui créaient des volumes élevés d'opérations de données à courte durée de vie, afin de réduire la charge de travail des bases de données tout en éliminant les événements retardés. • Scanné les demandes de tirage qui ont été manquées pendant l'incident. **4b. Mesures prises** • Modifier la façon dont de grandes séries de données sont écrites pour réduire la charge de la base de données. • Déplacer notre charge de travail la plus importante vers sa propre base de données dédiée, donc un problème ne peut pas affecter le reste de la plateforme. • Ajouter des alertes et une surveillance plus approfondie pour l'utilisation des bases de données et la santé des bases de données. • Donnez à chaque service ses propres identifiants de base de données. • Traiter plus efficacement les événements entrants pour accélérer la récupération après une perturbation. • Améliorer le suivi des retards de traitement et des alertes internes. • Examiner la capacité de la base de données et les paramètres de performance pour ajouter plus de salle de tête.

11. 7 octobre 2026 à 14:22 UTCresolved

    (1/2) **1. Résumé** Le 5 octobre 2026, à partir de 15h55 IDT, les clients de notre plateforme américaine ont vu des réponses lentes, des erreurs intermittentes et des retards dans les vérifications des demandes de tirage et les scans CLI. Certains clients dont les dépôts nécessitent des vérifications de requêtes Cycode pull ne peuvent fusionner tant que la numérisation n'a pas repris. Le problème a commencé quand un processus de maintenance de fond dans notre base de données principale est tombé en arrière-plan et a cessé d'être terminé, et la base de données a cessé de sauvegarder de nouvelles données. Le rétablissement du service a pris plusieurs heures parce que la base de données en attente a dû d'abord traiter un important arriéré de changements. La base de données était de retour et la plate-forme était à nouveau disponible à 19:43 IDT. Le traitement a alors été retardé et l'incident a été réglé à 23 h 24 HAI. Les demandes de tirage qui n'ont pas été satisfaites pendant l'incident ont été scannées. **2. Échéancier principal (TDI)** • **5 octobre 2026, 12 h 55 Un processus de maintenance de base de données de routine commence à fonctionner beaucoup plus lentement que la normale. Pas encore d'impact client. • **5 octobre 2026, 14:53 IDT**: Le prochain cycle de maintenance commence et ne se termine pas. • **5 octobre 2026, 15 h 55 La base de données cesse d'enregistrer de nouvelles données et les performances de la plate-forme se dégradent. • **5 octobre, 2026, 16 h 03 La base de données atteint sa limite de connexion. Les clients commencent à voir des erreurs. • **5 octobre 2026, 16 h 21 Incident déclaré et l'équipe d'intervention engagée. • **5 octobre, 2026, 16 h 24 Première mise à jour affichée sur la page d'état. • **Le 5 octobre 2026, 16 h 49 Le passage à la base de données en attente a commencé. • **5 octobre 2026, 17:00 HAI**: Dossier d'assistance ouvert avec notre fournisseur d'infrastructure cloud. • **5 octobre 2026, 18 h 24 Une autre voie de récupération a commencé en parallèle. Solution publiée pour les clients bloqués par les contrôles de demande de tirage requis. • **5 octobre 2026, 19:43 IDT**: Base de données à nouveau disponible, et l'API Cycode et la plate-forme Cycode sont accessibles. • **5 octobre 2026, 19 h 54 Tirez les curriculum vitae des requêtes. • **5 octobre 2026, 20 h 20 La capacité de traitement a augmenté pour éliminer les événements retardés. • **5 octobre 2026, 20 h 45 Des charges de travail élevées se sont arrêtées pour réduire la charge de la base de données. • **5 octobre 2026, 21 h 56 Retirez les demandes manquées pendant l'incident identifié et scanné. • **5 octobre 2026, 23:09 IDT**: Tous les services sont pleinement opérationnels. • **5 octobre 2026, 23 h 24 L'incident est réglé. **3. Cause racine** Notre base de données exécute un processus de fond de routine qui enregistre régulièrement des changements récents au stockage permanent. Deux conditions ont contribué au ralentissement de ce processus : • **Exploitations de données de courte durée en volume:** Certaines de nos tâches de traitement ont constamment créé et supprimé un grand nombre de structures de données de courte durée. • **Une synchronisation d'arrière-plan retardée :** un processus de synthèse de données est tombé loin derrière, ce qui a empêché la base de données de se nettoyer après elle-même. Le processus de maintenance s'est ralenti et a finalement cessé de se terminer. La base de données ne pouvait alors plus enregistrer de nouvelles données, et les requêtes ont commencé à faire la file d'attente. Nos services ont rejugé ces demandes et ouvert de nombreuses nouvelles connexions, qui ont utilisé la capacité de connexion de la base de données. Les clients considéraient cela comme des erreurs et des réponses lentes. Nous sommes passés à notre base de données. Avant de pouvoir desservir le trafic, il a dû traiter tous les changements apportés depuis le dernier cycle d'entretien terminé, soit environ quatre heures d'activité. Ça a prolongé la panne. Mesures prises** • Réduction de la charge sur la base de données en réduisant temporairement le traitement non essentiel. • Démarrage d'un passage à la base de données en attente. • A ouvert un dossier de support avec notre fournisseur d'infrastructure cloud et travaillé avec eux sur une base intensifiée. • Préparé une autre voie de récupération en parallèle. • A partagé une solution de rechange temporaire pour les clients bloqués par les contrôles de demande de tirage requis. • Une fois la base de données récupérée, la capacité de traitement a augmenté pour éliminer les événements retardés.

12. 7 octobre 2026 à 14:22 UTCinvestigating

    Le dernier arriéré restant continue d'être traité à un rythme régulier. Nos estimations montrent que l'arriéré des dernières pièces devrait être traité dans environ 60-90 minutes (20:30 UTC). Nous constatons que la majorité des scans de requêtes de tirage (60 % au moment de cette mise à jour) sont effectués en moins de 15 minutes. et ce nombre augmente constamment à un rythme constant. Autre que ce système semble opérationnel. Nous croyons que l'application/l'UI sont pleinement opérationnelles.

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

1. 5 octobre 2026 à 13:24 UTCinvestigating

   Nous avons remarqué des performances dégradées chez prod-us Les flux comme la demande de tirage ou la numérisation CLI peuvent être plus lents que d'habitude

2. 5 octobre 2026 à 14:17 UTCinvestigating

   Nous continuons d'étudier une dégradation majeure de la plateforme américaine causée par l'épuisement de la connexion PostgreSQLTM. Les clients peuvent connaître des temps de réponse lents, des erreurs élevées de 500 et des flux de travail plus lents et des scans CLI. Nous avons réduit la charge de la base de données sur plusieurs services et nous avons lancé une panne RDS. L'équipe travaille activement pour rétablir des performances normales.

3. 5 octobre 2026 à 14:29 UTCinvestigating

   L'équipe travaille activement avec AWS et étudie ce qui semble être un problème de rupture de base de données affectant l'environnement américain. Nous allons partager une autre mise à jour dès que nous avons plus d'informations.

4. 5 octobre 2026 à 15:17 UTCinvestigating

   L'équipe continue de travailler avec AWS, qui a intensifié la question à l'interne. En parallèle, nous travaillons à restaurer la fonctionnalité en passant à une autre base de données. Toute demande de tirage bloqué en attente de l'état Cycode peut être débloquée en supprimant les scans Cycode des vérifications prévues directement dans votre SCM (Source Code Management). Communiquez avec votre représentant Cycode pour vous aider à rationaliser le processus.

5. 5 octobre 2026 à 16:10 UTCinvestigating

   AWS a confirmé que l'instance de PostgreSQL est actuellement dans un état de récupération interne. La chute attendue de Multi-AZ n'a pas eu lieu comme prévu, et AWS étudie activement pourquoi. Parallèlement, nous poursuivons nos efforts pour restaurer les services touchés en utilisant un autre chemin de base de données pour accélérer la récupération

6. 5 octobre 2026 à 16:58 UTCinvestigating

   Nous voyons la base de données rétablir ses capacités opérationnelles. Nous voyons les premiers scans Pull Request en cours de traitement. Nous surveillons le système et augmentons le débit.

7. 5 octobre 2026 à 17:31 UTCinvestigating

   La base de données reste pleinement opérationnelle. Nous travaillons à accélérer le traitement au-delà des délais réguliers pour traiter tous les arriérés dès que possible.

8. 5 octobre 2026 à 18:17 UTCinvestigating

   La plateforme américaine s'améliore à la suite de l'épuisement de la connexion RDS/PostgreSQL. AWS a confirmé que l'instance originale PostgreSQL est revenue à un état opérationnel, et nous voyons les scans PR être traités à nouveau. La principale dégradation restante est le retard dans le traitement sous l'impulsion de GitHub en raison d'un important arriéré de webhook, qui continue de s'épuiser. Nous allons continuer à surveiller la récupération et fournir une autre mise à jour que le traitement retourne à la normale

9. 5 octobre 2026 à 19:06 UTCinvestigating

   Le dernier arriéré restant continue d'être traité à un rythme régulier. Nos estimations montrent que l'arriéré des dernières pièces devrait être traité dans environ 60-90 minutes (20:30 UTC). Nous constatons que la majorité des scans de requêtes de tirage (60 % au moment de cette mise à jour) sont effectués en moins de 15 minutes. et ce nombre augmente constamment à un rythme constant. Autre que ce système semble opérationnel. Nous croyons que l'application/l'UI sont pleinement opérationnelles.

10. 5 octobre 2026 à 20:09 UTCinvestigating

    Le système est de nouveau pleinement opérationnel

11. 5 octobre 2026 à 20:24 UTCresolved

    **1. Résumé** Le 5 octobre 2026, à partir de 15h55 IDT, les clients de notre plateforme américaine ont vu des réponses lentes, des erreurs intermittentes et des retards dans les vérifications des demandes de tirage et les scans CLI. Certains clients dont les dépôts nécessitent des vérifications de requêtes Cycode pull ne peuvent fusionner tant que la numérisation n'a pas repris. Le problème a commencé quand un processus de maintenance de fond dans notre base de données principale est tombé en arrière-plan et a cessé d'être terminé, et la base de données a cessé de sauvegarder de nouvelles données. Le rétablissement du service a pris plusieurs heures parce que la base de données en attente a dû d'abord traiter un important arriéré de changements. La base de données était de retour et la plate-forme était à nouveau disponible à 19:43 IDT. Le traitement a alors été retardé et l'incident a été réglé à 23 h 24 HAI. Les demandes de tirage qui n'ont pas été satisfaites pendant l'incident ont été scannées. **2. Échéancier principal (TDI)** • **5 octobre 2026, 12 h 55 Un processus de maintenance de base de données de routine commence à fonctionner beaucoup plus lentement que la normale. Pas encore d'impact client. • **5 octobre 2026, 14:53 IDT**: Le prochain cycle de maintenance commence et ne se termine pas. • **5 octobre 2026, 15 h 55 La base de données cesse d'enregistrer de nouvelles données et les performances de la plate-forme se dégradent. • **5 octobre, 2026, 16 h 03 La base de données atteint sa limite de connexion. Les clients commencent à voir des erreurs. • **5 octobre 2026, 16 h 21 Incident déclaré et l'équipe d'intervention engagée. • **5 octobre, 2026, 16 h 24 Première mise à jour affichée sur la page d'état. • **Le 5 octobre 2026, 16 h 49 Le passage à la base de données en attente a commencé. • **5 octobre 2026, 17:00 HAI**: Dossier d'assistance ouvert avec notre fournisseur d'infrastructure cloud. • **5 octobre 2026, 18 h 24 Une autre voie de récupération a commencé en parallèle. Solution publiée pour les clients bloqués par les contrôles de demande de tirage requis. • **5 octobre 2026, 19:43 IDT**: Base de données à nouveau disponible, et l'API Cycode et la plate-forme Cycode sont accessibles. • **5 octobre 2026, 19 h 54 Tirez les curriculum vitae des requêtes. • **5 octobre 2026, 20 h 20 La capacité de traitement a augmenté pour éliminer les événements retardés. • **5 octobre 2026, 20 h 45 Des charges de travail élevées se sont arrêtées pour réduire la charge de la base de données. • **5 octobre 2026, 21 h 56 Retirez les demandes manquées pendant l'incident identifié et scanné. • **5 octobre 2026, 23:09 IDT**: Tous les services sont pleinement opérationnels. • **5 octobre 2026, 23 h 24 L'incident est réglé. **3. Cause racine** Notre base de données exécute un processus de fond de routine qui enregistre régulièrement des changements récents au stockage permanent. Deux conditions ont contribué au ralentissement de ce processus : • **Exploitations de données de courte durée en volume:** Certaines de nos tâches de traitement ont constamment créé et supprimé un grand nombre de structures de données de courte durée. • **Une synchronisation d'arrière-plan retardée :** un processus de synthèse de données est tombé loin derrière, ce qui a empêché la base de données de se nettoyer après elle-même. Le processus de maintenance s'est ralenti et a finalement cessé de se terminer. La base de données ne pouvait alors plus enregistrer de nouvelles données, et les requêtes ont commencé à faire la file d'attente. Nos services ont rejugé ces demandes et ouvert de nombreuses nouvelles connexions, qui ont utilisé la capacité de connexion de la base de données. Les clients considéraient cela comme des erreurs et des réponses lentes. Nous sommes passés à notre base de données. Avant de pouvoir desservir le trafic, il a dû traiter tous les changements apportés depuis le dernier cycle d'entretien terminé, soit environ quatre heures d'activité. Ça a prolongé la panne. Mesures prises** • Réduction de la charge sur la base de données en réduisant temporairement le traitement non essentiel. • Démarrage d'un passage à la base de données en attente. • A ouvert un dossier de support avec notre fournisseur d'infrastructure cloud et travaillé avec eux sur une base intensifiée. • Préparé une autre voie de récupération en parallèle. • A partagé une solution de rechange temporaire pour les clients bloqués par les contrôles de demande de tirage requis. • Une fois la base de données récupérée, la capacité de traitement a augmenté pour éliminer les événements retardés. • Les charges de travail qui créaient des volumes élevés d'opérations de données à courte durée de vie, afin de réduire la charge de travail des bases de données tout en éliminant les événements retardés. • Scanné les demandes de tirage qui ont été manquées pendant l'incident. **4b. Mesures prises** • Modifier la façon dont de grandes séries de données sont écrites pour réduire la charge de la base de données. • Déplacer notre charge de travail la plus importante vers sa propre base de données dédiée, donc un problème ne peut pas affecter le reste de la plateforme. • Ajouter des alertes et une surveillance plus approfondie pour l'utilisation des bases de données et la santé des bases de données. • Donnez à chaque service ses propres identifiants de base de données. • Traiter plus efficacement les événements entrants pour accélérer la récupération après une perturbation. • Améliorer le suivi des retards de traitement et des alertes internes. • Examiner la capacité de la base de données et les paramètres de performance pour ajouter plus de salle de tête.

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

1. 7 octobre 2026 à 14:14 UTCmonitoring

   À 14 h HAE (18 h UTC), nous avons identifié un pic de charge important affectant la base de données d'authentification. Pour atténuer le problème, nous avons effectué une mise à jour d'instance. Une brève interruption des connexions à la base de données peut avoir eu lieu pendant la mise à niveau. La plate-forme est stable et nous continuons de suivre de près la situation.

2. 7 octobre 2026 à 14:14 UTCresolved

   Le système est pleinement opérationnel, sans problème permanent. Cet incident est maintenant résolu.

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

1. 28 septembre 2026 à 19:08 UTCmonitoring

   À 14 h HAE (18 h UTC), nous avons identifié un pic de charge important affectant la base de données d'authentification. Pour atténuer le problème, nous avons effectué une mise à jour d'instance. Une brève interruption des connexions à la base de données peut avoir eu lieu pendant la mise à niveau. La plate-forme est stable et nous continuons de suivre de près la situation.

2. 28 septembre 2026 à 20:45 UTCresolved

   Le système est pleinement opérationnel, sans problème permanent. Cet incident est maintenant résolu.

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

1. 7 octobre 2026 à 14:14 UTCresolved

   Résolue

2. 7 octobre 2026 à 14:14 UTCinvestigating

   Composant GitHub: Demandes de tirage incident GitHub original:

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

1. 8 octobre 2026 à 08:42 UTCinvestigating

   Composant GitHub: Demandes de tirage incident GitHub original:

2. 8 octobre 2026 à 08:42 UTCresolved

   Résolue

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

1. 13 septembre 2026 à 10:36 UTCinvestigating

   Composant GitHub: Demandes de tirage incident GitHub original:

2. 13 septembre 2026 à 18:53 UTCresolved

   Résolue

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

1. 7 octobre 2026 à 14:04 UTCresolved

   Les mesures MemoryDB sont stables, le délai de traitement s'est rétabli et le système est maintenant pleinement opérationnel.

2. 7 octobre 2026 à 14:04 UTCmonitoring

   Nous avons observé une forte augmentation de l'utilisation de mémoire MemoryDB dans le prod-us, y compris l'utilisation active de swap. L'atténuation a été appliquée. Les mesures MemoryDB sont restées stables depuis, et le retard de traitement diminue rapidement

3. 7 octobre 2026 à 14:04 UTCinvestigating

   Nous avons remarqué des performances dégradées chez prod-us Les flux comme la demande de tirage ou la numérisation CLI peuvent être plus lents que d'habitude

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

1. 8 septembre 2026 à 16:53 UTCinvestigating

   Nous avons remarqué des performances dégradées chez prod-us Les flux comme la demande de tirage ou la numérisation CLI peuvent être plus lents que d'habitude

2. 8 septembre 2026 à 17:21 UTCmonitoring

   Nous avons observé une forte augmentation de l'utilisation de mémoire MemoryDB dans le prod-us, y compris l'utilisation active de swap. L'atténuation a été appliquée. Les mesures MemoryDB sont restées stables depuis, et le retard de traitement diminue rapidement

3. 8 septembre 2026 à 17:26 UTCresolved

   Les mesures MemoryDB sont stables, le délai de traitement s'est rétabli et le système est maintenant pleinement opérationnel.

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

1. 7 octobre 2026 à 14:14 UTCinvestigating

   Nous avons remarqué des performances dégradées dans prod-eu. La dégradation des performances affecte toutes les applications et tous les flux (**comme la demande de tirage ou la numérisation CLI**) peuvent être plus lents que d'habitude. Notre première enquête suggère une charge excessive sur la base de données partagée, ce qui ralentit la lecture et l'écriture. L'équipe continue d'enquêter.

2. 7 octobre 2026 à 14:14 UTCresolved

   Le système est de nouveau pleinement opérationnel.

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

1. 8 septembre 2026 à 09:53 UTCinvestigating

   Nous avons remarqué des performances dégradées dans prod-eu. La dégradation des performances affecte toutes les applications et tous les flux (**comme la demande de tirage ou la numérisation CLI**) peuvent être plus lents que d'habitude. Notre première enquête suggère une charge excessive sur la base de données partagée, ce qui ralentit la lecture et l'écriture. L'équipe continue d'enquêter.

2. 8 septembre 2026 à 10:52 UTCresolved

   Le système est de nouveau pleinement opérationnel.

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

1. 7 octobre 2026 à 14:14 UTCresolved

   Composant GitHub: Demandes de tirage L'incident initial de GitHub: https://stspg.io/0xbhhq84v4mt

2. 7 octobre 2026 à 14:14 UTCinvestigating

   Composant GitHub: Demandes de tirage L'incident initial de GitHub: https://stspg.io/0xbhhq84v4mt

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

1. 8 octobre 2026 à 08:42 UTCinvestigating

   Composant GitHub: Demandes de tirage L'incident initial de GitHub: https://stspg.io/0xbhhq84v4mt

2. 8 octobre 2026 à 08:42 UTCresolved

   Composant GitHub: Demandes de tirage L'incident initial de GitHub: https://stspg.io/0xbhhq84v4mt

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

1. 1 septembre 2026 à 15:10 UTCinvestigating

   Composant GitHub: Demandes de tirage L'incident initial de GitHub: https://stspg.io/0xbhhq84v4mt

2. 1 septembre 2026 à 16:05 UTCresolved

   Composant GitHub: Demandes de tirage L'incident initial de GitHub: https://stspg.io/0xbhhq84v4mt

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

1. 8 octobre 2026 à 08:42 UTCinvestigating

   Composant GitHub: Demandes de tirage L'incident initial de GitHub: https://stspg.io/nrbwjftcz72d

2. 8 octobre 2026 à 08:42 UTCresolved

   Composant GitHub: Demandes de tirage L'incident initial de GitHub: https://stspg.io/nrbwjftcz72d

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