Historique des pannes de Circle Ci

1. 21 octobre 2026 à 19:31 UTCidentified

   Certains utilisateurs pourraient voir des temps d'attente accrus pour les emplois de gen2 Docker en raison de problèmes de capacité.

2. 21 octobre 2026 à 20:03 UTCidentified

   Nous ajoutons une capacité supplémentaire pour aider à atténuer le problème. Note: Nous voyons toujours des retards jusqu'à 20 minutes sur 2xlarge.

3. 21 octobre 2026 à 20:22 UTCidentified

   Les temps d'attente pour les 2xlarge docker emplois se rétablissent. Nous continuerons à nous mettre à jour au fur et à mesure que la capacité sera en ligne.

4. 21 octobre 2026 à 20:35 UTCidentified

   Les temps d'attente pour les travaux de 2xlarge docker sont maintenant inférieurs à 60 secondes. Les temps d'attente pour d'autres tailles de ressources n'ont pas été touchés par cet incident et demeurent inférieurs à 10 secondes.

5. 21 octobre 2026 à 20:40 UTCmonitoring

   Nous avons assisté à une reprise complète des temps d'attente pour les emplois de docker.

6. 21 octobre 2026 à 20:54 UTCresolved

   Temps d'attente pour les emplois de gen2 Docker ont récupéré et les emplois fonctionnent dans les temps d'attente normaux.

7. 22 octobre 2026 à 23:29 UTCpostmortem

   Résumé De 15:44 à 20:55 UTC le 21 Octobre, les clients exécutant les emplois de Gen 2 Docker ont vu des temps d'attente accrus pour leurs emplois pour commencer. Les retards étaient plus longs dans la classe de ressources 2xlarge, où les emplois attendaient jusqu'à 20 minutes. L'incident a été causé par la disponibilité limitée des instances cloud que nous avions configurées pour répondre à la demande, en particulier pour 2xgrands emplois. En réponse, notre équipe d'ingénierie a configuré d'autres types d'instances, configuré d'autres groupes de Docker Gen 2. À 20h55 UTC, les temps d'attente sont revenus à la normale et l'incident a été résolu. Après la résolution de l'incident, nous avons étendu notre flotte de Ge 2 Docker à d'autres régions nuageuses, et nous continuons de nous tenir activement debout à d'autres régions nuageuses afin de prévenir des incidents semblables à l'avenir. La page d'état originale se trouve ici : [21 octobre - Augmentation des temps d'attente de Docker gen2] (https://status.circleci.com/incidents/5jb50gh55gtj). Historique Lorsque CircleCI exécute un travail Docker, nous l'échelonnons sur l'un des plusieurs groupes d'instances cloud, et chaque instance est capable d'exécuter plusieurs tâches isolées. Planifier un travail sur une instance de cloud est un classique (https://en.wikipedia.org/wiki/Bin packing problem): trouver la capacité disponible qui correspond à la classe de ressources demandée CPU, mémoire et stockage. Les classes de ressources plus grandes comme 2xlarge sont plus difficiles à adapter que les plus petites, qui se rassemblent plus étroitement. Nous fournissons des instances en nuage en utilisant une liste classée de types d'instance. Si le fournisseur de cloud ne peut pas fournir notre premier choix, nous revenons au type suivant de la liste. Nous maintenons également une taille minimale de la flotte: un nombre minimum d'instances restent en cours, de sorte que nous n'abandonnons pas la capacité lorsque la demande est faible. Au-delà de cette taille minimale, nous ajoutons des exemples à mesure que la demande augmente. Quand il y a une capacité insuffisante pour exécuter une charge de travail, nous faisons la file d'attente qui fonctionne jusqu'à ce que la capacité soit disponible. Ce qui s'est passé \(Toutes les heures UTC\) À partir de 15h44, le 21 octobre, la demande pour la classe de ressources Gén. 2xlarge a fortement augmenté, et nous n'avons pas fourni de capacité supplémentaire assez rapidement pour suivre. Notre équipe d'ingénieurs a commencé à enquêter. Vers 19h25, les temps d'attente pour la classe de ressources Gen 2 2xlarge avaient atteint 20 minutes, et les temps d'attente pour d'autres classes de ressources avaient également augmenté. Dès 19h56, notre équipe d'ingénierie avait configuré des types d'instance supplémentaires à la flotte de Gen 2 afin d'obtenir plus de capacité en ligne, et à 19h59, nous dispensions ces types d'instance. À 20h11, nous avons ajouté plusieurs clusters de Gen 2 supplémentaires et augmenté la taille minimale de la flotte sur ces clusters. À 20h35, le nombre d'emplois en attente est revenu à des niveaux normaux, et à 20h41, 95 % des emplois de 2xlarge débutaient en 4 secondes. Nous avons résolu l'incident à 20 h 55. Après avoir résolu cet incident, nous avons ajouté des régions nuageuses supplémentaires pour les emplois de Docker afin de rendre plus de capacité disponible. ## Prévention future et amélioration des processus Nous avons déjà pris les mesures suivantes pour améliorer les temps de démarrage de l'emploi, y compris l'approvisionnement en capacités à partir de plus d'endroits, la réservation de plus de capacités pour de grandes classes de ressources et la mise en place d'un approvisionnement plus rapide. **Nous avons ajouté des régions supplémentaires pour les emplois de Docker.** Nous avons récemment ajouté des régions nuageuses supplémentaires pour les emplois de Machine, et nous avons maintenant fait de même pour les emplois de Docker. **Nous continuerons activement à ajouter des régions nuageuses supplémentaires pour les emplois de Docker et de Machine**. **Nous avons ajouté d'autres grappes de Gen 2**. Nous avons configuré plusieurs clusters Gen 2 supplémentaires pour planifier les travaux plus rapidement et pour rendre plus disponible la capacité totale. **Nous avons élargi l'ensemble des types d'instances en nuage que nous utilisons et avons augmenté la taille de notre flotte minimale.** Nous avons configuré des types d'instance supplémentaires. Nous avons également augmenté la taille minimale de la flotte du groupe 2 pour répondre à la demande de référence actuelle. **Nous avons modifié notre calendrier d'emploi afin de prioriser le calendrier des grandes classes de ressources.** Nous avons modifié la façon dont nous planifions les emplois afin d'équilibrer les temps d'attente plus équitablement entre les classes de ressources, et pour les travaux de bin-pack plus efficacement sur les instances disponibles. Conclusion L'expérience client est notre priorité, et nous nous engageons à améliorer continuellement la fiabilité de nos systèmes pour correspondre à la confiance que nos clients nous accordent. Nous remercions nos clients pour leur patience pendant que notre équipe a travaillé à résoudre cet incident. Veuillez contacter notre équipe de soutien pour toute question ou préoccupation.

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

1. 20 octobre 2026 à 15:58 UTCinvestigating

   Nous voyons des temps d'attente accrus pour certains emplois macOS utilisant la classe de ressources m4pro.large. Nous enquêtons et fournirons une autre mise à jour bientôt. Merci de votre patience.

2. 20 octobre 2026 à 16:32 UTCmonitoring

   Les clients exécutant des jobs macOS sur la classe de ressources m4pro.large voient encore des temps d'attente augmentés, certains travaux attendant jusqu'à 30 minutes pour commencer. Nous poursuivons notre surveillance et nous partagerons une autre mise à jour sous peu.

3. 20 octobre 2026 à 17:02 UTCmonitoring

   Les temps d'attente pour m4pro.large sont encore élevés en raison de la forte demande. Tous les m4pro.medium sont normaux. Nous suivons activement, nous apprécions la patience.

4. 20 octobre 2026 à 17:31 UTCmonitoring

   Temps d'attente pour les travaux macOS sur la classe de ressources m4pro.large sont en cours de récupération. Les emplois utilisant Xcode 27.0 attendent maintenant environ ~3,5 minutes en moyenne, à partir d'environ ~40 minutes au pic. Les emplois utilisant les codes X26,6 et 26.4.1 sont toujours en attente, ce qui permet de rattraper le retard accumulé. Les temps d'attente sur m4pro.medium sont normaux. Nous partagerons une autre mise à jour dès que nous continuerons à surveiller.

5. 20 octobre 2026 à 18:14 UTCresolved

   Les temps d'attente pour les travaux macOS sur la classe de ressources m4pro.large sont revenus à la normale. Nous vous remercions de votre patience pendant que les arriérés sont réglés.

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

1. 14 octobre 2026 à 14:47 UTCinvestigating

   Depuis environ 14:00 UTC, les clients exécutant des tâches macOS qui utilisent Xcode 26.6.0 sur la grande classe de ressources M4 Pro connaissent des retards de démarrage des emplois. Les temps d'attente ont atteint 30 minutes ou plus. Merci de votre patience pendant que nos ingénieurs enquêtent. Nous fournirons une autre mise à jour avant 15:30 UTC.

2. 14 octobre 2026 à 15:17 UTCidentified

   Retarde le démarrage des tâches macOS qui utilisent Xcode 26.6.0 ont récupéré. Depuis environ 15:11 UTC, les emplois macOS qui utilisent Xcode 26.4 connaissent des retards au départ, avec des temps d'attente d'environ 30 minutes. Merci de votre patience pendant que nos ingénieurs travaillent à résoudre ce problème. Nous fournirons une autre mise à jour d'ici 15h45 UTC.

3. 14 octobre 2026 à 16:01 UTCresolved

   Entre 14h00 UTC et 15h51 UTC le 14 octobre, les clients exécutant des tâches macOS qui utilisent Xcode 26.6.0 ou Xcode 26.4 ont connu des retards dans le démarrage des tâches. À partir de 14h00 UTC environ, les emplois utilisant le Xcode 26.6.0 de la grande classe de ressources M4 Pro ont attendu 30 minutes ou plus pour commencer, et ces retards se sont rétablis à environ 15h12 UTC. A partir d'environ 15:11 UTC, les travaux qui utilisent Xcode 26.4 ont attendu environ 30 minutes pour commencer. Le problème a été résolu et toutes les fonctionnalités affectées sont revenues à la normale. Nous vous remercions de votre patience pendant que notre équipe a travaillé à la mise en place d'un correctif.

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

1. 9 octobre 2026 à 11:33 UTCidentified

   Il y a un retard dans notre infrastructure de données causant des retards avant de construire des données et certaines notifications deviennent visibles. Nous travaillons sur une atténuation.

2. 9 octobre 2026 à 13:00 UTCidentified

   Ce qui est touché : Les clients déclenchent des pipelines, et les clients s'appuient sur des webhooks sortants et des notifications de courriel et de Slack. Que pouvez-vous attendre Depuis 11h15 UTC: - Les pipelines sont encore en cours de création, mais ils ne sont pas encore traités, de sorte que le redémarrage peut donner lieu à des pipelines en double. - Les webhooks sortants et les notifications transactionnelles (Slack et email) ne sont pas envoyés. - Les statuts des pipelines peuvent ne pas être visibles. - Les données relatives aux frais d'utilisation sur la page d'utilisation du projet seront inexistantes. Merci de votre patience pendant que nos ingénieurs travaillent à résoudre ce problème. Prochaine mise à jour: Nous fournirons une autre mise à jour avant 13:30 UTC.

3. 9 octobre 2026 à 13:30 UTCidentified

   Entre 11h15 UTC et environ 13h00 UTC, des pipelines ont été créés, mais non traités, et des webhooks sortants et des notifications transactionnelles (Slack et email) n'ont pas été envoyés. Ce qui est touché : Les clients déclenchent des pipelines, et les clients s'appuient sur des webhooks sortants et des notifications de courriel et de Slack. À quoi vous attendre : - Depuis environ 13h00 UTC, les pipelines sont à nouveau traités et les emplois commencent. - La plupart des emplois commencent actuellement dans environ 4 minutes, et certains attendent jusqu'à environ 10 minutes. Les pipelines déclenchés pendant l'incident sont encore en cours de traitement et peuvent prendre plus de temps pour démarrer. - Les webhooks sortants et les notifications ont repris. - Les pipelines sont toujours traités à partir de l'arriéré, de sorte que le redémarrage peut entraîner des pipelines en double. Merci de votre patience pendant que nos ingénieurs travaillent à résoudre ce problème. Prochaine mise à jour: Nous fournirons une autre mise à jour avant 14:00 UTC.

4. 9 octobre 2026 à 14:00 UTCidentified

   Depuis 11h15 UTC, les clients ont subi des perturbations dans les pipelines et les avis. Entre 11h15 UTC et environ 13h00 UTC, des pipelines ont été créés, mais non traités, et des webhooks sortants et des notifications transactionnelles (Slack et email) n'ont pas été envoyés. Ce qui est touché Clients exécutant des workflows et des emplois, et clients regardant les données d'utilisation sur la page Utilisation du projet. Que pouvez-vous attendre - Les pipelines sont à nouveau traités, y compris ceux déclenchés pendant l'incident. - Depuis environ 13h25 UTC, les workflows et les emplois commencent avec des retards croissants au fur et à mesure que nous résolvons l'arriéré. La plupart des emplois commencent actuellement dans environ 10 minutes, et certains attendent jusqu'à environ 25 minutes. - Nous nous attendons à faire face à cet arriéré d'environ 14h35 UTC. - Les flux de travail des pipelines déclenchés pendant l'incident sont toujours en attente de démarrage, de sorte que le redémarrage peut entraîner des flux de travail en double. - Les données relatives aux frais d'utilisation sur la page d'utilisation du projet sont actuellement inexistantes. Merci de votre patience pendant que nos ingénieurs travaillent à résoudre ce problème. Prochaine mise à jour Nous fournirons une autre mise à jour avant 14:30 UTC.

5. 9 octobre 2026 à 14:29 UTCidentified

   Depuis 11h15 UTC, les clients ont subi des perturbations dans les pipelines et les avis. Entre 11h15 UTC et environ 13h00 UTC, des pipelines ont été créés, mais non traités, et des webhooks sortants et des notifications transactionnelles (Slack et email) n'ont pas été envoyés. Ce qui est touché Clients exécutant des workflows et des emplois, et clients regardant les données d'utilisation sur la page Utilisation du projet. Que pouvez-vous attendre - Les retards dans le démarrage des workflows et des emplois s'améliorent. La plupart des emplois commencent maintenant dans environ 3 minutes, à partir d'environ 10 minutes à 13:50 UTC. - Certains flux de travail des pipelines déclenchés pendant l'incident attendent encore jusqu'à environ 40 minutes pour démarrer. - L'arriéré prend un peu plus de temps que prévu. Nous nous attendons maintenant à l'éliminer d'environ 14h45 UTC. - Les flux de travail des pipelines déclenchés pendant l'incident sont toujours en attente de démarrage, de sorte que le redémarrage peut entraîner des flux de travail en double. - Les données relatives aux frais d'utilisation sur la page d'utilisation du projet sont actuellement inexistantes. Merci de votre patience pendant que nos ingénieurs travaillent à résoudre ce problème. Prochaine mise à jour Nous fournirons une autre mise à jour d'ici 15:00 UTC.

6. 9 octobre 2026 à 14:43 UTCidentified

   Depuis 11h15 UTC, les clients ont subi des perturbations dans les pipelines et les avis. Entre 11h15 UTC et environ 13h00 UTC, des pipelines ont été créés, mais non traités, et des webhooks sortants et des notifications transactionnelles (Slack et email) n'ont pas été envoyés. Entre environ 13:00 UTC et 14:40 UTC, les workflows et les emplois ont commencé avec des retards pendant que nous avons travaillé sur l'arriéré. Quoi? Clients exécutant des workflows et des emplois, et clients regardant les données d'utilisation sur la page Utilisation du projet. Que pouvez-vous attendre - L'arriéré des flux de travail des pipelines déclenchés lors de l'incident a été réglé vers 14h40 UTC. - La plupart des emplois commencent maintenant dans environ 30 secondes, et certains attendent jusqu'à environ 3 minutes. - Les données relatives aux frais d'utilisation sur la page d'utilisation du projet sont actuellement inexistantes. Merci de votre patience pendant que nos ingénieurs continuent à travailler sur le problème sous-jacent. Prochaine mise à jour Nous fournirons une autre mise à jour par 15:10 UTC.

7. 9 octobre 2026 à 14:54 UTCmonitoring

   Depuis 11h15 UTC, les clients ont subi des perturbations dans les pipelines et les avis. Entre 11h15 UTC et environ 13h00 UTC, des pipelines ont été créés, mais non traités, et des webhooks sortants et des notifications transactionnelles (Slack et email) n'ont pas été envoyés. Entre environ 13:00 UTC et 14:40 UTC, les workflows et les emplois ont commencé avec des retards pendant que nous avons travaillé sur l'arriéré. Quoi? Clients exécutant des workflows et des emplois, et clients regardant les données d'utilisation sur la page Utilisation du projet. Que pouvez-vous attendre - L'arriéré des pipelines et des flux de travail de l'incident a été réglé. - Depuis environ 14h45 UTC, la plupart des workflows et des emplois commencent dans environ 15 secondes, et les temps de départ continuent de revenir à la normale. - Les données relatives aux frais d'utilisation sur la page d'utilisation du projet sont actuellement inexistantes. Merci de votre patience pendant que nos ingénieurs surveillent la récupération. Prochaine mise à jour Nous fournirons une autre mise à jour d'ici 15h20 UTC.

8. 9 octobre 2026 à 15:32 UTCmonitoring

   Depuis 11h15 UTC, les clients ont subi des perturbations dans les pipelines et les avis. Entre 11h15 UTC et environ 13h00 UTC, des pipelines ont été créés, mais non traités, et des webhooks sortants et des notifications transactionnelles (Slack et email) n'ont pas été envoyés. Entre environ 13:00 UTC et 14:40 UTC, les workflows et les emplois ont commencé avec des retards pendant que nous avons travaillé sur l'arriéré. Ce qui est touché Les clients regardent les pipelines, les workflows et les emplois dans l'interface utilisateur CircleCI, et les clients regardent les données d'utilisation sur la page Utilisation du projet. Que pouvez-vous attendre - Les flux de travail et les emplois fonctionnent à temps. - L'assurance-chômage CircleCI est à 30 minutes de retard. De nouveaux flux de travail et des changements d'état peuvent prendre du temps à apparaître. - Nos ingénieurs travaillent activement pour accélérer le traitement afin que l'UI puisse rattraper son retard. - Veuillez éviter de redémarrer les workflows qui n'apparaissent pas encore dans l'interface utilisateur, car cela peut créer des duplications. - Les données relatives aux frais d'utilisation sur la page d'utilisation du projet sont actuellement inexistantes. Merci de votre patience pendant que nos ingénieurs travaillent pour réduire ce retard. Prochaine mise à jour Nous fournirons une autre mise à jour avant 16:00 UTC.

9. 9 octobre 2026 à 16:02 UTCmonitoring

   Depuis 11h15 UTC, les clients ont subi des perturbations dans les pipelines et les avis. Entre 11h15 UTC et environ 13h00 UTC, des pipelines ont été créés, mais non traités, et des webhooks sortants et des notifications transactionnelles (Slack et email) n'ont pas été envoyés. Entre environ 13:00 UTC et 14:40 UTC, les workflows et les emplois ont commencé avec des retards pendant que nous avons travaillé sur l'arriéré. Ce qui est touché Clients exécutant des workflows et des emplois, clients regardant des pipelines, des workflows et des emplois dans l'interface utilisateur CircleCI, et clients regardant des données d'utilisation sur la page Utilisation du projet. Que pouvez-vous attendre - Depuis environ 15h15 UTC, les workflows et les emplois commencent avec des retards croissants. La plupart des emplois commencent actuellement en 4 minutes, et certains attendent jusqu'à 20 minutes. - L'assurance-chômage CircleCI reste à environ 30 minutes de retard en moyenne, et certaines mises à jour prennent plus de temps. De nouveaux flux de travail et des changements d'état peuvent prendre du temps à apparaître. - Veuillez éviter de redémarrer les workflows qui n'apparaissent pas encore dans l'interface utilisateur, car cela peut créer des duplications. - Les données relatives aux frais d'utilisation sur la page d'utilisation du projet sont actuellement inexistantes. Merci de votre patience pendant que nos ingénieurs travaillent à réduire ces retards. Prochaine mise à jour Nous fournirons une autre mise à jour d'ici 16:30 UTC.

10. 9 octobre 2026 à 16:32 UTCmonitoring

    Depuis 11h15 UTC, les clients ont subi des perturbations dans les pipelines et les avis. Entre 11h15 UTC et environ 13h00 UTC, des pipelines ont été créés, mais non traités, et des webhooks sortants et des notifications transactionnelles (Slack et email) n'ont pas été envoyés. Entre environ 13:00 UTC et 14:40 UTC, les workflows et les emplois ont commencé avec des retards pendant que nous avons travaillé sur l'arriéré. Depuis environ 15h15 UTC, les workflows et les emplois commencent à nouveau avec des retards. Ce qui est touché Clients exécutant des workflows et des emplois, clients regardant des pipelines, des workflows et des emplois dans l'interface utilisateur CircleCI, et clients regardant des données d'utilisation sur la page Utilisation du projet. Que pouvez-vous attendre - Les retards dans le démarrage des workflows et des emplois ont cessé d'augmenter et commencent à s'atténuer. La plupart des emplois commencent dans les 4 minutes, et certains attendent jusqu'à environ 25 minutes. - L'assurance-chômage CircleCI est maintenant à environ 20 minutes de retard, à partir d'environ 30 minutes. De nouveaux flux de travail et des changements d'état peuvent prendre du temps à apparaître. - Veuillez éviter de redémarrer les workflows qui n'apparaissent pas encore dans l'interface utilisateur, car cela peut créer des duplications. - Les données relatives aux frais d'utilisation sur la page d'utilisation du projet sont actuellement inexistantes. Merci de votre patience pendant que nos ingénieurs travaillent à réduire ces retards. Prochaine mise à jour Nous fournirons une autre mise à jour avant 17:00 UTC.

11. 9 octobre 2026 à 17:06 UTCmonitoring

    Depuis 11h15 UTC, les clients ont subi des perturbations dans les pipelines et les avis. Entre 11h15 UTC et environ 13h00 UTC, des pipelines ont été créés, mais non traités, et des webhooks sortants et des notifications transactionnelles (Slack et email) n'ont pas été envoyés. Entre environ 13:00 UTC et 14:40 UTC, les workflows et les emplois ont commencé avec des retards pendant que nous avons travaillé sur l'arriéré. Depuis environ 15h15 UTC, les workflows et les emplois commencent à nouveau avec des retards. Quoi? Clients exécutant des workflows et des emplois, clients regardant des pipelines, des workflows et des emplois dans l'interface utilisateur CircleCI, et clients regardant des données d'utilisation sur la page Utilisation du projet. Que pouvez-vous attendre - Retards dans le démarrage des workflows et des emplois. La plupart des emplois commencent dans les 4 minutes, et certains attendent jusqu'à environ 8 minutes, à partir d'environ 25 minutes. - L'assurance-chômage CircleCI reste à environ 20 minutes de retard en moyenne, et certaines mises à jour prennent plus de temps. De nouveaux flux de travail et des changements d'état peuvent prendre du temps à apparaître. - Veuillez éviter de redémarrer les workflows qui n'apparaissent pas encore dans l'interface utilisateur, car cela peut créer des duplications. - Les données relatives aux frais d'utilisation sur la page d'utilisation du projet sont actuellement inexistantes. Merci de votre patience pendant que nos ingénieurs travaillent à réduire ces retards. Prochaine mise à jour Nous fournirons une autre mise à jour avant 17:30 UTC.

12. 9 octobre 2026 à 17:34 UTCidentified

    Depuis 11h15 UTC, les clients ont subi des perturbations dans les pipelines et les avis. Entre 11h15 UTC et environ 13h00 UTC, des pipelines ont été créés, mais non traités, et des webhooks sortants et des notifications transactionnelles (Slack et email) n'ont pas été envoyés. Entre environ 13:00 UTC et 14:40 UTC, les workflows et les emplois ont commencé avec des retards pendant que nous avons travaillé sur l'arriéré. Depuis environ 15h15 UTC, les workflows et les emplois commencent à nouveau avec des retards. Quoi? Les clients déclenchent des pipelines et exécutent des workflows et des emplois, les clients regardent des pipelines, des workflows et des emplois dans l'interface utilisateur CircleCI, et les clients regardent des données d'utilisation sur la page Utilisation du projet. Que pouvez-vous attendre - Depuis environ 17h00 UTC, les retards ont augmenté considérablement. La plupart des emplois prennent maintenant environ 12 minutes pour commencer, et certains attendent jusqu'à environ 30 minutes. - Depuis environ 17h15 UTC, certains emplois ne commencent pas. - Les pipelines sont traités plus lentement, donc certains peuvent prendre plus de temps pour commencer. - L'UI CircleCI est en retard de plus d'une heure. De nouveaux flux de travail et des changements d'état peuvent prendre du temps à apparaître. - Veuillez éviter de redémarrer les workflows qui n'apparaissent pas encore dans l'interface utilisateur, car cela peut créer des duplications. - Les données relatives aux frais d'utilisation sur la page d'utilisation du projet sont actuellement inexistantes. Merci de votre patience pendant que nos ingénieurs travaillent à résoudre ce problème. Prochaine mise à jour Nous fournirons une autre mise à jour d'ici 18:00 UTC.

13. 9 octobre 2026 à 18:08 UTCidentified

    Depuis 11h15 UTC, les clients ont subi des perturbations dans les pipelines et les avis. Entre 11h15 UTC et environ 13h00 UTC, des pipelines ont été créés, mais non traités, et des webhooks sortants et des notifications transactionnelles (Slack et email) n'ont pas été envoyés. Entre environ 13:00 UTC et 14:40 UTC, les workflows et les emplois ont commencé avec des retards pendant que nous avons travaillé sur l'arriéré. Depuis environ 15h15 UTC, les workflows et les emplois commencent à nouveau avec des retards. Quoi? Les clients déclenchent des pipelines et exécutent des workflows et des emplois, les clients regardent des pipelines, des workflows et des emplois dans l'interface utilisateur CircleCI, et les clients regardent des données d'utilisation sur la page Utilisation du projet. À quoi s'attendre - Depuis environ 17h00 UTC, nous constatons une augmentation des retards. La plupart des emplois prennent maintenant environ 25 minutes pour commencer, et certains attendent jusqu'à environ une heure. - Depuis environ 17:15 UTC, certains workflows en cours ont échoué et un petit nombre d'emplois ne démarrent pas. - De nouveaux pipelines sont en attente et prennent plus de temps à démarrer. - L'UI CircleCI est en retard de plus d'une heure. De nouveaux flux de travail et des changements d'état peuvent prendre du temps à apparaître. - Veuillez éviter de redémarrer les workflows qui n'apparaissent pas encore dans l'interface utilisateur, car cela peut créer des duplications. - Les données relatives aux frais d'utilisation sur la page d'utilisation du projet sont actuellement inexistantes. Nos ingénieurs continuent de travailler pour résoudre le problème. Prochaine mise à jour Nous fournirons une autre mise à jour d'ici 18:30 UTC.

14. 9 octobre 2026 à 18:32 UTCidentified

    Ce qui a changé depuis notre dernière mise à jour * L'UI CircleCI est à environ une heure de retard, et jusqu'à environ 90 minutes pour certaines mises à jour. Les flux de travail et les emplois peuvent déjà avoir couru, ou être en cours d'exécution, même si l'assurance-chômage les montre comme non commencés ou ne les montre pas du tout. * Les emplois qui courent commencent plus rapidement. La plupart commencent maintenant dans environ 15 minutes, à partir d'environ 28 minutes, mais certains attendent encore plus d'une heure. * Les nouveaux pipelines sont de plus en plus retardés. * Certains flux de travail échouent encore. Les flux de travail qui n'ont pas pu être traités à temps sont marqués comme ayant échoué. * Veuillez éviter de redémarrer les workflows qui n'apparaissent pas encore dans l'interface utilisateur, car cela peut créer des duplications. Toujours en cours : Les données relatives aux frais d'utilisation sur la page Utilisation du projet sont inexistantes. Prochaine mise à jour Nous fournirons une autre mise à jour avant 19:00 UTC.

15. 9 octobre 2026 à 18:57 UTCidentified

    Ce qui a changé depuis notre dernière mise à jour * Les emplois commencent plus rapidement. La plupart commencent maintenant dans environ 8 minutes, en baisse d'environ 15 minutes, et les plus longues attentes ont chuté de plus d'une heure à environ 45 minutes. * L'assurance-chômage CircleCI commence à rattraper son retard, mais elle est toujours en retard. Les flux de travail et les emplois peuvent déjà avoir couru, ou être en cours d'exécution, même si l'assurance-chômage les montre comme non commencés ou ne les montre pas du tout. * Les pipelines sont traités plus rapidement, mais les nouveaux pipelines sont encore retardés. Toujours en cours * Certains workflows et emplois échouent encore. * Veuillez éviter de redémarrer les workflows qui n'apparaissent pas encore dans l'interface utilisateur, car cela peut créer des duplications. * Les données de charge d'utilisation sur la page d'utilisation du projet sont inexistantes. Prochaine mise à jour Nous fournirons une autre mise à jour avant 19:30 UTC.

16. 9 octobre 2026 à 19:29 UTCidentified

    Depuis notre dernière mise à jour, les emplois commencent plus rapidement: la plupart commencent maintenant dans les 6 minutes, à partir d'environ 8 minutes. L'assurance-chômage CircleCI rattrape, mais toujours à une heure de retard. De nouveaux pipelines sont traités à leur arrivée. Les emplois peuvent déjà avoir été exécutés même si l'interface utilisateur ne les montre pas encore, alors évitez de redémarrer les workflows qui n'apparaissent pas dans l'interface utilisateur. Nous fournirons une autre mise à jour d'ici 20:00 UTC.

17. 9 octobre 2026 à 20:06 UTCidentified

    Les emplois commencent plus vite et moins nombreux sont les échecs : la plupart des emplois commencent maintenant dans les 4 minutes, en baisse d'environ 6 minutes, et les plus longues attentes ont chuté d'environ 30 minutes à environ 20 minutes. Des pipelines datant de plus tôt dans l'incident sont maintenant en cours de réalisation. L'UI CircleCI est toujours en retard, et certaines mises à jour plus anciennes peuvent prendre plus de temps à apparaître. Les emplois peuvent déjà avoir été exécutés même si l'interface utilisateur ne les montre pas encore, alors évitez de redémarrer les workflows qui n'apparaissent pas dans l'interface utilisateur. Nous fournirons une autre mise à jour d'ici 20:30 UTC.

18. 9 octobre 2026 à 21:22 UTCidentified

    Depuis environ 20h48 UTC, de nouveaux workflows et emplois ne commencent pas. Nous avons temporairement interrompu le démarrage de nouveaux travaux afin que nos systèmes puissent rattraper le travail déjà en cours, y compris les mises à jour retardées de l'interface utilisateur CircleCI et de l'API. Des mises à jour plus anciennes apparaissent maintenant dans l'interface utilisateur et l'API à mesure que cet arriéré disparaît. De nouveaux pipelines sont toujours acceptés et en attente Veuillez éviter de redémarrer des pipelines ou des workflows pendant cette période, car cela peut créer des duplications une fois le travail repris. Nous fournirons une autre mise à jour avant 22:00 UTC.

19. 9 octobre 2026 à 22:09 UTCidentified

    Depuis notre dernière mise à jour, la plupart des pipelines qui ont été retardés plus tôt dans l'incident ont maintenant été traités, et leurs flux de travail sont en attente pour commencer. De nouveaux workflows et de nouveaux emplois restent en pause pendant que nous nous préparons à reprendre le travail en toute sécurité. Les mises à jour retardées continuent d'apparaître dans l'interface utilisateur CircleCI et l'API. Veuillez continuer à éviter de redémarrer les pipelines ou les workflows, car cela peut créer des duplications une fois que le travail reprend. Nous fournirons une autre mise à jour avant 22:30 UTC.

20. 9 octobre 2026 à 22:28 UTCidentified

    Depuis notre dernière mise à jour, nous avons commencé à reprendre progressivement le travail, et certains workflows et travaux en attente recommencent. La plupart des travaux en attente sont toujours en attente, et les travaux qui commencent peuvent avoir attendu plus d'une heure. Nous augmentons soigneusement le taux pour éviter de surcharger nos systèmes. Les mises à jour retardées continuent d'apparaître dans l'interface utilisateur CircleCI et l'API. Veuillez continuer à éviter de redémarrer les pipelines ou les workflows, car cela peut créer des duplications à mesure que le travail en attente reprend. Nous fournirons une autre mise à jour avant 23:00 UTC.

21. 9 octobre 2026 à 23:00 UTCidentified

    Un grand nombre de workflows et d'emplois en file d'attente ont commencé, et l'interface utilisateur CircleCI et l'API ont rattrapé et montrent des mises à jour normalement avec peu de retards. Nous continuons de travailler dans le cadre des travaux en attente. Les emplois de la file d'attente ont peut-être attendu environ une heure ou plus pour commencer, et certains emplois Linux attendent jusqu'à environ 10 minutes de capacité. S'il vous plaît continuer à éviter de redémarrer pendant que le travail en attente continue à traiter. Nous fournirons une autre mise à jour avant 23:30 UTC.

22. 9 octobre 2026 à 23:38 UTCidentified

    Nous travaillons toujours sur un arriéré important de workflows et d'emplois en attente. Les temps d'attente s'améliorent, mais ils restent plus longs que la normale et certains emplois ont attendu plus d'une heure. L'interface utilisateur CircleCI et l'API demeurent à jour. Veuillez éviter de redémarrer les pipelines ou les workflows pendant que l'arriéré s'annule, car cela peut créer des duplications. Nous fournirons une autre mise à jour avant 00:00 UTC.

23. 9 octobre 2026 à 23:59 UTCidentified

    Depuis notre dernière mise à jour, l'arriéré de workflows et d'emplois en file d'attente a été comblé, à partir de 23h47 UTC. Les flux de travail et les emplois commencent maintenant en quelques secondes, et l'interface utilisateur CircleCI et l'API sont à jour. Nous surveillons nos systèmes de près pour nous assurer qu'ils restent stables. Nous fournirons une autre mise à jour d'ici 00:30 UTC.

24. 10 octobre 2026 à 00:45 UTCidentified

    Les flux de travail et les emplois ont continué de commencer normalement, en quelques secondes, et l'interface utilisateur et l'API de CircleCI demeurent à jour. Les notifications de slack et d'email retardées plus tôt dans l'incident sont toujours en cours de livraison. Les données relatives aux frais d'utilisation sur la page Utilisation du projet sont inexistantes. Nous continuons de surveiller nos systèmes de près et nous fournirons une autre mise à jour d'ici 01:15 UTC.

25. 10 octobre 2026 à 01:23 UTCmonitoring

    Les flux de travail et les emplois commencent et fonctionnent normalement, et l'interface utilisateur CircleCI et l'API sont à jour. Nous continuons de surveiller nos systèmes de près pour nous assurer qu'ils demeurent stables. Nous fournirons une autre mise à jour avant 02:00 UTC.

26. 10 octobre 2026 à 02:08 UTCresolved

    Entre 11h15 UTC et 23h47 UTC le 9 octobre, les clients ont connu des retards et des défaillances dans les pipelines, les workflows et les emplois, ainsi que des retards dans l'interface utilisateur CircleCI, l'API et les notifications. De 11h15 à 13h00 UTC, des pipelines ont été créés mais non traités, et des webhooks sortants et des notifications de Slack et de courriel n'ont pas été envoyés. De 13:00 à 14:40 UTC, les workflows et les emplois ont commencé avec des retards pendant que nous avons travaillé sur l'arriéré. De 15h15 à 20h48 UTC, les workflows et les emplois ont commencé avec des retards croissants, allant jusqu'à environ une heure, et l'interface utilisateur et API de CircleCI a chuté de 2 heures. Pendant cette période, certains travaux n'ont pas commencé et certains workflows en cours ont échoué. De 20:48 à environ 22:10 UTC, nous avons temporairement interrompu le démarrage de nouveaux workflows et des emplois afin que nos systèmes puissent récupérer. De nouveaux pipelines ont été acceptés et en attente pendant cette période. De 22h10 à 23h47 UTC, les workflows et les emplois en attente ont repris et ont été traités. Certains avaient attendu jusqu'à environ 2 heures. Le problème a été résolu et toutes les fonctionnalités affectées sont revenues à la normale. Les données relatives aux frais d'utilisation sur la page Utilisation du projet ne sont pas encore à jour et seront mises à jour une fois que nos données seront remplies. Les clients dont les emplois ont échoué pendant cette fenêtre peuvent réutiliser des emplois affectés. Nous vous remercions de votre patience pendant que nos ingénieurs ont travaillé à la mise en œuvre d'un correctif.

27. 12 octobre 2026 à 22:32 UTCpostmortem

    ## Summary Between 11:15 UTC and 23:47 UTC on October 9, CircleCI customers experienced hours-long delays and failures across pipelines, workflows and jobs, along with delays in the CircleCI UI, API and notifications. * From 11:15 to 13:00 UTC, pipelines were created but not processed, and outbound webhooks and Slack and email notifications were not sent. * From 13:00 to 14:40 UTC, workflows and jobs started with delays while we worked through the backlog. * From 15:15 to 20:48 UTC, workflows and jobs started with increasing delays, of up to about an hour, and the CircleCI UI and API fell behind by up to about 2 hours. During this time, some jobs failed to start and some in-progress workflows failed. * From 20:48 to 22:10 UTC, we temporarily paused starting new workflows and jobs so our systems could recover. New pipelines were accepted and queued during this time. * From 22:10 to 23:47 UTC, queued workflows and jobs resumed and were successfully processed. Some of them had waited up to about 2 hours. * By 23:47, the incident was mitigated. The status page for this incident can be found at [October 9 - Delay in data appearing in UI and API](https://status.circleci.com/incidents/6cfhhlr4rmm0). Customers experienced a similar incident earlier in the week at [October 6 - Delays in pipelines, workflows, UI data, and notifications](https://status.circleci.com/incidents/z4hbq8h49j8c). Multiple CircleCI services use Temporal backed by Postgres as a reliable queueing mechanism, and both incidents had the same cause: the rate of writes to Temporal's Postgres instance were faster than Postgres’s transaction log could archive those writes. In both cases, this caused multi-hour delays in processing both pipelines and status notifications. We evaluated several mitigations, then paused new workflow starts so the system could recover safely, and ramped back up gradually. We then throttled work back up until our systems returned to normal. To permanently resolve the bottleneck, we have split work across multiple Temporal instances, each with its own independent database and worker clusters, and we load-balance across them. We had already scheduled infrastructure work starting the week of October 12 that would have removed this exact bottleneck and prevented these incidents. So starting 19:11 on October 9 our engineering team implemented, tested, and rolled out a simpler version of these changes within a few hours. We further added new alerting and tuned the underlying databases for better performance under high load. Customers whose jobs failed during this window may rerun them. ## Background To run customer jobs, CircleCI executes a series of steps: we accept customer pipelines; we assign jobs for those pipelines to workers; we deliver status updates for those pipelines and jobs; and we charge customers for the credits those jobs consume. Each of these steps is implemented by an independent service, with reliable queues in between. Historically we have implemented these reliable queues with RabbitMQ on top of durable storage, with exponential backoff and dead letter queues for reliability. Over the last year, we have increasingly reimplemented our reliable queues on [Temporal](https://temporal.io/), which provides far better durability and reliability guarantees over a simpler and more powerful programming model. Our build service \(which turns a pipeline config into an executable plan\), our workflow orchestrator service \(which distributes tasks onto workers\), our notification service \(which delivers status updates\), and our charging service \(which charges customers for credits\) all now use Temporal. Temporal stores the state for its workflows and activities \(called “history”\) in a database, and this is the only component in a Temporal instance that is synchronous and stateful. As a consequence, a Temporal instance’s ability to accept and execute workflows is dependent on the write rate of its backing database. We have also configured Temporal to delete completed workflows and activities from its history 3 days after they complete. At the time of this incident, we used a single clustered Temporal instance backed by a Multi-AZ Postgres RDS instance for all of these reliable queues. While a Multi-AZ RDS instance is resilient to zone failures, it maintains database consistency via a single write-ahead-log \(WAL\). At the time we had configured our Postgres instance to store its WAL on a Dedicated Log Volume \(DLV\) so log writes did not compete with data writes. The database archives the log continuously to backup storage, and it can only reuse space on the volume after the log has been archived. If the database writes logs faster than it archives, the volume fills and Postgres has no space to the write its WAL log. Then the database stops accepting incoming writes and goes entirely read-only. An RDS DLV is limited to 1TB of storage and 3000 IOPS and per AWS these limits are hardcoded and cannot be increased. ## What Happened _\(All times UTC\)_ One of the contributing factors to the October 6 incident was that we were processing a high rate of Temporal history deletions at the same time as incoming work, which in turn put pressure on the backing database. To resolve the October 6 incident, we changed cleanup settings on Temporal’s largest tables and moved the transaction log back to its dedicated volume. These changes eliminated the major source of transaction log writes, but did not consider the additional log writes from scheduled deletions. Because we have configured Temporal to delete completed workflows and activities from its history 3 days after they complete, the October 6 history was scheduled to be deleted on October 9. Starting at 08:00 on October 9, Temporal began processing those scheduled deletions, and as a consequence free space on the Postgres DLV began dropping precipitously, from 0.8TB at 08:00 to 0.1TB by 10:10. Our monitoring alerted at 10:28 and we declared an incident at 10:31. While our infrastructure team was investigating, at 11:15 the DLV ran out of space and the Postgres instance went read-only. This stopped all Temporal processing in its tracks. At 11:42, we restarted Postgres to move the WAL log from the DLV onto the data volume and use the spare disk space and IOPS there. This maneuver had mitigated the incident on October 6, and we knew it would take roughly 60 minutes. While the database was restarting, we began implementing several load-shedding techniques upstream of Temporal: * We began investigating whether we should shed incoming workloads altogether to keep the rest moving, but ultimately decided that this would provide no value. * At 12:29, we flagged off credit charging updates, which represented 12% of Temporal activities. This left the Pipeline Usage page with stale charging data, until we would backfill it, but would not lose data or prevent pipelines from running. At 12:59, the database was back up and began processing work that had queued since 11:15 and by 14:40, this backlog had cleared and jobs were starting on time. However, by 15:15, delays returned as database’s routing cleanup had fallen far behind on the tables Temporal uses to track queued and scheduled work. Those tables normally hold tens of thousands of deleted rows awaiting cleanup, but by late afternoon, they held tens of millions of rows. Every Temporal operation had to read past those rows, so the database spent much more processing time on each one and Temporal ran slower. This resulted in customers continuing to see hour-long delays in starting pipelines and in status updates. For the next several hours we attempted various mitigations, including: * Manipulating Temporal configuration values to reduce database pressure. This had minimal effect. * Running manual vacuum jobs to clean up dead rows in Postgres. This ended up competing for CPU with queries themselves, and was ultimately counterproductive. We cancelled them at 17:45 to relieve the pressure on the database load. * We began trying to move all of the notification usecases to a separate Temporal instance. This represented 18% of Temporal activities. We successfully finished moving notifications by 17:07. * At 17:16, we successfully implemented an optimization in our representation of pipeline state, which reduced it by 5%. That in turn reduced the size of database writes and therefore data pressure on the Postgres WAL log. None of these fully mitigated the issue. By 20:48, we realized that Postgres was now thrashing on database CPU and was no longer bottlenecked on log writes. We further realized that our upstream systems were both submitting new work and also retrying work that had earlier been submitted and failed. Recognizing that we were in a classic retry storm, we paused all incoming and retry work and let it queue up, in order to allow the database to fully complete in-process work. We then slowly throttled up queued work from 22:07 to keep the database at a sustainable load. This fully succeeded by 23:47 when all queued work had started, and we closed the incident at 02:08 on October 10. ## Future Prevention and Process Improvement ### Multiple Temporal Instances In parallel with incident mitigation and resolution, starting at 19:11 on October 9, we also began standing up multiple sharded Temporal instances and implementing the ability to load-balance incoming work between them. Each of the multiple Temporal instances maintains its own independent database and worker clusters, and so is isolated from the others. As a postmortem action item from the October 6 incident, we had already scheduled infrastructure work that would have removed the bottleneck of a single Temporal instance and Postgres database, starting October 12 and expecting to take 2 weeks. On October 9, we realized that this work simply could not wait, so our engineering team implemented, tested, and rolled out a simpler version of the planned changes within a few hours. These changes completed successfully at 01:45 on October 10. **In addition, we are changing how we store and monitor transaction logs.** Our Temporal database no longer uses the fixed-size log volume. We are adding alerts on how far log archiving falls behind and how fast the database writes logs, so we can act hours earlier than we did on October 9. **We are also revisiting the Temporal's deletion schedule.** Temporal deletes finished work a few days after it runs, so a busy day returns as database load later in the week. We are changing when and how quickly those deletions run. **We are changing how our systems retry when Temporal is slow.** On October 9, our systems retried failed work against Temporal and added to its load. As we committed after the October 6 incident, we are changing our systems to wait for Temporal to recover so work is not dropped. ## Conclusion Customer experience is our top priority, and we commit to continually improving the reliability of our systems to match the trust that our customers place in us. We thank our customers for their patience while our team worked to resolve these incidents. Please reach out to our support team with any questions or concerns.

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

1. 8 octobre 2026 à 13:00 UTCidentified

   Les clients peuvent connaître des temps d'attente élevés pour les travaux de machine. Nous travaillons à résoudre ce problème.

2. 8 octobre 2026 à 13:34 UTCidentified

   Les clients utilisant des postes de machine Linux connaissent des temps d'attente élevés, en moyenne environ 11 minutes, avec les plus longues attentes dépassant 30 minutes sur le moyen, bras.medium et bras.grandes classes de ressources. Nos ingénieurs ont identifié le problème et travaillent sur une solution. Nous fournirons une autre mise à jour avant 14:00 UTC.

3. 8 octobre 2026 à 14:04 UTCidentified

   Les clients utilisant des machines Linux connaissent des temps d'attente élevés, en moyenne 40 minutes, avec les plus longues attentes dépassant 50 minutes. La plupart des classes de ressources de machine Linux sont affectées, y compris moyen, grand, xlarge, 2xlarge et leurs équivalents bras. Nos ingénieurs ont identifié le problème et travaillent sur une solution. Nous fournirons une autre mise à jour avant 14:30 UTC.

4. 8 octobre 2026 à 14:37 UTCidentified

   Les clients utilisant des tâches de machine Linux et Docker à distance connaissent des temps d'attente élevés. Les temps d'attente ont commencé à diminuer et ont maintenant une moyenne d'environ 20 minutes, avec les plus longues attentes dépassant 40 minutes sur certaines classes de ressources. Nos ingénieurs ont identifié le problème et travaillent sur une solution. Nous fournirons une autre mise à jour d'ici 15:00 UTC.

5. 8 octobre 2026 à 15:01 UTCidentified

   Un correctif a été déployé et les temps d'attente sont en baisse, mais les clients utilisant Linux machine jobs et Remote Docker connaissent toujours des retards. Les temps d'attente moyens sont actuellement d'environ 11 minutes, les plus longs dépassant 35 minutes pour certaines classes de ressources. Nous nous efforçons d'accroître la capacité le plus rapidement possible. Nous fournirons une autre mise à jour avant 15:30 UTC.

6. 8 octobre 2026 à 15:31 UTCidentified

   Les temps d'attente continuent de diminuer, mais les clients utilisant des tâches de machine Linux et Docker à distance connaissent toujours des retards. Les temps d'attente sont actuellement d'environ 6 minutes. Les plus longues attentes, jusqu'à environ 20 minutes, sont sur le 2xlarge, bras.2xlarge et gpu.nvidia. petites classes de ressources. Nous nous efforçons d'accroître la capacité le plus rapidement possible. Nous fournirons une autre mise à jour avant 16:00 UTC.

7. 8 octobre 2026 à 15:59 UTCidentified

   Les temps d'attente continuent de diminuer, mais les clients utilisant des tâches de machine Linux et Docker à distance connaissent toujours des retards. Les temps d'attente sont actuellement d'environ 90 secondes, les plus longs pouvant atteindre environ 6 minutes sur certaines classes de ressources. Nous nous efforçons d'accroître la capacité le plus rapidement possible. Nous fournirons une autre mise à jour d'ici 16:30 UTC.

8. 8 octobre 2026 à 16:09 UTCmonitoring

   Temps d'attente pour les clients utilisant des tâches Linux machine et Docker distant sont revenus à la normale. Nous veillons à confirmer que les temps d'attente restent stables tout en continuant d'augmenter la capacité. Nous fournirons une autre mise à jour d'ici 16:30 UTC.

9. 8 octobre 2026 à 16:35 UTCresolved

   Entre 12h40 UTC et 16h00 UTC le 8 octobre, les clients utilisant des postes Linux et Docker à distance ont connu des temps d'attente élevés. Le problème a été résolu et les temps d'attente sont revenus à la normale. Nous vous remercions de votre patience pendant que notre équipe a travaillé à la mise en place d'un correctif.

10. 8 octobre 2026 à 17:54 UTCpostmortem

    Résumé Entre le 1er octobre et le 8 octobre 2026, les clients de CircleCI ont connu cinq incidents distincts dans lesquels des emplois ont attendu plus longtemps que la normale pour commencer, ou ont échoué à démarrer. Trois des incidents ont été causés par la disponibilité limitée de l'instance de notre fournisseur de cloud. L'un a été causé par un problème de configuration dans notre infrastructure de planification, et l'autre par des limites de mémoire sur un service interne, que nous avons soulevé pendant l'incident. * ** 1 octobre 07:57 à 10:24 UTC:** Docker Gen 2 a attendu jusqu'à 30 minutes pour commencer. Un problème de configuration a empêché les serveurs de programmation Gen 2 d'utiliser leurs disques locaux haute performance. Lors d'un éclatement de la circulation, les disques de repli saturés et le placement du travail ont ralenti. * **7 octobre, 13 h 27 à 14 h 06 UTC :** Les travaux de machines ont attendu plus longtemps que la normale parce que nous n'avons pas pu acquérir assez de machines virtuelles de notre fournisseur de cloud. * **7 octobre, 14 h 24 à 15 h 21 UTC :** Certains emplois ont échoué avec une erreur d'infrastructure, et les workflows ont été retardés. Le service qui donne à chaque travail sa configuration au démarrage est épuisé de mémoire et redémarré. * **7 octobre, 18 h 49 à 20 h 05 UTC :** Docker Gen 2 a attendu plus longtemps que la normale car nous n'avons pas pu acquérir suffisamment d'instances de notre fournisseur de cloud. * ** 8 octobre, 12 h 48 à 16 h 00 UTC :** Les travaux de machine Linux et les travaux Docker à distance ont attendu jusqu'à 50 minutes pour démarrer. Notre fournisseur de cloud n'avait pas assez de type d'instance que nous demandons, et un défaut dans la logique qui choisit un type d'instance différent nous a empêchés d'utiliser des alternatives. Les emplois qui ont attendu pendant ces incidents ont été retardés et non perdus. Les clients dont les emplois ont échoué avec une erreur d'infrastructure lors de l'incident du 7 octobre de 14:24 à 15:21 UTC peuvent les réutiliser. Les pages d'état d'origine se trouvent ci-dessous : * [1er octobre - Retards dans le démarrage des emplois du groupe 2 Docker] (https://status.circleci.com/incidents/22mrv46g6n7g) * [7 octobre - Retard dans le démarrage des tâches de la machine] (https://status.circleci.com/incidents/tj6wdnfjwr64) * [7 octobre - Niveau élevé d'infra sur les emplois clients] (https://status.circleci.com/incidents/0z31ldjd8m5v) * [7 octobre - Augmentation des temps d'attente pour Docker Gen2] (https://status.circleci.com/incidents/39rfrjmk5pvd) * [8 octobre - Augmentation des temps d'attente pour les emplois de machines] (https://status.circleci.com/incidents/jn756xtsy4xg) **Contexte** Chaque travail qui fonctionne sur CercleCI a besoin de calcul. D'où vient ce calcul dépend l'exécuteur. Les tâches Docker sont exécutées sur des groupes de serveurs qui planifient les travaux sur une flotte d'instances. Le programmeur est le logiciel sur les serveurs qui décide quelle instance exécute chaque tâche. Au moment de l'incident du 1er octobre, les emplois de Ge 2 Docker étaient occupés par un de ces groupes. Les emplois du groupe 1 Docker sont répartis entre plusieurs grappes. Les tâches de machine, y compris les tâches Docker à distance, obtenir une machine virtuelle dédiée. Un travail Docker distant est traité comme un travail de machine Linux depuis la soumission jusqu'à la fourniture. Notre service de fourniture de machines demande à chaque machine de notre fournisseur de cloud dans l'une des deux régions que nous utilisons normalement pour les travaux de machines. Lorsque le fournisseur ne peut pas fournir le type d'instance que nous demandons, le service tombe en arrière : il demande un type d'instance différent, ou une région différente, d'une liste que nous maintenons. Un emploi attend qu'une machine soit disponible. Quand un travail commence, il demande un service de configuration de travail pour sa configuration. Ce service fonctionne comme un ensemble de pods, qui sont de petites copies du même programme. Si trop de gousses s'arrêtent, les gousses restantes portent plus de charge, et les travaux ne peuvent pas commencer avant que le service se rétablisse. Ces chemins dépendent de trois types de capacité : le débit de nos systèmes de programmation, la fourniture d'instances par notre fournisseur de cloud, ainsi que la mémoire et le nombre de copies des services qui commencent à travailler. Un manque d'emplois fait attendre ou échouer. Ce qui s'est passé \(Toutes les heures UTC\) ** 1er octobre : Docker Gen 2 a retardé les travaux jusqu'à 30 minutes** À 07:44, l'activité disque sur les serveurs qui planifient les emplois de Gen 2 Docker a augmenté à 90% de la capacité et est restée là. À 07h57, le nombre d'emplois de Docker en attente de départ a commencé à augmenter, et les temps d'attente ont augmenté avec. Une alerte automatisée a téléphoné à l'ingénieur de garde à 08h08. Nous avons déclaré un incident à 8 h 42. À 8 h 43, les ingénieurs ont identifié une latence élevée sur les serveurs de programmation. Ils ont d'abord cru que les disques étaient trop lents pour la charge, donc ils ont préparé un changement à un type de disque plus rapide. À 9 h 01, l'équipe s'est entendue sur deux axes de travail : déplacer les serveurs vers des disques plus rapides, et ajouter un deuxième cluster de la génération 2 afin que les tâches se divisent en deux clusters. À 9 h 41, les ingénieurs ont trouvé la cause profonde. Chaque serveur de programmation dispose de disques rapides qui lui sont directement attachés, et le programmeur est censé y conserver ses données de travail. Ces serveurs fonctionnent sur une image du système d'exploitation renforcée par la sécurité, et sur cette image les disques rapides n'étaient pas utilisés. Le planificateur a plutôt écrit ses données pour ralentir les disques attachés au réseau. Le script qui met en place les disques rapides a échoué sans erreur, et une lacune dans la connexion sur ces serveurs a caché l'échec. Le trafic du groupe 2 était également devenu de plus en plus effréné. Les disques plus lents saturés pendant ces rafales, et le programmeur est tombé derrière. Les temps d'attente ont atteint leur point culminant à 9 h 54, lorsque les emplois de la classe de ressources moyennes de la génération 2 ont attendu jusqu'à 30 minutes. À 9h55, les ingénieurs ont appliqué un correctif qui a configuré correctement les disques rapides. À 10h11, le planificateur a commencé à placer des emplois plus rapidement, ce qui a confirmé que les serveurs pouvaient suivre de nouveaux emplois. Les temps d'attente pour le medium de Gen 2 sont tombés à 13 minutes à 10:14, 7 minutes à 10:17 et 1 minute 30 secondes à 10:20. Nous avons déplacé la page d'état à la surveillance à 10 h 24 et résolu l'incident à 10 h 45. À 11 h 20, le deuxième groupe de la génération 2 a commencé à occuper des emplois. ### **Le 7 octobre, 13h27 à 14h06: Augmentation des temps d'attente pour les postes de machines** Nous avons déclaré un incident à 13h27 après avoir vu des files d'attente et des temps d'attente élevés. Nous avons posté à la page de statut à 13:31. À 13h31, les ingénieurs ont vu que nous luttions pour acquérir des machines virtuelles pour des emplois de machines, et que le nombre d'emplois en attente de démarrage était élevé principalement pour des emplois de machines. À 13h34, les temps d'attente étaient élevés entre les exciteurs. À 13h48, les temps d'attente ont commencé à se rétablir à mesure que d'autres machines étaient disponibles, et nous avons résolu l'incident à 14h06. ### **Le 7 octobre, 14h24 à 15h21: Défauts d'emploi et retards de travail** Peu après que l'incident précédent ait été marqué comme résolu, nous avons déclaré un nouvel incident à 14h24 en raison d'une forte baisse du nombre d'emplois soumis à nos systèmes d'exécution. À 14 h 26, les ingénieurs ont vu que les modules du service de configuration de travail redémarraient. Les pods qui redémarrent laissent moins de copies du service pour répondre aux demandes, et les tâches qui ne pouvaient pas récupérer leur configuration après des tentatives répétées ont échoué avec une erreur d'infrastructure. Les flux de travail qui étaient déjà en cours attendaient des mises à jour des emplois qui n'avaient pas commencé. À 14h35, les ingénieurs ont augmenté la quantité de mémoire disponible pour les pods et augmenté le nombre de pods, ce qui a donné au service plus de copies pour partager la charge. Nous avons également augmenté la quantité de mémoire disponible Les soumissions de Job ont commencé à récupérer, et le nombre de messages circulant dans notre système de flux de travail est revenu à des niveaux normaux. À 14h44, nous avons déplacé la page d'état à la surveillance. Les pods du service de configuration de travail ont atteint leurs limites de mémoire et ont redémarré. Nous avons augmenté les allocations de mémoire et le nombre de modules, et le service a récupéré. À 15 h 13, nous avons augmenté le nombre de cas dans nos grappes de Docker de la génération 2 afin de pouvoir composer rapidement avec l'arriéré de travail en attente. Nous avons résolu l'incident à 15 h 21. ### **7 octobre, 18:49 à 20:05: Augmentation des temps d'attente pour les emplois de Docker Gen 2** Nous avons déclaré un nouvel incident à 18h49 après que les temps d'attente de Docker Gen 2 aient augmenté. À 18h51, les ingénieurs ont confirmé qu'une pénurie d'instances disponibles nous empêchait d'en acquérir assez, ce qui soulevait des temps d'attente. Les temps d'attente diffèrent selon la taille des classes de ressources. À 19 h 52, les temps d'attente moyens étaient inférieurs à une heure plus tôt à mesure que la capacité devenait disponible, bien que de brèves pics se soient poursuivis, et nous avons déplacé la page d'état à la surveillance. Nous avons résolu l'incident à 20 h 5. ### **Le 8 octobre : les tâches de machine Linux et de Docker à distance attendent jusqu'à 50 minutes** Nous avons déclaré un incident à 12h48 après avoir vu un grand nombre d'emplois en attente de départ et de longs temps d'attente pour les travaux de machine et Docker à distance. À 12h49, les ingénieurs ont vu que notre fournisseur de cloud ne pouvait pas fournir assez d'instances. Les retards ont continué à grimper au fur et à mesure que nous enquêtions. À 13 h 13, nous avons commencé à examiner la logique qui choisit un type d'instance ou une région différent lorsque notre premier choix n'est pas disponible. À 13h24, nous soupçonnions qu'un défaut dans cette logique nous empêchait d'utiliser d'autres types d'instances dans notre région primaire, donc nous avons désactivé notre région de repli et confirmé la cause du défaut. Les ingénieurs ont commencé à travailler sur une solution et l'ont déployé à 14h49. Le service a commencé à demander d'autres types d'instance et a commencé des machines en grand nombre. À 14h58, la file d'attente d'une machine a baissé régulièrement. Les temps d'attente moyens entre les classes de ressources ont continué de baisser au cours de l'heure suivante, alors que nous avons résorbé l'arriéré d'emplois en attente. À 16h00, la file d'attente des emplois en attente d'une machine dédouanée et le nombre d'emplois en attente sont revenus à la normale. Nous avons déplacé la page d'état à la surveillance à 16h09 et résolu l'incident à 16h35. **Prévention future et amélioration des processus** Nous prenons les mesures suivantes pour renforcer la résilience des temps de démarrage de l'emploi, y compris la diversification de l'offre, la logique de repli et la détection plus précoce. **Nous développons nos régions de calcul.** Dans les incidents du 7 et du 8 octobre, notre fournisseur de cloud n'a pas pu fournir suffisamment de cas dans les régions que nous utilisions. Nous ajoutons de nouvelles régions à notre logique de repli afin de gérer les pics de demande qui dépassent nos régions préférées. **Nous fixons la logique qui choisit un type d'instance différent.** Le 8 octobre, un défaut a empêché la fourniture de la machine d'utiliser d'autres types d'instances dans la même région. Nous avons déployé un correctif pendant l'incident et nous sommes en train de revoir et de remanier cette logique dans son ensemble, avec des tests, de sorte qu'une pénurie d'un type d'instance déplace le travail vers un autre. **Nous développons les types d'instances que nous offrons et garantissons des capacités supplémentaires.** Nous travaillons avec notre fournisseur de cloud pour réserver des capacités supplémentaires dans nos régions existantes, et nous ajoutons des types d'instances sur lesquels les emplois peuvent fonctionner. La demande de calcul à haut rendement augmente dans l'industrie. Nous diversifions nos sources de capacités et nos clients sont donc isolés de la variation de l'offre. **Nous avons ajouté un deuxième groupe de la génération 2 de Docker afin que les éclats de trafic soient répartis entre deux groupes.** Nous ajoutons également des alertes sur la saturation du disque du serveur et sur la rapidité avec laquelle le programmeur place les tâches, et une alerte qui s'allume lorsqu'un serveur démarre sans ses disques rapides en utilisation. Nous avons fait échouer le script de configuration du disque avec une erreur, et nous avons restauré l'expédition des journaux de ces serveurs afin qu'un problème similaire soit visible plus tôt. L'expérience client est notre priorité, et nous nous engageons à améliorer continuellement la fiabilité de nos systèmes pour correspondre à la confiance que nos clients nous accordent. Nous remercions nos clients pour leur patience pendant que notre équipe a travaillé à résoudre ces incidents. Veuillez contacter notre équipe de soutien pour toute question ou préoccupation.

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

1. 7 octobre 2026 à 18:54 UTCidentified

   Il y a un temps d'attente accru pour les emplois sur Docker Gen2.

2. 7 octobre 2026 à 19:00 UTCidentified

   Remarque : les retards seront plus visibles pour les personnes qui courent sur Docker `xlarge` et au-dessus.

3. 7 octobre 2026 à 19:52 UTCmonitoring

   Nous voyons toujours des pics dans les temps d'attente des tâches, mais en moyenne les temps d'attente sont meilleurs pour tous Docker Gen2.

4. 7 octobre 2026 à 20:05 UTCresolved

   Cet incident a été résolu.

5. 8 octobre 2026 à 17:54 UTCpostmortem

   Résumé Entre le 1er octobre et le 8 octobre 2026, les clients de CircleCI ont connu cinq incidents distincts dans lesquels des emplois ont attendu plus longtemps que la normale pour commencer, ou ont échoué à démarrer. Trois des incidents ont été causés par la disponibilité limitée de l'instance de notre fournisseur de cloud. L'un a été causé par un problème de configuration dans notre infrastructure de planification, et l'autre par des limites de mémoire sur un service interne, que nous avons soulevé pendant l'incident. * ** 1 octobre 07:57 à 10:24 UTC:** Docker Gen 2 a attendu jusqu'à 30 minutes pour commencer. Un problème de configuration a empêché les serveurs de programmation Gen 2 d'utiliser leurs disques locaux haute performance. Lors d'un éclatement de la circulation, les disques de repli saturés et le placement du travail ont ralenti. * **7 octobre, 13 h 27 à 14 h 06 UTC :** Les travaux de machines ont attendu plus longtemps que la normale parce que nous n'avons pas pu acquérir assez de machines virtuelles de notre fournisseur de cloud. * **7 octobre, 14 h 24 à 15 h 21 UTC :** Certains emplois ont échoué avec une erreur d'infrastructure, et les workflows ont été retardés. Le service qui donne à chaque travail sa configuration au démarrage est épuisé de mémoire et redémarré. * **7 octobre, 18 h 49 à 20 h 05 UTC :** Docker Gen 2 a attendu plus longtemps que la normale car nous n'avons pas pu acquérir suffisamment d'instances de notre fournisseur de cloud. * ** 8 octobre, 12 h 48 à 16 h 00 UTC :** Les travaux de machine Linux et les travaux Docker à distance ont attendu jusqu'à 50 minutes pour démarrer. Notre fournisseur de cloud n'avait pas assez de type d'instance que nous demandons, et un défaut dans la logique qui choisit un type d'instance différent nous a empêchés d'utiliser des alternatives. Les emplois qui ont attendu pendant ces incidents ont été retardés et non perdus. Les clients dont les emplois ont échoué avec une erreur d'infrastructure lors de l'incident du 7 octobre de 14:24 à 15:21 UTC peuvent les réutiliser. Les pages d'état d'origine se trouvent ci-dessous : * [1er octobre - Retards dans le démarrage des emplois du groupe 2 Docker] (https://status.circleci.com/incidents/22mrv46g6n7g) * [7 octobre - Retard dans le démarrage des tâches de la machine] (https://status.circleci.com/incidents/tj6wdnfjwr64) * [7 octobre - Niveau élevé d'infra sur les emplois clients] (https://status.circleci.com/incidents/0z31ldjd8m5v) * [7 octobre - Augmentation des temps d'attente pour Docker Gen2] (https://status.circleci.com/incidents/39rfrjmk5pvd) * [8 octobre - Augmentation des temps d'attente pour les emplois de machines] (https://status.circleci.com/incidents/jn756xtsy4xg) **Contexte** Chaque travail qui fonctionne sur CercleCI a besoin de calcul. D'où vient ce calcul dépend l'exécuteur. Les tâches Docker sont exécutées sur des groupes de serveurs qui planifient les travaux sur une flotte d'instances. Le programmeur est le logiciel sur les serveurs qui décide quelle instance exécute chaque tâche. Au moment de l'incident du 1er octobre, les emplois de Ge 2 Docker étaient occupés par un de ces groupes. Les emplois du groupe 1 Docker sont répartis entre plusieurs grappes. Les tâches de machine, y compris les tâches Docker à distance, obtenir une machine virtuelle dédiée. Un travail Docker distant est traité comme un travail de machine Linux depuis la soumission jusqu'à la fourniture. Notre service de fourniture de machines demande à chaque machine de notre fournisseur de cloud dans l'une des deux régions que nous utilisons normalement pour les travaux de machines. Lorsque le fournisseur ne peut pas fournir le type d'instance que nous demandons, le service tombe en arrière : il demande un type d'instance différent, ou une région différente, d'une liste que nous maintenons. Un emploi attend qu'une machine soit disponible. Quand un travail commence, il demande un service de configuration de travail pour sa configuration. Ce service fonctionne comme un ensemble de pods, qui sont de petites copies du même programme. Si trop de gousses s'arrêtent, les gousses restantes portent plus de charge, et les travaux ne peuvent pas commencer avant que le service se rétablisse. Ces chemins dépendent de trois types de capacité : le débit de nos systèmes de programmation, la fourniture d'instances par notre fournisseur de cloud, ainsi que la mémoire et le nombre de copies des services qui commencent à travailler. Un manque d'emplois fait attendre ou échouer. Ce qui s'est passé \(Toutes les heures UTC\) ** 1er octobre : Docker Gen 2 a retardé les travaux jusqu'à 30 minutes** À 07:44, l'activité disque sur les serveurs qui planifient les emplois de Gen 2 Docker a augmenté à 90% de la capacité et est restée là. À 07h57, le nombre d'emplois de Docker en attente de départ a commencé à augmenter, et les temps d'attente ont augmenté avec. Une alerte automatisée a téléphoné à l'ingénieur de garde à 08h08. Nous avons déclaré un incident à 8 h 42. À 8 h 43, les ingénieurs ont identifié une latence élevée sur les serveurs de programmation. Ils ont d'abord cru que les disques étaient trop lents pour la charge, donc ils ont préparé un changement à un type de disque plus rapide. À 9 h 01, l'équipe s'est entendue sur deux axes de travail : déplacer les serveurs vers des disques plus rapides, et ajouter un deuxième cluster de la génération 2 afin que les tâches se divisent en deux clusters. À 9 h 41, les ingénieurs ont trouvé la cause profonde. Chaque serveur de programmation dispose de disques rapides qui lui sont directement attachés, et le programmeur est censé y conserver ses données de travail. Ces serveurs fonctionnent sur une image du système d'exploitation renforcée par la sécurité, et sur cette image les disques rapides n'étaient pas utilisés. Le planificateur a plutôt écrit ses données pour ralentir les disques attachés au réseau. Le script qui met en place les disques rapides a échoué sans erreur, et une lacune dans la connexion sur ces serveurs a caché l'échec. Le trafic du groupe 2 était également devenu de plus en plus effréné. Les disques plus lents saturés pendant ces rafales, et le programmeur est tombé derrière. Les temps d'attente ont atteint leur point culminant à 9 h 54, lorsque les emplois de la classe de ressources moyennes de la génération 2 ont attendu jusqu'à 30 minutes. À 9h55, les ingénieurs ont appliqué un correctif qui a configuré correctement les disques rapides. À 10h11, le planificateur a commencé à placer des emplois plus rapidement, ce qui a confirmé que les serveurs pouvaient suivre de nouveaux emplois. Les temps d'attente pour le medium de Gen 2 sont tombés à 13 minutes à 10:14, 7 minutes à 10:17 et 1 minute 30 secondes à 10:20. Nous avons déplacé la page d'état à la surveillance à 10 h 24 et résolu l'incident à 10 h 45. À 11 h 20, le deuxième groupe de la génération 2 a commencé à occuper des emplois. ### **Le 7 octobre, 13h27 à 14h06: Augmentation des temps d'attente pour les postes de machines** Nous avons déclaré un incident à 13h27 après avoir vu des files d'attente et des temps d'attente élevés. Nous avons posté à la page de statut à 13:31. À 13h31, les ingénieurs ont vu que nous luttions pour acquérir des machines virtuelles pour des emplois de machines, et que le nombre d'emplois en attente de démarrage était élevé principalement pour des emplois de machines. À 13h34, les temps d'attente étaient élevés entre les exciteurs. À 13h48, les temps d'attente ont commencé à se rétablir à mesure que d'autres machines étaient disponibles, et nous avons résolu l'incident à 14h06. ### **Le 7 octobre, 14h24 à 15h21: Défauts d'emploi et retards de travail** Peu après que l'incident précédent ait été marqué comme résolu, nous avons déclaré un nouvel incident à 14h24 en raison d'une forte baisse du nombre d'emplois soumis à nos systèmes d'exécution. À 14 h 26, les ingénieurs ont vu que les modules du service de configuration de travail redémarraient. Les pods qui redémarrent laissent moins de copies du service pour répondre aux demandes, et les tâches qui ne pouvaient pas récupérer leur configuration après des tentatives répétées ont échoué avec une erreur d'infrastructure. Les flux de travail qui étaient déjà en cours attendaient des mises à jour des emplois qui n'avaient pas commencé. À 14h35, les ingénieurs ont augmenté la quantité de mémoire disponible pour les pods et augmenté le nombre de pods, ce qui a donné au service plus de copies pour partager la charge. Nous avons également augmenté la quantité de mémoire disponible Les soumissions de Job ont commencé à récupérer, et le nombre de messages circulant dans notre système de flux de travail est revenu à des niveaux normaux. À 14h44, nous avons déplacé la page d'état à la surveillance. Les pods du service de configuration de travail ont atteint leurs limites de mémoire et ont redémarré. Nous avons augmenté les allocations de mémoire et le nombre de modules, et le service a récupéré. À 15 h 13, nous avons augmenté le nombre de cas dans nos grappes de Docker de la génération 2 afin de pouvoir composer rapidement avec l'arriéré de travail en attente. Nous avons résolu l'incident à 15 h 21. ### **7 octobre, 18:49 à 20:05: Augmentation des temps d'attente pour les emplois de Docker Gen 2** Nous avons déclaré un nouvel incident à 18h49 après que les temps d'attente de Docker Gen 2 aient augmenté. À 18h51, les ingénieurs ont confirmé qu'une pénurie d'instances disponibles nous empêchait d'en acquérir assez, ce qui soulevait des temps d'attente. Les temps d'attente diffèrent selon la taille des classes de ressources. À 19 h 52, les temps d'attente moyens étaient inférieurs à une heure plus tôt à mesure que la capacité devenait disponible, bien que de brèves pics se soient poursuivis, et nous avons déplacé la page d'état à la surveillance. Nous avons résolu l'incident à 20 h 5. ### **Le 8 octobre : les tâches de machine Linux et de Docker à distance attendent jusqu'à 50 minutes** Nous avons déclaré un incident à 12h48 après avoir vu un grand nombre d'emplois en attente de départ et de longs temps d'attente pour les travaux de machine et Docker à distance. À 12h49, les ingénieurs ont vu que notre fournisseur de cloud ne pouvait pas fournir assez d'instances. Les retards ont continué à grimper au fur et à mesure que nous enquêtions. À 13 h 13, nous avons commencé à examiner la logique qui choisit un type d'instance ou une région différent lorsque notre premier choix n'est pas disponible. À 13h24, nous soupçonnions qu'un défaut dans cette logique nous empêchait d'utiliser d'autres types d'instances dans notre région primaire, donc nous avons désactivé notre région de repli et confirmé la cause du défaut. Les ingénieurs ont commencé à travailler sur une solution et l'ont déployé à 14h49. Le service a commencé à demander d'autres types d'instance et a commencé des machines en grand nombre. À 14h58, la file d'attente d'une machine a baissé régulièrement. Les temps d'attente moyens entre les classes de ressources ont continué de baisser au cours de l'heure suivante, alors que nous avons résorbé l'arriéré d'emplois en attente. À 16h00, la file d'attente des emplois en attente d'une machine dédouanée et le nombre d'emplois en attente sont revenus à la normale. Nous avons déplacé la page d'état à la surveillance à 16h09 et résolu l'incident à 16h35. **Prévention future et amélioration des processus** Nous prenons les mesures suivantes pour renforcer la résilience des temps de démarrage de l'emploi, y compris la diversification de l'offre, la logique de repli et la détection plus précoce. **Nous développons nos régions de calcul.** Dans les incidents du 7 et du 8 octobre, notre fournisseur de cloud n'a pas pu fournir suffisamment de cas dans les régions que nous utilisions. Nous ajoutons de nouvelles régions à notre logique de repli afin de gérer les pics de demande qui dépassent nos régions préférées. **Nous fixons la logique qui choisit un type d'instance différent.** Le 8 octobre, un défaut a empêché la fourniture de la machine d'utiliser d'autres types d'instances dans la même région. Nous avons déployé un correctif pendant l'incident et nous sommes en train de revoir et de remanier cette logique dans son ensemble, avec des tests, de sorte qu'une pénurie d'un type d'instance déplace le travail vers un autre. **Nous développons les types d'instances que nous offrons et garantissons des capacités supplémentaires.** Nous travaillons avec notre fournisseur de cloud pour réserver des capacités supplémentaires dans nos régions existantes, et nous ajoutons des types d'instances sur lesquels les emplois peuvent fonctionner. La demande de calcul à haut rendement augmente dans l'industrie. Nous diversifions nos sources de capacités et nos clients sont donc isolés de la variation de l'offre. **Nous avons ajouté un deuxième groupe de la génération 2 de Docker afin que les éclats de trafic soient répartis entre deux groupes.** Nous ajoutons également des alertes sur la saturation du disque du serveur et sur la rapidité avec laquelle le programmeur place les tâches, et une alerte qui s'allume lorsqu'un serveur démarre sans ses disques rapides en utilisation. Nous avons fait échouer le script de configuration du disque avec une erreur, et nous avons restauré l'expédition des journaux de ces serveurs afin qu'un problème similaire soit visible plus tôt. L'expérience client est notre priorité, et nous nous engageons à améliorer continuellement la fiabilité de nos systèmes pour correspondre à la confiance que nos clients nous accordent. Nous remercions nos clients pour leur patience pendant que notre équipe a travaillé à résoudre ces incidents. Veuillez contacter notre équipe de soutien pour toute question ou préoccupation.

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

1. 7 octobre 2026 à 14:27 UTCinvestigating

   Nous enquêtons sur une augmentation de l'infrastructure échoue pour les emplois clients.

2. 7 octobre 2026 à 14:44 UTCmonitoring

   Nous voyons des signes de guérison. Les temps d'attente Docker Gen2 sont légèrement élevés et nous surveillons.

3. 7 octobre 2026 à 15:21 UTCresolved

   Cet incident a été résolu.

4. 8 octobre 2026 à 17:55 UTCpostmortem

   Résumé Entre le 1er octobre et le 8 octobre 2026, les clients de CircleCI ont connu cinq incidents distincts dans lesquels des emplois ont attendu plus longtemps que la normale pour commencer, ou ont échoué à démarrer. Trois des incidents ont été causés par la disponibilité limitée de l'instance de notre fournisseur de cloud. L'un a été causé par un problème de configuration dans notre infrastructure de planification, et l'autre par des limites de mémoire sur un service interne, que nous avons soulevé pendant l'incident. * ** 1 octobre 07:57 à 10:24 UTC:** Docker Gen 2 a attendu jusqu'à 30 minutes pour commencer. Un problème de configuration a empêché les serveurs de programmation Gen 2 d'utiliser leurs disques locaux haute performance. Lors d'un éclatement de la circulation, les disques de repli saturés et le placement du travail ont ralenti. * **7 octobre, 13 h 27 à 14 h 06 UTC :** Les travaux de machines ont attendu plus longtemps que la normale parce que nous n'avons pas pu acquérir assez de machines virtuelles de notre fournisseur de cloud. * **7 octobre, 14 h 24 à 15 h 21 UTC :** Certains emplois ont échoué avec une erreur d'infrastructure, et les workflows ont été retardés. Le service qui donne à chaque travail sa configuration au démarrage est épuisé de mémoire et redémarré. * **7 octobre, 18 h 49 à 20 h 05 UTC :** Docker Gen 2 a attendu plus longtemps que la normale car nous n'avons pas pu acquérir suffisamment d'instances de notre fournisseur de cloud. * ** 8 octobre, 12 h 48 à 16 h 00 UTC :** Les travaux de machine Linux et les travaux Docker à distance ont attendu jusqu'à 50 minutes pour démarrer. Notre fournisseur de cloud n'avait pas assez de type d'instance que nous demandons, et un défaut dans la logique qui choisit un type d'instance différent nous a empêchés d'utiliser des alternatives. Les emplois qui ont attendu pendant ces incidents ont été retardés et non perdus. Les clients dont les emplois ont échoué avec une erreur d'infrastructure lors de l'incident du 7 octobre de 14:24 à 15:21 UTC peuvent les réutiliser. Les pages d'état d'origine se trouvent ci-dessous : * [1er octobre - Retards dans le démarrage des emplois du groupe 2 Docker] (https://status.circleci.com/incidents/22mrv46g6n7g) * [7 octobre - Retard dans le démarrage des tâches de la machine] (https://status.circleci.com/incidents/tj6wdnfjwr64) * [7 octobre - Niveau élevé d'infra sur les emplois clients] (https://status.circleci.com/incidents/0z31ldjd8m5v) * [7 octobre - Augmentation des temps d'attente pour Docker Gen2] (https://status.circleci.com/incidents/39rfrjmk5pvd) * [8 octobre - Augmentation des temps d'attente pour les emplois de machines] (https://status.circleci.com/incidents/jn756xtsy4xg) **Contexte** Chaque travail qui fonctionne sur CercleCI a besoin de calcul. D'où vient ce calcul dépend l'exécuteur. Les tâches Docker sont exécutées sur des groupes de serveurs qui planifient les travaux sur une flotte d'instances. Le programmeur est le logiciel sur les serveurs qui décide quelle instance exécute chaque tâche. Au moment de l'incident du 1er octobre, les emplois de Ge 2 Docker étaient occupés par un de ces groupes. Les emplois du groupe 1 Docker sont répartis entre plusieurs grappes. Les tâches de machine, y compris les tâches Docker à distance, obtenir une machine virtuelle dédiée. Un travail Docker distant est traité comme un travail de machine Linux depuis la soumission jusqu'à la fourniture. Notre service de fourniture de machines demande à chaque machine de notre fournisseur de cloud dans l'une des deux régions que nous utilisons normalement pour les travaux de machines. Lorsque le fournisseur ne peut pas fournir le type d'instance que nous demandons, le service tombe en arrière : il demande un type d'instance différent, ou une région différente, d'une liste que nous maintenons. Un emploi attend qu'une machine soit disponible. Quand un travail commence, il demande un service de configuration de travail pour sa configuration. Ce service fonctionne comme un ensemble de pods, qui sont de petites copies du même programme. Si trop de gousses s'arrêtent, les gousses restantes portent plus de charge, et les travaux ne peuvent pas commencer avant que le service se rétablisse. Ces chemins dépendent de trois types de capacité : le débit de nos systèmes de programmation, la fourniture d'instances par notre fournisseur de cloud, ainsi que la mémoire et le nombre de copies des services qui commencent à travailler. Un manque d'emplois fait attendre ou échouer. Ce qui s'est passé \(Toutes les heures UTC\) ** 1er octobre : Docker Gen 2 a retardé les travaux jusqu'à 30 minutes** À 07:44, l'activité disque sur les serveurs qui planifient les emplois de Gen 2 Docker a augmenté à 90% de la capacité et est restée là. À 07h57, le nombre d'emplois de Docker en attente de départ a commencé à augmenter, et les temps d'attente ont augmenté avec. Une alerte automatisée a téléphoné à l'ingénieur de garde à 08h08. Nous avons déclaré un incident à 8 h 42. À 8 h 43, les ingénieurs ont identifié une latence élevée sur les serveurs de programmation. Ils ont d'abord cru que les disques étaient trop lents pour la charge, donc ils ont préparé un changement à un type de disque plus rapide. À 9 h 01, l'équipe s'est entendue sur deux axes de travail : déplacer les serveurs vers des disques plus rapides, et ajouter un deuxième cluster de la génération 2 afin que les tâches se divisent en deux clusters. À 9 h 41, les ingénieurs ont trouvé la cause profonde. Chaque serveur de programmation dispose de disques rapides qui lui sont directement attachés, et le programmeur est censé y conserver ses données de travail. Ces serveurs fonctionnent sur une image du système d'exploitation renforcée par la sécurité, et sur cette image les disques rapides n'étaient pas utilisés. Le planificateur a plutôt écrit ses données pour ralentir les disques attachés au réseau. Le script qui met en place les disques rapides a échoué sans erreur, et une lacune dans la connexion sur ces serveurs a caché l'échec. Le trafic du groupe 2 était également devenu de plus en plus effréné. Les disques plus lents saturés pendant ces rafales, et le programmeur est tombé derrière. Les temps d'attente ont atteint leur point culminant à 9 h 54, lorsque les emplois de la classe de ressources moyennes de la génération 2 ont attendu jusqu'à 30 minutes. À 9h55, les ingénieurs ont appliqué un correctif qui a configuré correctement les disques rapides. À 10h11, le planificateur a commencé à placer des emplois plus rapidement, ce qui a confirmé que les serveurs pouvaient suivre de nouveaux emplois. Les temps d'attente pour le medium de Gen 2 sont tombés à 13 minutes à 10:14, 7 minutes à 10:17 et 1 minute 30 secondes à 10:20. Nous avons déplacé la page d'état à la surveillance à 10 h 24 et résolu l'incident à 10 h 45. À 11 h 20, le deuxième groupe de la génération 2 a commencé à occuper des emplois. ### **Le 7 octobre, 13h27 à 14h06: Augmentation des temps d'attente pour les postes de machines** Nous avons déclaré un incident à 13h27 après avoir vu des files d'attente et des temps d'attente élevés. Nous avons posté à la page de statut à 13:31. À 13h31, les ingénieurs ont vu que nous luttions pour acquérir des machines virtuelles pour des emplois de machines, et que le nombre d'emplois en attente de démarrage était élevé principalement pour des emplois de machines. À 13h34, les temps d'attente étaient élevés entre les exciteurs. À 13h48, les temps d'attente ont commencé à se rétablir à mesure que d'autres machines étaient disponibles, et nous avons résolu l'incident à 14h06. ### **Le 7 octobre, 14h24 à 15h21: Défauts d'emploi et retards de travail** Peu après que l'incident précédent ait été marqué comme résolu, nous avons déclaré un nouvel incident à 14h24 en raison d'une forte baisse du nombre d'emplois soumis à nos systèmes d'exécution. À 14 h 26, les ingénieurs ont vu que les modules du service de configuration de travail redémarraient. Les pods qui redémarrent laissent moins de copies du service pour répondre aux demandes, et les tâches qui ne pouvaient pas récupérer leur configuration après des tentatives répétées ont échoué avec une erreur d'infrastructure. Les flux de travail qui étaient déjà en cours attendaient des mises à jour des emplois qui n'avaient pas commencé. À 14h35, les ingénieurs ont augmenté la quantité de mémoire disponible pour les pods et augmenté le nombre de pods, ce qui a donné au service plus de copies pour partager la charge. Nous avons également augmenté la quantité de mémoire disponible Les soumissions de Job ont commencé à récupérer, et le nombre de messages circulant dans notre système de flux de travail est revenu à des niveaux normaux. À 14h44, nous avons déplacé la page d'état à la surveillance. Les pods du service de configuration de travail ont atteint leurs limites de mémoire et ont redémarré. Nous avons augmenté les allocations de mémoire et le nombre de modules, et le service a récupéré. À 15 h 13, nous avons augmenté le nombre de cas dans nos grappes de Docker de la génération 2 afin de pouvoir composer rapidement avec l'arriéré de travail en attente. Nous avons résolu l'incident à 15 h 21. ### **7 octobre, 18:49 à 20:05: Augmentation des temps d'attente pour les emplois de Docker Gen 2** Nous avons déclaré un nouvel incident à 18h49 après que les temps d'attente de Docker Gen 2 aient augmenté. À 18h51, les ingénieurs ont confirmé qu'une pénurie d'instances disponibles nous empêchait d'en acquérir assez, ce qui soulevait des temps d'attente. Les temps d'attente diffèrent selon la taille des classes de ressources. À 19 h 52, les temps d'attente moyens étaient inférieurs à une heure plus tôt à mesure que la capacité devenait disponible, bien que de brèves pics se soient poursuivis, et nous avons déplacé la page d'état à la surveillance. Nous avons résolu l'incident à 20 h 5. ### **Le 8 octobre : les tâches de machine Linux et de Docker à distance attendent jusqu'à 50 minutes** Nous avons déclaré un incident à 12h48 après avoir vu un grand nombre d'emplois en attente de départ et de longs temps d'attente pour les travaux de machine et Docker à distance. À 12h49, les ingénieurs ont vu que notre fournisseur de cloud ne pouvait pas fournir assez d'instances. Les retards ont continué à grimper au fur et à mesure que nous enquêtions. À 13 h 13, nous avons commencé à examiner la logique qui choisit un type d'instance ou une région différent lorsque notre premier choix n'est pas disponible. À 13h24, nous soupçonnions qu'un défaut dans cette logique nous empêchait d'utiliser d'autres types d'instances dans notre région primaire, donc nous avons désactivé notre région de repli et confirmé la cause du défaut. Les ingénieurs ont commencé à travailler sur une solution et l'ont déployé à 14h49. Le service a commencé à demander d'autres types d'instance et a commencé des machines en grand nombre. À 14h58, la file d'attente d'une machine a baissé régulièrement. Les temps d'attente moyens entre les classes de ressources ont continué de baisser au cours de l'heure suivante, alors que nous avons résorbé l'arriéré d'emplois en attente. À 16h00, la file d'attente des emplois en attente d'une machine dédouanée et le nombre d'emplois en attente sont revenus à la normale. Nous avons déplacé la page d'état à la surveillance à 16h09 et résolu l'incident à 16h35. **Prévention future et amélioration des processus** Nous prenons les mesures suivantes pour renforcer la résilience des temps de démarrage de l'emploi, y compris la diversification de l'offre, la logique de repli et la détection plus précoce. **Nous développons nos régions de calcul.** Dans les incidents du 7 et du 8 octobre, notre fournisseur de cloud n'a pas pu fournir suffisamment de cas dans les régions que nous utilisions. Nous ajoutons de nouvelles régions à notre logique de repli afin de gérer les pics de demande qui dépassent nos régions préférées. **Nous fixons la logique qui choisit un type d'instance différent.** Le 8 octobre, un défaut a empêché la fourniture de la machine d'utiliser d'autres types d'instances dans la même région. Nous avons déployé un correctif pendant l'incident et nous sommes en train de revoir et de remanier cette logique dans son ensemble, avec des tests, de sorte qu'une pénurie d'un type d'instance déplace le travail vers un autre. **Nous développons les types d'instances que nous offrons et garantissons des capacités supplémentaires.** Nous travaillons avec notre fournisseur de cloud pour réserver des capacités supplémentaires dans nos régions existantes, et nous ajoutons des types d'instances sur lesquels les emplois peuvent fonctionner. La demande de calcul à haut rendement augmente dans l'industrie. Nous diversifions nos sources de capacités et nos clients sont donc isolés de la variation de l'offre. **Nous avons ajouté un deuxième groupe de la génération 2 de Docker afin que les éclats de trafic soient répartis entre deux groupes.** Nous ajoutons également des alertes sur la saturation du disque du serveur et sur la rapidité avec laquelle le programmeur place les tâches, et une alerte qui s'allume lorsqu'un serveur démarre sans ses disques rapides en utilisation. Nous avons fait échouer le script de configuration du disque avec une erreur, et nous avons restauré l'expédition des journaux de ces serveurs afin qu'un problème similaire soit visible plus tôt. L'expérience client est notre priorité, et nous nous engageons à améliorer continuellement la fiabilité de nos systèmes pour correspondre à la confiance que nos clients nous accordent. Nous remercions nos clients pour leur patience pendant que notre équipe a travaillé à résoudre ces incidents. Veuillez contacter notre équipe de soutien pour toute question ou préoccupation.

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

1. 7 octobre 2026 à 13:40 UTCinvestigating

   Les clients peuvent connaître des temps d'attente élevés pour les tâches de travail de machine, nous enquêtons sur la cause racine et nous mettrons à jour quand nous en savons plus.

2. 7 octobre 2026 à 13:52 UTCmonitoring

   Nous voyons des signes de reprise et de suivi de la situation.

3. 7 octobre 2026 à 14:06 UTCresolved

   L'incident a été résolu. Merci de votre patience

4. 8 octobre 2026 à 17:55 UTCpostmortem

   Résumé Entre le 1er octobre et le 8 octobre 2026, les clients de CircleCI ont connu cinq incidents distincts dans lesquels des emplois ont attendu plus longtemps que la normale pour commencer, ou ont échoué à démarrer. Trois des incidents ont été causés par la disponibilité limitée de l'instance de notre fournisseur de cloud. L'un a été causé par un problème de configuration dans notre infrastructure de planification, et l'autre par des limites de mémoire sur un service interne, que nous avons soulevé pendant l'incident. * ** 1 octobre 07:57 à 10:24 UTC:** Docker Gen 2 a attendu jusqu'à 30 minutes pour commencer. Un problème de configuration a empêché les serveurs de programmation Gen 2 d'utiliser leurs disques locaux haute performance. Lors d'un éclatement de la circulation, les disques de repli saturés et le placement du travail ont ralenti. * **7 octobre, 13 h 27 à 14 h 06 UTC :** Les travaux de machines ont attendu plus longtemps que la normale parce que nous n'avons pas pu acquérir assez de machines virtuelles de notre fournisseur de cloud. * **7 octobre, 14 h 24 à 15 h 21 UTC :** Certains emplois ont échoué avec une erreur d'infrastructure, et les workflows ont été retardés. Le service qui donne à chaque travail sa configuration au démarrage est épuisé de mémoire et redémarré. * **7 octobre, 18 h 49 à 20 h 05 UTC :** Docker Gen 2 a attendu plus longtemps que la normale car nous n'avons pas pu acquérir suffisamment d'instances de notre fournisseur de cloud. * ** 8 octobre, 12 h 48 à 16 h 00 UTC :** Les travaux de machine Linux et les travaux Docker à distance ont attendu jusqu'à 50 minutes pour démarrer. Notre fournisseur de cloud n'avait pas assez de type d'instance que nous demandons, et un défaut dans la logique qui choisit un type d'instance différent nous a empêchés d'utiliser des alternatives. Les emplois qui ont attendu pendant ces incidents ont été retardés et non perdus. Les clients dont les emplois ont échoué avec une erreur d'infrastructure lors de l'incident du 7 octobre de 14:24 à 15:21 UTC peuvent les réutiliser. Les pages d'état d'origine se trouvent ci-dessous : * [1er octobre - Retards dans le démarrage des emplois du groupe 2 Docker] (https://status.circleci.com/incidents/22mrv46g6n7g) * [7 octobre - Retard dans le démarrage des tâches de la machine] (https://status.circleci.com/incidents/tj6wdnfjwr64) * [7 octobre - Niveau élevé d'infra sur les emplois clients] (https://status.circleci.com/incidents/0z31ldjd8m5v) * [7 octobre - Augmentation des temps d'attente pour Docker Gen2] (https://status.circleci.com/incidents/39rfrjmk5pvd) * [8 octobre - Augmentation des temps d'attente pour les emplois de machines] (https://status.circleci.com/incidents/jn756xtsy4xg) **Contexte** Chaque travail qui fonctionne sur CercleCI a besoin de calcul. D'où vient ce calcul dépend l'exécuteur. Les tâches Docker sont exécutées sur des groupes de serveurs qui planifient les travaux sur une flotte d'instances. Le programmeur est le logiciel sur les serveurs qui décide quelle instance exécute chaque tâche. Au moment de l'incident du 1er octobre, les emplois de Ge 2 Docker étaient occupés par un de ces groupes. Les emplois du groupe 1 Docker sont répartis entre plusieurs grappes. Les tâches de machine, y compris les tâches Docker à distance, obtenir une machine virtuelle dédiée. Un travail Docker distant est traité comme un travail de machine Linux depuis la soumission jusqu'à la fourniture. Notre service de fourniture de machines demande à chaque machine de notre fournisseur de cloud dans l'une des deux régions que nous utilisons normalement pour les travaux de machines. Lorsque le fournisseur ne peut pas fournir le type d'instance que nous demandons, le service tombe en arrière : il demande un type d'instance différent, ou une région différente, d'une liste que nous maintenons. Un emploi attend qu'une machine soit disponible. Quand un travail commence, il demande un service de configuration de travail pour sa configuration. Ce service fonctionne comme un ensemble de pods, qui sont de petites copies du même programme. Si trop de gousses s'arrêtent, les gousses restantes portent plus de charge, et les travaux ne peuvent pas commencer avant que le service se rétablisse. Ces chemins dépendent de trois types de capacité : le débit de nos systèmes de programmation, la fourniture d'instances par notre fournisseur de cloud, ainsi que la mémoire et le nombre de copies des services qui commencent à travailler. Un manque d'emplois fait attendre ou échouer. Ce qui s'est passé \(Toutes les heures UTC\) ** 1er octobre : Docker Gen 2 a retardé les travaux jusqu'à 30 minutes** À 07:44, l'activité disque sur les serveurs qui planifient les emplois de Gen 2 Docker a augmenté à 90% de la capacité et est restée là. À 07h57, le nombre d'emplois de Docker en attente de départ a commencé à augmenter, et les temps d'attente ont augmenté avec. Une alerte automatisée a téléphoné à l'ingénieur de garde à 08h08. Nous avons déclaré un incident à 8 h 42. À 8 h 43, les ingénieurs ont identifié une latence élevée sur les serveurs de programmation. Ils ont d'abord cru que les disques étaient trop lents pour la charge, donc ils ont préparé un changement à un type de disque plus rapide. À 9 h 01, l'équipe s'est entendue sur deux axes de travail : déplacer les serveurs vers des disques plus rapides, et ajouter un deuxième cluster de la génération 2 afin que les tâches se divisent en deux clusters. À 9 h 41, les ingénieurs ont trouvé la cause profonde. Chaque serveur de programmation dispose de disques rapides qui lui sont directement attachés, et le programmeur est censé y conserver ses données de travail. Ces serveurs fonctionnent sur une image du système d'exploitation renforcée par la sécurité, et sur cette image les disques rapides n'étaient pas utilisés. Le planificateur a plutôt écrit ses données pour ralentir les disques attachés au réseau. Le script qui met en place les disques rapides a échoué sans erreur, et une lacune dans la connexion sur ces serveurs a caché l'échec. Le trafic du groupe 2 était également devenu de plus en plus effréné. Les disques plus lents saturés pendant ces rafales, et le programmeur est tombé derrière. Les temps d'attente ont atteint leur point culminant à 9 h 54, lorsque les emplois de la classe de ressources moyennes de la génération 2 ont attendu jusqu'à 30 minutes. À 9h55, les ingénieurs ont appliqué un correctif qui a configuré correctement les disques rapides. À 10h11, le planificateur a commencé à placer des emplois plus rapidement, ce qui a confirmé que les serveurs pouvaient suivre de nouveaux emplois. Les temps d'attente pour le medium de Gen 2 sont tombés à 13 minutes à 10:14, 7 minutes à 10:17 et 1 minute 30 secondes à 10:20. Nous avons déplacé la page d'état à la surveillance à 10 h 24 et résolu l'incident à 10 h 45. À 11 h 20, le deuxième groupe de la génération 2 a commencé à occuper des emplois. ### **Le 7 octobre, 13h27 à 14h06: Augmentation des temps d'attente pour les postes de machines** Nous avons déclaré un incident à 13h27 après avoir vu des files d'attente et des temps d'attente élevés. Nous avons posté à la page de statut à 13:31. À 13h31, les ingénieurs ont vu que nous luttions pour acquérir des machines virtuelles pour des emplois de machines, et que le nombre d'emplois en attente de démarrage était élevé principalement pour des emplois de machines. À 13h34, les temps d'attente étaient élevés entre les exciteurs. À 13h48, les temps d'attente ont commencé à se rétablir à mesure que d'autres machines étaient disponibles, et nous avons résolu l'incident à 14h06. ### **Le 7 octobre, 14h24 à 15h21: Défauts d'emploi et retards de travail** Peu après que l'incident précédent ait été marqué comme résolu, nous avons déclaré un nouvel incident à 14h24 en raison d'une forte baisse du nombre d'emplois soumis à nos systèmes d'exécution. À 14 h 26, les ingénieurs ont vu que les modules du service de configuration de travail redémarraient. Les pods qui redémarrent laissent moins de copies du service pour répondre aux demandes, et les tâches qui ne pouvaient pas récupérer leur configuration après des tentatives répétées ont échoué avec une erreur d'infrastructure. Les flux de travail qui étaient déjà en cours attendaient des mises à jour des emplois qui n'avaient pas commencé. À 14h35, les ingénieurs ont augmenté la quantité de mémoire disponible pour les pods et augmenté le nombre de pods, ce qui a donné au service plus de copies pour partager la charge. Nous avons également augmenté la quantité de mémoire disponible Les soumissions de Job ont commencé à récupérer, et le nombre de messages circulant dans notre système de flux de travail est revenu à des niveaux normaux. À 14h44, nous avons déplacé la page d'état à la surveillance. Les pods du service de configuration de travail ont atteint leurs limites de mémoire et ont redémarré. Nous avons augmenté les allocations de mémoire et le nombre de modules, et le service a récupéré. À 15 h 13, nous avons augmenté le nombre de cas dans nos grappes de Docker de la génération 2 afin de pouvoir composer rapidement avec l'arriéré de travail en attente. Nous avons résolu l'incident à 15 h 21. ### **7 octobre, 18:49 à 20:05: Augmentation des temps d'attente pour les emplois de Docker Gen 2** Nous avons déclaré un nouvel incident à 18h49 après que les temps d'attente de Docker Gen 2 aient augmenté. À 18h51, les ingénieurs ont confirmé qu'une pénurie d'instances disponibles nous empêchait d'en acquérir assez, ce qui soulevait des temps d'attente. Les temps d'attente diffèrent selon la taille des classes de ressources. À 19 h 52, les temps d'attente moyens étaient inférieurs à une heure plus tôt à mesure que la capacité devenait disponible, bien que de brèves pics se soient poursuivis, et nous avons déplacé la page d'état à la surveillance. Nous avons résolu l'incident à 20 h 5. ### **Le 8 octobre : les tâches de machine Linux et de Docker à distance attendent jusqu'à 50 minutes** Nous avons déclaré un incident à 12h48 après avoir vu un grand nombre d'emplois en attente de départ et de longs temps d'attente pour les travaux de machine et Docker à distance. À 12h49, les ingénieurs ont vu que notre fournisseur de cloud ne pouvait pas fournir assez d'instances. Les retards ont continué à grimper au fur et à mesure que nous enquêtions. À 13 h 13, nous avons commencé à examiner la logique qui choisit un type d'instance ou une région différent lorsque notre premier choix n'est pas disponible. À 13h24, nous soupçonnions qu'un défaut dans cette logique nous empêchait d'utiliser d'autres types d'instances dans notre région primaire, donc nous avons désactivé notre région de repli et confirmé la cause du défaut. Les ingénieurs ont commencé à travailler sur une solution et l'ont déployé à 14h49. Le service a commencé à demander d'autres types d'instance et a commencé des machines en grand nombre. À 14h58, la file d'attente d'une machine a baissé régulièrement. Les temps d'attente moyens entre les classes de ressources ont continué de baisser au cours de l'heure suivante, alors que nous avons résorbé l'arriéré d'emplois en attente. À 16h00, la file d'attente des emplois en attente d'une machine dédouanée et le nombre d'emplois en attente sont revenus à la normale. Nous avons déplacé la page d'état à la surveillance à 16h09 et résolu l'incident à 16h35. **Prévention future et amélioration des processus** Nous prenons les mesures suivantes pour renforcer la résilience des temps de démarrage de l'emploi, y compris la diversification de l'offre, la logique de repli et la détection plus précoce. **Nous développons nos régions de calcul.** Dans les incidents du 7 et du 8 octobre, notre fournisseur de cloud n'a pas pu fournir suffisamment de cas dans les régions que nous utilisions. Nous ajoutons de nouvelles régions à notre logique de repli afin de gérer les pics de demande qui dépassent nos régions préférées. **Nous fixons la logique qui choisit un type d'instance différent.** Le 8 octobre, un défaut a empêché la fourniture de la machine d'utiliser d'autres types d'instances dans la même région. Nous avons déployé un correctif pendant l'incident et nous sommes en train de revoir et de remanier cette logique dans son ensemble, avec des tests, de sorte qu'une pénurie d'un type d'instance déplace le travail vers un autre. **Nous développons les types d'instances que nous offrons et garantissons des capacités supplémentaires.** Nous travaillons avec notre fournisseur de cloud pour réserver des capacités supplémentaires dans nos régions existantes, et nous ajoutons des types d'instances sur lesquels les emplois peuvent fonctionner. La demande de calcul à haut rendement augmente dans l'industrie. Nous diversifions nos sources de capacités et nos clients sont donc isolés de la variation de l'offre. **Nous avons ajouté un deuxième groupe de la génération 2 de Docker afin que les éclats de trafic soient répartis entre deux groupes.** Nous ajoutons également des alertes sur la saturation du disque du serveur et sur la rapidité avec laquelle le programmeur place les tâches, et une alerte qui s'allume lorsqu'un serveur démarre sans ses disques rapides en utilisation. Nous avons fait échouer le script de configuration du disque avec une erreur, et nous avons restauré l'expédition des journaux de ces serveurs afin qu'un problème similaire soit visible plus tôt. L'expérience client est notre priorité, et nous nous engageons à améliorer continuellement la fiabilité de nos systèmes pour correspondre à la confiance que nos clients nous accordent. Nous remercions nos clients pour leur patience pendant que notre équipe a travaillé à résoudre ces incidents. Veuillez contacter notre équipe de soutien pour toute question ou préoccupation.

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

1. 6 octobre 2026 à 16:00 UTCinvestigating

   Ce qui est touché Clients utilisant des pipelines et des workflows CircleCI, y compris l'affichage des données de l'interface utilisateur, les notifications sortantes et les webhooks sortants. Que pouvez-vous attendre Retards dans la création des pipelines et dans le démarrage des workflows et des emplois. Le travail, le flux de travail et les données de pipeline peuvent prendre jusqu'à 15 minutes pour apparaître dans l'interface utilisateur. Les notifications et les webhooks sortants sont retardés d'une minute maximum. Prochaine mise à jour Nous fournirons une autre mise à jour dans les 30 minutes ou comme nous avons plus d'informations à partager.

2. 6 octobre 2026 à 16:10 UTCinvestigating

   Depuis 15:47 UTC, les clients peuvent également voir des emplois échoués, en plus des retards précédemment signalés. Nos ingénieurs continuent d'étudier et d'atténuer le problème.

3. 6 octobre 2026 à 16:31 UTCidentified

   À partir de 16h02 UTC, les pipelines échouent entièrement, de sorte qu'aucun nouveau workflow ou travail ne fonctionne à ce stade. Cela s'ajoute aux retards et aux échecs signalés précédemment. Nos ingénieurs continuent de travailler sur l'atténuation du problème, et nous partagerons plus d'informations dès que nous l'avons.

4. 6 octobre 2026 à 16:42 UTCidentified

   À partir de 16h39 UTC, nous commençons à voir la récupération de nouveaux pipelines et workflows soumis, et les emplois commencent à courir à nouveau. Nos ingénieurs continuent de travailler sur la récupération et partageront plus d'informations dès que nous l'avons.

5. 6 octobre 2026 à 17:21 UTCidentified

   Tandis que les pipelines, les workflows et les emplois fonctionnent à nouveau, les clients peuvent continuer à voir des retards plus longs que d'habitude entre les emplois d'un workflow, et les notifications sortantes sont retardées d'environ 1 minute. Les notifications et les mises à jour d'état de votre système de contrôle de version commencent à sortir à nouveau. Nos ingénieurs continuent de travailler à une reprise complète.

6. 6 octobre 2026 à 18:04 UTCidentified

   Les clients continuent de connaître des retards plus longs que d'habitude entre les tâches d'un workflow, ainsi que des retards dans les notifications à l'étranger. Nous vous remercions de votre patience pendant que nos ingénieurs continuent à enquêter et à travailler sur l'atténuation de la question. Nous partagerons une autre mise à jour dans les 30 prochaines minutes, ou plus tôt si plus d'information devient disponible.

7. 6 octobre 2026 à 18:55 UTCidentified

   Les clients continuent de connaître des retards plus longs que d'habitude avant le début des workflows et des travaux, parfois jusqu'à environ 30 minutes. Cette situation est améliorée par rapport à l'incident précédent, mais des retards subsistent. Les retards dans les notifications à l'étranger se sont améliorés. Nous vous remercions de votre patience pendant que nos ingénieurs continuent de travailler pour rétablir les heures normales de début d'emploi. Nous partagerons une autre mise à jour dans les 30 prochaines minutes, ou plus tôt si plus d'information devient disponible.

8. 6 octobre 2026 à 19:16 UTCidentified

   Les clients continuent de subir des retards. La plupart commencent maintenant dans environ 20 minutes, ce qui s'est amélioré par rapport à environ 40 minutes plus tôt dans l'incident. Un très petit nombre de workflows peut avoir attendu plus d'une heure. Nos ingénieurs ont apporté des changements qui ont amélioré la stabilité des services, et le retard restant est dû à un arriéré de travail qui s'est accumulé pendant l'incident. L'arriéré diminue, et nous nous efforçons de l'éliminer plus rapidement. Nous communiquerons davantage d'information au fur et à mesure que les progrès se poursuivront. Nous vous remercions de votre patience pendant que nos ingénieurs travaillent sur l'arriéré. Nous partagerons une autre mise à jour dans les 30 prochaines minutes, ou plus tôt si plus d'information devient disponible.

9. 6 octobre 2026 à 19:51 UTCidentified

   Les retards dans le démarrage des tâches et des emplois continuent de diminuer. La plupart commencent maintenant dans un délai d'environ 10 minutes, ce qui s'est amélioré par rapport à environ 40 minutes plus tôt dans l'incident. Un très petit nombre de workflows peut avoir attendu plus d'une heure. Si votre travail n'a pas commencé, veuillez le refaire. Les retards dans les notifications à l'étranger se sont améliorés. Le retard restant est dû à un arriéré de travail qui s'est accumulé pendant l'incident, et cet arriéré a diminué de plus de la moitié. Nous nous attendons à ce que l'arriéré soit réglé dans environ 15 minutes. Nous partagerons une autre mise à jour une fois qu'elle aura été approuvée, ou dans les 30 prochaines minutes au plus tard.

10. 6 octobre 2026 à 20:13 UTCidentified

    L ' arriéré de retards de travail a été réglé et les flux de travail recommencent sans retard dans les notifications. Cependant, les clients qui utilisent des jobs Docker et Linux dans plusieurs classes de ressources, y compris le moyen, le grand et le 2xlarge gen2, peuvent maintenant voir des jobs attendre dans la file d'attente pendant quelques minutes avant de commencer. Nos ingénieurs continuent de travailler à atténuer ce problème. Si votre travail n'a pas commencé, veuillez le refaire. Nous vous remercions de votre patience pendant que nos ingénieurs travaillent là-dessus. Nous partagerons une autre mise à jour dans les 30 prochaines minutes, ou plus tôt si plus d'information devient disponible.

11. 6 octobre 2026 à 20:31 UTCmonitoring

    Les flux de travail et les emplois commencent normalement, et les temps d'attente pour les emplois Docker et Linux sont revenus à la normale. Nos ingénieurs continuent de surveiller ce problème. Si votre travail n'a pas commencé, veuillez le refaire. Nous vous remercions de votre patience pendant que nos ingénieurs travaillent là-dessus. Nous partagerons une autre mise à jour dans les 30 prochaines minutes, ou plus tôt si plus d'information devient disponible.

12. 6 octobre 2026 à 21:18 UTCresolved

    Entre environ 15 h 30 UTC et 20 h 30 UTC le 6 octobre 2026, les clients ont connu des retards et des défaillances touchant les pipelines, les flux de travail et les emplois. De 16h02 UTC à 16h39 UTC, les pipelines ont échoué et aucun nouveau workflow ou travail n'a pu démarrer. Après la reprise du service, les workflows et les emplois ont continué de commencer avec des retards jusqu'à environ 20h00 UTC. Les temps de démarrage ont atteint en moyenne 40 minutes à leur maximum, et un très petit nombre de workflows ont attendu plus d'une heure. Les notifications et les webhooks sortants ont également été retardés jusqu'à environ 19h00 UTC, généralement d'environ une minute. Comme l'arriéré de travail retardé a été comblé, l'augmentation de la demande qui en a résulté a exercé une pression sur notre capacité d'exécution, ce qui a entraîné d'autres retards pour les emplois Docker et Linux. De 19h45 UTC à 20h30 UTC, ces emplois ont attendu dans la file d'attente plus longtemps que d'habitude avant de commencer. Au sommet, vers 20h05 UTC, les attentes ont atteint environ 8 minutes pour 2xlarge gen2, 6 minutes pour xlarge gen2, et moins de 5 minutes pour quelques autres classes de ressources. Le problème a été résolu et toutes les fonctionnalités touchées sont revenues à la normale. Les clients dont les emplois ont échoué pendant cette fenêtre peuvent réutiliser des emplois affectés. Nous vous remercions de votre patience pendant que notre équipe a travaillé à la mise en place d'un correctif.

13. 7 octobre 2026 à 22:08 UTCpostmortem

    Résumé Le 6 octobre 2026, de 15h30 à 20h30 UTC, les clients de CircleCI ont connu des retards en créant des pipelines et en commençant des workflows et des emplois. De 15h48 à 16h38 UTC, aucun workflow ou travail n'a commencé, et les pipelines déclenchés de 16h02 UTC ont échoué. Des retards intermittents plus courts ont commencé plus tôt, à 13 h 30 UTC. Les données de l'interface utilisateur CircleCI, les notifications et les mises à jour de l'état des commits aux fournisseurs de contrôle de versions ont également été retardées. L'incident a commencé dans la base de données derrière notre service d'orchestration de flux de travail, qui coordonne chaque pipeline, workflow et travail sur CircleCI. La maintenance courante sur les plus grandes tables de la base de données écrivait des journaux de transactions plus rapidement que la base de données ne pouvait les archiver, et les journaux remplissaient le volume de stockage réservé pour eux. Pour éviter que la base de données ne devienne en lecture seule, nos ingénieurs ont déplacé les journaux vers le volume de stockage principal de la base. Ce déménagement a pris la base de données hors ligne pendant 50 minutes. Lorsque la base de données est revenue, elle a travaillé à peu près la moitié de son taux normal jusqu'à ce que nos ingénieurs changent le réglage d'une base de données à 18:19 UTC. Nous avons ensuite réglé l'arriéré et les heures de début d'emploi sont revenues à la normale à 20 h 30 UTC. Les clients dont les travaux ont échoué pendant cette fenêtre peuvent les réutiliser. La page d'état originale peut être trouvée [ici](https://status.circleci.com/incidents/z4hbq8h49j8c). Historique Lorsque vous déclenchez un pipeline, CircleCI le livre à un service d'orchestration de workflow. Ce service suit l'état de chaque workflow et travail, décide quand chaque travail est prêt à courir, et passe les travaux prêts à notre flotte d'exécution. Il conduit également les données de travail que vous voyez dans l'interface utilisateur et les notifications et les états de commit que nous envoyons lorsque le travail prend fin. Le service d'orchestration stocke son état dans une base de données. La base de données écrit chaque changement à un journal de transactions avant de l'appliquer, et elle conserve ces journaux sur un volume de stockage dédié. Il archive les journaux en continu pour qu'il puisse réutiliser cet espace. Si l'archivage tombe derrière et que le volume se remplit, la base de données cesse d'accepter les écrits, et aucun nouveau travail ne peut avancer. La base de données exécute également un processus de maintenance périodique \(autovacuums\) sur chaque table pour garder ses enregistrements internes valides au fil du temps. Sur une très grande table, ce processus lit chaque page de la table et écrit un grand volume de journaux de transactions. Ce qui s'est passé \(Toutes les heures UTC\) À partir de 10h02 le 6 octobre, notre surveillance a soulevé des alertes de courte durée sur les erreurs du service d'orchestration. Chaque alerte a été effacée en 15 minutes environ. Nos ingénieurs avaient déjà vu des alertes aussi brèves, et le système n'a montré aucun autre signe de stress, donc ils ont suivi le runbook à chaque fois, et chaque alerte s'est dégagée sur sa propre voie et a également commencé à travailler pour rendre les alertes moins sensibles. Environ 12h40, ainsi que la charge de travail régulière qui génère ses propres journaux de transactions, le processus de maintenance sur plusieurs des plus grandes tables de la base de données a commencé à écrire des journaux de transactions supplémentaires plus rapidement que la base de données ne pouvait les archiver, et le volume de journal a commencé à remplir. À 13 h 30, le service d'orchestration a commencé à ralentir. Jusqu'à 15 h 30, certains pipelines et travaux ont pris plus de temps à démarrer, en courtes explosions. À 13h35, notre surveillance a de nouveau alerté, cette fois-ci en même temps que les alertes de plusieurs autres services. Les ingénieurs de l'infrastructure ont suivi les carnets d'alerte, en éliminant certaines des alertes. Les alertes sont revenues vers 14h30 et après enquête, nous avons déclaré un incident à 14h54. Nous aurions dû reconnaître la combinaison des alertes plus tôt, et nous avons abordé la façon dont nous fixons cela ci-dessous. Après avoir déclaré l'incident, nos ingénieurs ont tracé le ralentissement au processus de maintenance \(anti-wraparound autovacuum\). La base de données redémarre automatiquement ce processus s'il est annulé, de sorte que nos ingénieurs ont modifié ses paramètres pour l'aider à terminer plus rapidement. À 15 h 30, les retards étaient constants, et certains emplois commençaient à échouer. À 15 h 43, le volume du journal des transactions était presque complet. Si elle était remplie, la base de données cesserait d'accepter les écrits et aucun travail ne pourrait être exécuté. Nos ingénieurs ont décidé de déplacer les journaux de transaction sur le volume de stockage principal de la base de données, qui avait beaucoup d'espace libre. Le déménagement exigeait que la base de données soit déconnectée, et nous ne pouvions prédire à l'avance combien de temps cela prendrait. Le déménagement a commencé à 15h47. De 15:48 à 16:38, le service d'orchestration ne pouvait traiter aucune œuvre. Les clients pouvaient encore déclencher des pipelines, mais aucun workflow ou travail n'a commencé, et à partir de 16:02 pipelines nouvellement déclenchés a échoué. Nous avons posté sur notre page de statut à 15:58 et l'avons élevé à une panne majeure à 16:20. Pendant que la base de données était hors ligne, nos ingénieurs ont préparé une base de données de remplacement comme un retour. La base de données originale est revenue en premier, donc nous l'avons gardée en service. À 16 h 38, la base de données est revenue en ligne et le travail a repris. Avec les journaux de transactions et les données régulières partageant maintenant le même stockage, la base de données a fonctionné plus lentement qu'auparavant. De 16:38 à 18:19, le service d'orchestration a traité le travail à peu près la moitié de son tarif normal, et les travaux ont attendu des dizaines de minutes pour commencer, jusqu'à environ 50 minutes au plus. Pendant ce temps, la base de données a dû terminer l'archivage de son arriéré de journaux de transactions avant de pouvoir les ramener à un volume dédié. Nous avons également étudié et mis en œuvre plusieurs modifications de paramètres de base de données pour arrêter d'autres opérations de maintenance depuis le début et préparé des moyens pour réduire le travail atteignant le service. Avec la base de données de remplacement, nous avons également préparé une pile complète du service pendant cette période afin que nous puissions passer à elle au risque de perte de données et avons opté contre ce mouvement. À 18 h 19, nos ingénieurs ont modifié le réglage d'une base de données pour réduire le temps d'attente de chaque écriture. La vitesse de traitement s'est rétablie, et l'arriéré a commencé à se résorber. Pour l'effacer plus rapidement, nous avons ajouté une base de données et une capacité de serveur aux systèmes qui transmettent les tâches à notre flotte d'exécution. Vers 19h55, de nouveaux emplois ont repris à temps. L'arriéré a ensuite atteint notre flotte d'exécution. De 19 h 49 à 20 h 30, certains emplois de Docker dans des classes de ressources plus importantes ont attendu jusqu'à environ 10 minutes pour commencer pendant que la capacité augmentait. À 20 h 30, les heures de début du travail étaient de retour à la normale. Nous avons déplacé la page d'état à la surveillance à 20 h 32 et résolu l'incident à 21 h 19. Environ 3 500 emplois ont échoué pendant l'incident. Les clients peuvent réorganiser ces emplois. Nous n'avons trouvé aucune preuve que CercleCI ait travaillé plus d'une fois. Les clients qui recourent à un workflow alors que l'exécution originale était encore retardée ont peut-être vu les deux versions terminées. Les clients du plan annuel peuvent travailler avec leur équipe de compte pour examiner l'utilisation. ## Prévention future et amélioration des processus Nous prenons les mesures suivantes pour prévenir une récidive et améliorer notre temps de réponse : **Nous ajoutons des alertes sur les conditions qui ont causé cet incident.** Notre surveillance a capté le ralentissement, mais nous n'avions aucune alerte sur le volume total du journal des transactions ni sur la distance parcourue par l'archivage. Nous ajoutons des alertes sur les deux, ainsi que des alertes sur la maintenance de la base de données qui les conduit, afin que nous puissions agir plus tôt. Nous revoyons également toutes nos alertes pour nous assurer que les alertes bruyantes ou sensibles ne cachent pas les vrais problèmes. **Nous accordons comment le processus de maintenance \(autovacuum\) fonctionne sur notre base de données.** Nous examinons la fréquence et l'agressivité avec lesquelles les autovacuums fonctionnent sur notre base de données. Nous suivons également la taille de ces tables au fil du temps afin qu'elles restent dans des limites sûres. **Nous supprimons le goulot d'étranglement du journal des transactions.** Tous les écrits du service d'orchestration passent actuellement par une base de données et un journal des transactions, donc quand ce journal est tombé en arrière, chaque pipeline, flux de travail et travail ralenti avec elle. Nous évaluons deux approches : diviser le service en plusieurs instances de base de données, chacune avec son propre journal des transactions, et le déplacer vers une base de données distribuée construite pour diffuser les écrits sur de nombreux nœuds. L'une ou l'autre approche limiterait l'effet d'un retard à une partie de la charge de travail. **Nous faisons attendre nos systèmes que le service d'orchestration se rétablisse.** Pendant l'incident, certains emplois ont échoué parce que nos systèmes ont abandonné après avoir réessayé. Nous travaillons à changer ce comportement. **Nous améliorons les mises à jour de notre page de statut lors de longs incidents.** Les clients nous ont dit que nos premières mises à jour ne donnaient pas assez de détails. Nous mettons à jour nos lignes directrices afin que les mises à jour incluent l'impact et le moment précis plus tôt. (en milliers de dollars) L'expérience client est notre priorité, et nous nous engageons à améliorer continuellement la fiabilité de nos systèmes pour correspondre à la confiance que nos clients nous accordent. Nous remercions nos clients pour leur patience pendant que notre équipe a travaillé à résoudre cet incident. Veuillez contacter notre équipe de soutien pour toute question ou préoccupation.

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

1. 1 octobre 2026 à 09:06 UTCinvestigating

   Les clients peuvent rencontrer des retards dans le démarrage des emplois Docker Gen 2. Nous nous efforçons d'augmenter le débit du système pour l'accueillir.

2. 1 octobre 2026 à 09:47 UTCidentified

   Nous avons identifié la cause profonde et nous travaillons activement sur une solution. Merci de votre patience.

3. 1 octobre 2026 à 10:13 UTCidentified

   Une réparation a été déployée et nous commençons à observer la récupération.

4. 1 octobre 2026 à 10:24 UTCmonitoring

   Nous voyons les temps d'attente revenir à des niveaux normaux, et continuons à surveiller.

5. 1 octobre 2026 à 10:45 UTCresolved

   Cet incident a été résolu.

6. 9 octobre 2026 à 22:36 UTCpostmortem

   Résumé Entre le 1er octobre et le 8 octobre 2026, les clients de CircleCI ont connu cinq incidents distincts dans lesquels des emplois ont attendu plus longtemps que la normale pour commencer, ou ont échoué à démarrer. Trois des incidents ont été causés par la disponibilité limitée de l'instance de notre fournisseur de cloud. L'un a été causé par un problème de configuration dans notre infrastructure de planification, et l'autre par des limites de mémoire sur un service interne, que nous avons soulevé pendant l'incident. * ** 1 octobre 07:57 à 10:24 UTC:** Docker Gen 2 a attendu jusqu'à 30 minutes pour commencer. Un problème de configuration a empêché les serveurs de programmation Gen 2 d'utiliser leurs disques locaux haute performance. Lors d'un éclatement de la circulation, les disques de repli saturés et le placement du travail ont ralenti. * **7 octobre, 13 h 27 à 14 h 06 UTC :** Les travaux de machines ont attendu plus longtemps que la normale parce que nous n'avons pas pu acquérir assez de machines virtuelles de notre fournisseur de cloud. * **7 octobre, 14 h 24 à 15 h 21 UTC :** Certains emplois ont échoué avec une erreur d'infrastructure, et les workflows ont été retardés. Le service qui donne à chaque travail sa configuration au démarrage est épuisé de mémoire et redémarré. * **7 octobre, 18 h 49 à 20 h 05 UTC :** Docker Gen 2 a attendu plus longtemps que la normale car nous n'avons pas pu acquérir suffisamment d'instances de notre fournisseur de cloud. * ** 8 octobre, 12 h 48 à 16 h 00 UTC :** Les travaux de machine Linux et les travaux Docker à distance ont attendu jusqu'à 50 minutes pour démarrer. Notre fournisseur de cloud n'avait pas assez de type d'instance que nous demandons, et un défaut dans la logique qui choisit un type d'instance différent nous a empêchés d'utiliser des alternatives. Les emplois qui ont attendu pendant ces incidents ont été retardés et non perdus. Les clients dont les emplois ont échoué avec une erreur d'infrastructure lors de l'incident du 7 octobre de 14:24 à 15:21 UTC peuvent les réutiliser. Les pages d'état d'origine se trouvent ci-dessous : * [1er octobre - Retards dans le démarrage des emplois du groupe 2 Docker] (https://status.circleci.com/incidents/22mrv46g6n7g) * [7 octobre - Retard dans le démarrage des tâches de la machine] (https://status.circleci.com/incidents/tj6wdnfjwr64) * [7 octobre - Niveau élevé d'infra sur les emplois clients] (https://status.circleci.com/incidents/0z31ldjd8m5v) * [7 octobre - Augmentation des temps d'attente pour Docker Gen2] (https://status.circleci.com/incidents/39rfrjmk5pvd) * [8 octobre - Augmentation des temps d'attente pour les emplois de machines] (https://status.circleci.com/incidents/jn756xtsy4xg) **Contexte** Chaque travail qui fonctionne sur CercleCI a besoin de calcul. D'où vient ce calcul dépend l'exécuteur. Les tâches Docker sont exécutées sur des groupes de serveurs qui planifient les travaux sur une flotte d'instances. Le programmeur est le logiciel sur les serveurs qui décide quelle instance exécute chaque tâche. Au moment de l'incident du 1er octobre, les emplois de Ge 2 Docker étaient occupés par un de ces groupes. Les emplois du groupe 1 Docker sont répartis entre plusieurs grappes. Les tâches de machine, y compris les tâches Docker à distance, obtenir une machine virtuelle dédiée. Un travail Docker distant est traité comme un travail de machine Linux depuis la soumission jusqu'à la fourniture. Notre service de fourniture de machines demande à chaque machine de notre fournisseur de cloud dans l'une des deux régions que nous utilisons normalement pour les travaux de machines. Lorsque le fournisseur ne peut pas fournir le type d'instance que nous demandons, le service tombe en arrière : il demande un type d'instance différent, ou une région différente, d'une liste que nous maintenons. Un emploi attend qu'une machine soit disponible. Quand un travail commence, il demande un service de configuration de travail pour sa configuration. Ce service fonctionne comme un ensemble de pods, qui sont de petites copies du même programme. Si trop de gousses s'arrêtent, les gousses restantes portent plus de charge, et les travaux ne peuvent pas commencer avant que le service se rétablisse. Ces chemins dépendent de trois types de capacité : le débit de nos systèmes de programmation, la fourniture d'instances par notre fournisseur de cloud, ainsi que la mémoire et le nombre de copies des services qui commencent à travailler. Un manque d'emplois fait attendre ou échouer. Ce qui s'est passé \(Toutes les heures UTC\) ** 1er octobre : Docker Gen 2 a retardé les travaux jusqu'à 30 minutes** À 07:44, l'activité disque sur les serveurs qui planifient les emplois de Gen 2 Docker a augmenté à 90% de la capacité et est restée là. À 07h57, le nombre d'emplois de Docker en attente de départ a commencé à augmenter, et les temps d'attente ont augmenté avec. Une alerte automatisée a téléphoné à l'ingénieur de garde à 08h08. Nous avons déclaré un incident à 8 h 42. À 8 h 43, les ingénieurs ont identifié une latence élevée sur les serveurs de programmation. Ils ont d'abord cru que les disques étaient trop lents pour la charge, donc ils ont préparé un changement à un type de disque plus rapide. À 9 h 01, l'équipe s'est entendue sur deux axes de travail : déplacer les serveurs vers des disques plus rapides, et ajouter un deuxième cluster de la génération 2 afin que les tâches se divisent en deux clusters. À 9 h 41, les ingénieurs ont trouvé la cause profonde. Chaque serveur de programmation dispose de disques rapides qui lui sont directement attachés, et le programmeur est censé y conserver ses données de travail. Ces serveurs fonctionnent sur une image du système d'exploitation renforcée par la sécurité, et sur cette image les disques rapides n'étaient pas utilisés. Le planificateur a plutôt écrit ses données pour ralentir les disques attachés au réseau. Le script qui met en place les disques rapides a échoué sans erreur, et une lacune dans la connexion sur ces serveurs a caché l'échec. Le trafic du groupe 2 était également devenu de plus en plus effréné. Les disques plus lents saturés pendant ces rafales, et le programmeur est tombé derrière. Les temps d'attente ont atteint leur point culminant à 9 h 54, lorsque les emplois de la classe de ressources moyennes de la génération 2 ont attendu jusqu'à 30 minutes. À 9h55, les ingénieurs ont appliqué un correctif qui a configuré correctement les disques rapides. À 10h11, le planificateur a commencé à placer des emplois plus rapidement, ce qui a confirmé que les serveurs pouvaient suivre de nouveaux emplois. Les temps d'attente pour le medium de Gen 2 sont tombés à 13 minutes à 10:14, 7 minutes à 10:17 et 1 minute 30 secondes à 10:20. Nous avons déplacé la page d'état à la surveillance à 10 h 24 et résolu l'incident à 10 h 45. À 11 h 20, le deuxième groupe de la génération 2 a commencé à occuper des emplois. ### **Le 7 octobre, 13h27 à 14h06: Augmentation des temps d'attente pour les postes de machines** Nous avons déclaré un incident à 13h27 après avoir vu des files d'attente et des temps d'attente élevés. Nous avons posté à la page de statut à 13:31. À 13h31, les ingénieurs ont vu que nous luttions pour acquérir des machines virtuelles pour des emplois de machines, et que le nombre d'emplois en attente de démarrage était élevé principalement pour des emplois de machines. À 13h34, les temps d'attente étaient élevés entre les exciteurs. À 13h48, les temps d'attente ont commencé à se rétablir à mesure que d'autres machines étaient disponibles, et nous avons résolu l'incident à 14h06. ### **Le 7 octobre, 14h24 à 15h21: Défauts d'emploi et retards de travail** Peu après que l'incident précédent ait été marqué comme résolu, nous avons déclaré un nouvel incident à 14h24 en raison d'une forte baisse du nombre d'emplois soumis à nos systèmes d'exécution. À 14 h 26, les ingénieurs ont vu que les modules du service de configuration de travail redémarraient. Les pods qui redémarrent laissent moins de copies du service pour répondre aux demandes, et les tâches qui ne pouvaient pas récupérer leur configuration après des tentatives répétées ont échoué avec une erreur d'infrastructure. Les flux de travail qui étaient déjà en cours attendaient des mises à jour des emplois qui n'avaient pas commencé. À 14h35, les ingénieurs ont augmenté la quantité de mémoire disponible pour les pods et augmenté le nombre de pods, ce qui a donné au service plus de copies pour partager la charge. Nous avons également augmenté la quantité de mémoire disponible Les soumissions de Job ont commencé à récupérer, et le nombre de messages circulant dans notre système de flux de travail est revenu à des niveaux normaux. À 14h44, nous avons déplacé la page d'état à la surveillance. Les pods du service de configuration de travail ont atteint leurs limites de mémoire et ont redémarré. Nous avons augmenté les allocations de mémoire et le nombre de modules, et le service a récupéré. À 15 h 13, nous avons augmenté le nombre de cas dans nos grappes de Docker de la génération 2 afin de pouvoir composer rapidement avec l'arriéré de travail en attente. Nous avons résolu l'incident à 15 h 21. ### **7 octobre, 18:49 à 20:05: Augmentation des temps d'attente pour les emplois de Docker Gen 2** Nous avons déclaré un nouvel incident à 18h49 après que les temps d'attente de Docker Gen 2 aient augmenté. À 18h51, les ingénieurs ont confirmé qu'une pénurie d'instances disponibles nous empêchait d'en acquérir assez, ce qui soulevait des temps d'attente. Les temps d'attente diffèrent selon la taille des classes de ressources. À 19 h 52, les temps d'attente moyens étaient inférieurs à une heure plus tôt à mesure que la capacité devenait disponible, bien que de brèves pics se soient poursuivis, et nous avons déplacé la page d'état à la surveillance. Nous avons résolu l'incident à 20 h 5. ### **Le 8 octobre : les tâches de machine Linux et de Docker à distance attendent jusqu'à 50 minutes** Nous avons déclaré un incident à 12h48 après avoir vu un grand nombre d'emplois en attente de départ et de longs temps d'attente pour les travaux de machine et Docker à distance. À 12h49, les ingénieurs ont vu que notre fournisseur de cloud ne pouvait pas fournir assez d'instances. Les retards ont continué à grimper au fur et à mesure que nous enquêtions. À 13 h 13, nous avons commencé à examiner la logique qui choisit un type d'instance ou une région différent lorsque notre premier choix n'est pas disponible. À 13h24, nous soupçonnions qu'un défaut dans cette logique nous empêchait d'utiliser d'autres types d'instances dans notre région primaire, donc nous avons désactivé notre région de repli et confirmé la cause du défaut. Les ingénieurs ont commencé à travailler sur une solution et l'ont déployé à 14h49. Le service a commencé à demander d'autres types d'instance et a commencé des machines en grand nombre. À 14h58, la file d'attente d'une machine a baissé régulièrement. Les temps d'attente moyens entre les classes de ressources ont continué de baisser au cours de l'heure suivante, alors que nous avons résorbé l'arriéré d'emplois en attente. À 16h00, la file d'attente des emplois en attente d'une machine dédouanée et le nombre d'emplois en attente sont revenus à la normale. Nous avons déplacé la page d'état à la surveillance à 16h09 et résolu l'incident à 16h35. **Prévention future et amélioration des processus** Nous prenons les mesures suivantes pour renforcer la résilience des temps de démarrage de l'emploi, y compris la diversification de l'offre, la logique de repli et la détection plus précoce. **Nous développons nos régions de calcul.** Dans les incidents du 7 et du 8 octobre, notre fournisseur de cloud n'a pas pu fournir suffisamment de cas dans les régions que nous utilisions. Nous ajoutons de nouvelles régions à notre logique de repli afin de gérer les pics de demande qui dépassent nos régions préférées. **Nous fixons la logique qui choisit un type d'instance différent.** Le 8 octobre, un défaut a empêché la fourniture de la machine d'utiliser d'autres types d'instances dans la même région. Nous avons déployé un correctif pendant l'incident et nous sommes en train de revoir et de remanier cette logique dans son ensemble, avec des tests, de sorte qu'une pénurie d'un type d'instance déplace le travail vers un autre. **Nous développons les types d'instances que nous offrons et garantissons des capacités supplémentaires.** Nous travaillons avec notre fournisseur de cloud pour réserver des capacités supplémentaires dans nos régions existantes, et nous ajoutons des types d'instances sur lesquels les emplois peuvent fonctionner. La demande de calcul à haut rendement augmente dans l'industrie. Nous diversifions nos sources de capacités et nos clients sont donc isolés de la variation de l'offre. **Nous avons ajouté un deuxième groupe de la génération 2 de Docker afin que les éclats de trafic soient répartis entre deux groupes.** Nous ajoutons également des alertes sur la saturation du disque du serveur et sur la rapidité avec laquelle le programmeur place les tâches, et une alerte qui s'allume lorsqu'un serveur démarre sans ses disques rapides en utilisation. Nous avons fait échouer le script de configuration du disque avec une erreur, et nous avons restauré l'expédition des journaux de ces serveurs afin qu'un problème similaire soit visible plus tôt. L'expérience client est notre priorité, et nous nous engageons à améliorer continuellement la fiabilité de nos systèmes pour correspondre à la confiance que nos clients nous accordent. Nous remercions nos clients pour leur patience pendant que notre équipe a travaillé à résoudre ces incidents. Veuillez contacter notre équipe de soutien pour toute question ou préoccupation.

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

1. 23 septembre 2026 à 18:13 UTCidentified

   Les clients peuvent rencontrer des retards dans les nouvelles inscriptions et prévoir des changements qui se reflètent dans leur compte.

2. 23 septembre 2026 à 20:06 UTCresolved

   Cet incident a été résolu.

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

1. 21 septembre 2026 à 16:22 UTCinvestigating

   Les clients peuvent rencontrer des retards dans le démarrage des travaux sur Linux Machine. Nous enquêtons.

2. 21 septembre 2026 à 16:48 UTCmonitoring

   Temps d'attente des tâches pour Linux Machine sont de retour à la normale.

3. 21 septembre 2026 à 17:09 UTCresolved

   This incident has been resolved.

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

1. 16 septembre 2026 à 14:55 UTCinvestigating

   Nous enquêtons sur un retard dans la disponibilité des données sur les pipelines. Les pipelines fonctionnent toujours, mais les données les concernant peuvent être retardées dans l'interface utilisateur ou l'API.

2. 16 septembre 2026 à 15:29 UTCidentified

   Nous avons identifié le problème et nous travaillons actuellement à une remise en état. Merci de votre patience.

3. 16 septembre 2026 à 17:34 UTCidentified

   Les données sur les pipelines sont maintenant disponibles normalement, à l'exception des résultats des essais, qui peuvent encore être retardés. Nous continuons à travailler sur cette question, merci de votre patience.

4. 16 septembre 2026 à 18:22 UTCmonitoring

   Toutes les données sur les pipelines sont maintenant disponibles normalement. Nous continuerons de surveiller le rétablissement.

5. 16 septembre 2026 à 19:30 UTCresolved

   Cet incident a été résolu.

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

1. 15 septembre 2026 à 14:42 UTCinvestigating

   Nous assistons actuellement à un retard dans la présentation des données sur les pipelines dans l'interface utilisateur.

2. 15 septembre 2026 à 15:14 UTCidentified

   Nous commençons à voir un certain rétablissement.

3. 15 septembre 2026 à 17:02 UTCresolved

   L'incident ayant une incidence sur les données du pipeline de l'assurance-chômage a maintenant été résolu. Nous vous remercions de votre patience pendant que nos ingénieurs ont travaillé à réduire les retards.

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

1. 14 septembre 2026 à 11:59 UTCinvestigating

   En raison de l'augmentation des erreurs de réseau et des retards, nous assistons à une augmentation des temps d'attente pour les emplois macOS. Nous enquêtons avec notre hébergeur macOS.

2. 14 septembre 2026 à 12:36 UTCinvestigating

   Les temps d'attente pour les emplois macOS diminuent et nous continuons à enquêter.

3. 14 septembre 2026 à 12:48 UTCmonitoring

   Notre fournisseur d'hébergement macOS a mis en place une atténuation et nous avons vu des latences améliorées. Nous continuerons de surveiller.

4. 14 septembre 2026 à 12:59 UTCresolved

   Les temps d'attente pour les emplois macOS sont de retour à la normale.

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

1. 10 septembre 2026 à 20:25 UTCidentified

   Un petit nombre de clients peuvent voir des erreurs ou ne pas être en mesure de charger la page des pipelines pour des projets avec des avertissements de configuration dépréciés, lors de l'utilisation de la vue des pipelines classiques. Les clients sur la vue des nouveaux pipelines ne sont pas touchés. Nous avons identifié la cause et déployé une solution.

2. 10 septembre 2026 à 20:25 UTCmonitoring

   Un correctif a été mis en place et nous suivons les résultats.

3. 10 septembre 2026 à 20:26 UTCresolved

   Cet incident a été résolu. Un petit nombre de clients qui ont créé des pipelines entre 18:53 UTC et 19:24 UTC qui contenaient config en utilisant la syntaxe de config dépréciée aura vu leurs travaux de type build ne démarrent pas. Les clients dont le travail ou les pipelines ont échoué peuvent les réutiliser.

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

1. 4 septembre 2026 à 15:16 UTCinvestigating

   Nous avons détecté des problèmes de réseau affectant notre infrastructure Mac. Nous enquêtons et fournirons des mises à jour sous peu. Les clients peuvent faire la queue pendant cette période.

2. 4 septembre 2026 à 15:43 UTCidentified

   Nous avons identifié le problème de réseautage avec notre fournisseur d'infrastructure Mac et travaillons avec eux pour résoudre le problème. Nous commençons à voir une certaine reprise, mais nous nous attendons à ce que les clients voient encore une certaine file d'attente. On se revoit bientôt.

3. 4 septembre 2026 à 16:19 UTCmonitoring

   Notre fournisseur d'infrastructure Mac a appliqué une correction à ce problème de réseau et nous voyons les temps de queue revenir à la normale. Nous allons continuer à surveiller les choses encore un peu. On se revoit bientôt.

4. 4 septembre 2026 à 16:55 UTCresolved

   Nous n'avons vu aucun autre impact sur les temps d'attente et tout est revenu à la normale. Nous apprécions votre patience pendant que nous avons travaillé pour résoudre et surveiller cette question.

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

1. 26 août 2026 à 15:43 UTCidentified

   Les clients peuvent rencontrer des erreurs intermittentes lors de la consultation des interfaces d'utilisation du plan ou des API d'utilisation du plan. Nous avons identifié le problème et nous travaillons activement à atténuer ces erreurs.

2. 26 août 2026 à 16:04 UTCmonitoring

   Nous avons atténué le problème avec les API d'utilisation du plan et les pages pertinentes de l'interface utilisateur sont chargées correctement.

3. 26 août 2026 à 16:10 UTCresolved

   Cet incident a été résolu.

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

1. 25 août 2026 à 23:20 UTCresolved

   Entre 19h49 UTC et 21h07 UTC le 25 août 2026, les clients qui tentaient de se connecter à CircleCI en utilisant GitHub ont été incapables de se connecter et ont reçu une erreur de GitHub indiquant que l'URL de rappel était invalide. Les clients déjà connectés n'étaient pas touchés. Le problème a été résolu et la connexion GitHub fonctionne normalement. Nous vous remercions de votre patience pendant que notre équipe a travaillé à la mise en place d'un correctif.

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

1. 17 août 2026 à 21:06 UTCidentified

   La cause du problème a été identifiée et nous sommes en train de le résoudre.

2. 17 août 2026 à 21:36 UTCmonitoring

   Un correctif a été mis en place et nous suivons les résultats.

3. 17 août 2026 à 21:37 UTCresolved

   Insights données est une fois de plus bonne. Merci de votre patience.

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