Historique des pannes de Circle Ci

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.

1. 17 août 2026 à 14:04 UTCidentified

   GitHub a signalé un incident qui a un impact sur le déclenchement du pipeline CircleCI et l'enregistrement : https://www.githubstatus.com/incidents/zkxwbgr0cnmx Les emplois qui sont dans les vols sont en cours, mais le rapport d'état à GitHub Pull Requests peut échouer.

2. 17 août 2026 à 14:25 UTCidentified

   Nous continuons de voir des taux d'erreur élevés sur les API GitHub et réduit le trafic webhook. Nous continuerons de fournir des mises à jour à mesure que de plus amples renseignements seront disponibles.

3. 17 août 2026 à 15:49 UTCidentified

   Nous continuons à voir des taux d'erreur élevés sur les API de GitHub et réduit le trafic webhook. Les clients utilisant GitHub comme VCS peuvent ainsi avoir un impact sur leur plateforme CircleCI. Ceci est directement lié à l'incident GitHub est l'expérience: https://www.githubstatus.com/incidents/zkxwbgr0cnmx Nous fournirons des mises à jour à mesure que de plus amples renseignements seront disponibles.

4. 17 août 2026 à 16:22 UTCmonitoring

   Nous avons commencé à observer une meilleure stabilité dans les API GitHub. Nous continuerons de surveiller leur rétablissement.

5. 17 août 2026 à 17:01 UTCmonitoring

   Les taux d'erreur de l'API GitHub et les latences semblent avoir récupéré. Nous continuerons de surveiller.

6. 17 août 2026 à 17:23 UTCmonitoring

   Certaines API de GitHub sont encore dégradées, ce qui entraîne un petit nombre de défaillances liées aux mises à jour de l'état de commit et au traitement des crochets. Nous continuerons de faire de notre mieux pour atténuer ces effets.

7. 17 août 2026 à 19:05 UTCresolved

   Les API de GitHub semblent fonctionner normalement.

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

1. 15 août 2026 à 13:58 UTCresolved

   À la suite de l'entretien prévu qui s'est terminé à 13 h UTC le 15 août, un certain impact sur le traitement des emplois a continué pendant environ 30 minutes au-delà de la fenêtre annoncée. Certains clients ont continué de constater des retards dans le démarrage des emplois, ainsi qu'un petit nombre d'emplois qui échouent avec des erreurs d'infrastructure, jusqu'à environ 13h30 UTC. Cela a été résolu et le traitement des tâches est revenu à 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 œuvre d'un correctif et nous vous excusons de tout inconvénient que l'impact prolongé pourrait avoir causé.

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

1. 12 août 2026 à 16:33 UTCidentified

   GitHub connaît actuellement une dégradation des services (https://www.githubstatus.com/incidents/76t89hbfb09h). Les clients qui utilisent GitHub comme leur VCS peuvent avoir un impact sur leur expérience de plate-forme CircleCI, impactant la caisse et les flux de travail. Nous fournirons une autre mise à jour car nous avons plus d'informations à partager. Merci de votre patience.

2. 12 août 2026 à 16:43 UTCresolved

   The issue impacting customers who use GitHub as their VCS while GitHub was undergoing a service degradation (https://www.githubstatus.com/incidents/76t89hbfb09h) has now been resolved. GitHub has resolved the underlying issue and the affected functionality has returned to normal. We thank you for your patience.

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

1. 11 août 2026 à 17:42 UTCresolved

   Between 13:50 UTC and approximately 17:30 UTC on August 11, 2026, some customers experienced delays of up to an hour in pipeline status updates and in notification delivery. Between 16:40 UTC and 17:00 UTC within that same window, a small number of customers also saw newly created pipelines fail to process, appearing in an errored state in the UI and API. The issue has been resolved and all affected functionality has returned to normal. Customers whose pipelines errored during that window can retrigger them. We thank you for your patience while our team worked on implementing a fix.

1. 6 août 2026 à 13:06 UTCinvestigating

   Les données de l'API d'utilisation sont retardées pour 8/5/2026. Toutes les données antérieures demeurent disponibles. Nous enquêtons. Merci de votre patience.

2. 6 août 2026 à 15:06 UTCidentified

   The issue has been identified and a fix is in progress.

3. 6 août 2026 à 19:33 UTCmonitoring

   A fix is in place and is being monitored. Thanks for your patience.

4. 6 août 2026 à 19:54 UTCresolved

   The Usage API issue has been resolved. Data has been loaded for yesterday, 8/5/2026. We appreciate your patience.

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

1. 5 août 2026 à 16:58 UTCinvestigating

   Nous constatons un problème avec le service Insights où les données des dernières 24 heures sont en retard. Nous enquêtons.

2. 5 août 2026 à 17:46 UTCinvestigating

   We are continuing to investigate and will update as we know more.

3. 5 août 2026 à 18:25 UTCidentified

   We have identified the issue, and are working with our upstream provider to resolve it now.

4. 5 août 2026 à 21:01 UTCresolved

   The upstream issue has been resolved, and the insights data from the last 24 hours has caught up. Thank you for your patience.

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

1. 4 août 2026 à 19:27 UTCinvestigating

   We are experiencing increased queue times for Windows, Android, and GPU jobs due to capacity constraints with a third-party infrastructure provider. Jobs will continue to be processed but may take longer than usual to start. Thank you for your patience while our engineers work to resolve this.

2. 4 août 2026 à 19:59 UTCmonitoring

   We're starting to see queue times slowly recovering. We'll be monitoring this situation, we appreciate your patience.

3. 4 août 2026 à 20:33 UTCmonitoring

   Queue times continue to gradually recover with our third-party infrastructure provider, though we've seen a slight uptick in the last 30 mins. We're keeping an eye on this and will keep you updated as things get back to normal. Again, thank you for your patience.

4. 4 août 2026 à 21:16 UTCmonitoring

   Queue times for both Android and Windows jobs, which had been recovering, have started to rise again. This continues to be related to capacity constraints with our third-party infrastructure provider. We'll continue to monitor and provide updates at least every 30 minutes. We appreciate your patience.

5. 4 août 2026 à 21:46 UTCmonitoring

   Queue times for both Android and Windows jobs continue to be volatile, with sharp swings up and down. This remains related to capacity constraints with our third-party infrastructure provider. Our team will continue to monitor and provide updates at least every 30 minutes. We appreciate your patience.

6. 4 août 2026 à 22:20 UTCmonitoring

   Queue times for both Android and Windows jobs, affected by capacity constraints with our third-party infrastructure provider, have been recovering significantly for the last half hour. We're continuing to monitor for a bit longer to confirm they return to normal levels. We appreciate your patience.

7. 4 août 2026 à 23:40 UTCresolved

   Queue times for Android and Windows jobs have reduced significantly over the last hour. You may still notice brief, isolated queuing at times, but this is no longer at incident-level impact. This was related to capacity constraints with a third-party infrastructure provider. We thank you for your patience while we monitored the situation. If you have any issues, please reach out to our Support team.

1. 24 juillet 2026 à 16:35 UTCidentified

   GitHub connaît actuellement une dégradation des services (https://www.githubstatus.com/incidents/yjysg0xrl67m). Les clients qui utilisent GitHub comme leur VCS peuvent avoir un impact sur leur expérience de plate-forme CircleCI, impactant la caisse et les flux de travail. Nous fournirons une autre mise à jour car nous avons plus d'informations à partager. Merci de votre patience.

2. 24 juillet 2026 à 17:41 UTCresolved

   La question ayant une incidence sur les clients qui utilisent GitHub comme VCS alors que GitHub subissait une dégradation de service (https://www.githubstatus.com/incidents/yjysg0xrl67m) a maintenant été résolue. GitHub a résolu le problème sous-jacent et la fonctionnalité affectée est revenue à la normale. Nous vous remercions de votre patience.

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

1. 22 juillet 2026 à 19:57 UTCinvestigating

   Nous enquêtons sur les retards dans la création d'emplois en utilisant la classe de ressources gen3.

2. 22 juillet 2026 à 23:17 UTCinvestigating

   Nous continuons d'étudier les temps d'attente élevés affectant les clients en utilisant les executeurs de machines gen3. Les emplois touchés peuvent prendre plus de temps que d'habitude pour commencer. Nous fournirons une autre mise à jour dès que nous aurons plus d'informations à partager.

3. 23 juillet 2026 à 00:31 UTCinvestigating

   Nous avons identifié le problème et travaillons avec notre fournisseur pour résoudre la disponibilité des ressources gen 3. Les groupes 1 et 2 sont tous deux pleinement opérationnels.

4. 23 juillet 2026 à 02:05 UTCresolved

   Entre 19h24 UTC le 22 juillet et 01h50 UTC le 23 juillet, les clients utilisant les classes de ressources de la machine d'aperçu gen3 (Linux VM) ont connu des retards et, dans certains cas, des emplois qui n'ont pas commencé. Nous avons supprimé les classes de ressources gen3 alors que nous abordons les questions de stabilité les concernant. Malheureusement, les flux de travail pour lesquels nous n'avons pas pu fournir de capacité de calcul pendant cette période ont été annulés. Les clients touchés devraient changer leur classe de ressources de gen3 à gen2 et réexécuter ces workflows. Nous vous remercions de votre patience pendant que notre équipe a travaillé à résoudre ce problème.

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

1. 22 juillet 2026 à 06:13 UTCmonitoring

   Un sous-ensemble de clients peut avoir connu des erreurs de chargement app.circleci.com à partir de 03:18 UTC. Un correctif a été déployé et nous surveillons le rétablissement complet. Merci de votre patience pendant que nos ingénieurs confirment la récupération. Nous fournirons une autre mise à jour sous peu.

2. 22 juillet 2026 à 06:27 UTCresolved

   Entre 03:18 UTC et 06:04 UTC le 22 juillet 2026, un sous-ensemble de clients n'ont pas pu accéder à app.circleci.com. Le problème a été résolu et l'accès est revenu à 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. 20 juillet 2026 à 00:35 UTCidentified

   Nous avons identifié un problème avec les requêtes de l'API GitHub qui peuvent amener certains clients à voir les workflows bloqués dans un état en cours d'exécution ou les workflows ne démarrent pas. GitHub a signalé des incidents sur les API https://www.githubstatus.com/incidents/ph5nns5y4gxj https://www.githubstatus.com/incidents/8vfyvq16hzh9 Nous surveillons la stabilité des API GitHub et mettrons à jour cette page à mesure que de plus amples informations sont disponibles.

2. 20 juillet 2026 à 01:24 UTCidentified

   Nous voyons également des erreurs de traitement des webhooks push event en raison de la panne d'API en amont. Les utilisateurs peuvent avoir besoin de réessayer des pipelines pour ces événements de poussée.

3. 20 juillet 2026 à 01:36 UTCmonitoring

   Nous voyons des signes de récupération de l'API GitHub. Nous resterons dans un état de surveillance pour vérifier que le taux d'erreur de l'API a récupéré.

4. 20 juillet 2026 à 01:45 UTCresolved

   Les taux d'erreur de l'API GitHub ont été récupérés à des niveaux normaux. Au cours de l'incident, certains clients ont peut-être vu des pipelines ne démarrent pas ou ne reçoivent pas de mises à jour. Certains pipelines peuvent être bloqués dans un état de circulation. * Vous devriez re-push commits ou utiliser l'interface utilisateur pour déclencher manuellement les pipelines qui n'ont pas démarré. * Les pipelines dans un état de fonctionnement bloqué devraient être annulés et réacheminés. Si vous rencontrez des problèmes, veuillez contacter le support CircleCI.

5. 23 juillet 2026 à 21:10 UTCpostmortem

   Résumé Le 20 juillet, 2026 de 00:22 à 01:45 UTC, les clients de CircleCI utilisant nos intégrations GitHub ont connu des défaillances en exécutant des pipelines et des workflows expérimentés se coinçant. Au cours de cet incident, certains pipelines déclenchés par des utilisateurs utilisant GitHub n'ont pas démarré ou exécuté comme pipelines d'erreur. Les clients dont les pipelines ont échoué ou ont fonctionné comme pipelines d'erreur pendant cette fenêtre devraient les ré-exécuter. Cela a été causé par une [dégradation de l'API en amont à GitHub](https://www.githubstatus.com/incidents/ph5nns5y4gxj), qui a touché de nombreuses API GitHub utilisées par CircleCI pour déclencher et exécuter des pipelines. D'ici 01:45 UTC, les API GitHub ont récupéré et les pipelines clients ont fonctionné normalement. La page d'état du CercleCI se trouve ici (https://status.circleci.com/incidents/9lvbbbs9l87b). Ce qui s'est passé \(toutes les heures UTC\) À partir de 00:22 le 20 juillet 2026, GitHub a commencé à renvoyer des erreurs élevées pour les demandes d'API suivantes: * "demandes/*/jeton" * "repos/*/commits" * "repos/*/*/contenu/*" * "repos/*/*/hooks" * "repos/*/*/hooks/*" * "repos/*/*/clés" * "repos/*/*/pulls" * "repos/*/*/statuts/*" CircleCI compte sur ces demandes pour déclencher et exécuter correctement les pipelines. À 00h22, notre surveillance interne nous a alerté du problème. Notre équipe a commencé à enquêter et a constaté qu'un petit nombre de pipelines appartenant à des projets de GitHub n'avaient pas commencé ni couru comme pipelines d'erreur. Cela comprenait les pipelines et les flux de travail prévus. En outre, un petit nombre de flux de travail des clients ont connu des emplois bloqués et ont nécessité une nouvelle gestion du flux de travail à corriger. À 1 h 45, GitHub a récupéré et le traitement des pipelines est revenu à des niveaux d'exploitation normaux. Seuls les pipelines déclenchés pendant la fenêtre de l'incident ont été touchés, et les clients devraient les réutiliser. ## Prévention future et amélioration des processus Nous travaillons activement à améliorer la résilience du traitement des pipelines pendant les interruptions de service de GitHub afin de réduire l'impact client d'incidents similaires à l'avenir. Nous sommes des fonctionnalités de cadrage qui aideront les clients à récupérer avec des étapes manuelles réduites après la résolution des incidents. 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. Veuillez contacter notre équipe de soutien pour toute question ou préoccupation.

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

1. 16 juillet 2026 à 23:04 UTCinvestigating

   Nous enquêtons sur un problème où les clients peuvent voir des erreurs de chargement de l'application Web CircleCI et de connexion, ainsi que des pipelines et des workflows programmés ne démarrent pas ou ne fonctionnent pas tard. Ceci est lié à un incident continu touchant GitHub. Vous pouvez suivre le statut de GitHub à l'adresse https://www.githubstatus.com/incidents/gxycch3076xk. Nos ingénieurs enquêtent activement. Nous fournirons une autre mise à jour dès que nous aurons plus d'informations à partager.

2. 16 juillet 2026 à 23:42 UTCidentified

   Nous continuons de voir des taux d'échec élevés des API GitHub qui ont une incidence sur la connexion et le traitement des flux de travail. Nous continuerons à surveiller l'API GitHub pour la récupération.

3. 17 juillet 2026 à 00:09 UTCmonitoring

   Qu'est-ce qui se passe ? L'incident en amont touchant GitHub a été atténué et est actuellement surveillé du côté de GitHub. Vous pouvez suivre le statut de GitHub à l'adresse https://www.githubstatus.com/. Que pouvez-vous attendre L'accès à l'application Web CircleCI, à la connexion et au traitement des pipelines et des flux de travail revient à la normale. Vous pouvez encore voir des erreurs intermittentes ou des pipelines et des workflows programmés retardés que les systèmes se stabilisent. Merci de votre patience pendant que nous surveillons la guérison complète.

4. 17 juillet 2026 à 00:26 UTCresolved

   Un incident affectant l'API de GitHub a amené les clients de CircleCI à éprouver des erreurs en chargeant l'application web et en se connectant, ainsi que des pipelines et des workflows programmés qui ne démarrent pas ou ne fonctionnent pas tard. GitHub a résolu l'incident sous-jacent (https://www.githubstatus.com/) et toutes les fonctionnalités touchées sont revenues à la normale. Les clients dont le travail ou les pipelines ont échoué peuvent les réutiliser. Les pipelines et les workflows prévus qui ont été manqués pendant l'incident ne fonctionneront pas automatiquement et devront être redémarrés. Nous vous remercions de votre patience.

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

1. 14 juillet 2026 à 22:54 UTCidentified

   Le 13 juillet, entre 15h30 UTC et 22h40 UTC, nous avons connu des retards dans le démarrage d'emplois dans les classes de ressources Docker (Gen 2) en raison des contraintes de capacité de notre fournisseur de cloud. Les retards ont atteint environ 1 minute 48 secondes. Nous continuons de connaître ces retards depuis environ 15 h 45 UTC. Jusqu'à présent, les retards ont atteint environ 1 minute 19 secondes. Nous travaillons avec notre fournisseur de cloud pour augmenter la capacité et mettrons à jour cet incident au fur et à mesure que la situation change.

2. 15 juillet 2026 à 00:32 UTCresolved

   Le 13 juillet, entre 15h30 UTC et 22h40 UTC, nous avons connu des retards dans le démarrage d'emplois dans les classes de ressources Docker (Gen 2) en raison des contraintes de capacité de notre fournisseur de cloud. Le même numéro a repris le 14 juillet entre 15h45 UTC et 22h50 UTC. Les retards ont atteint 25 minutes le 13 juillet et 24 minutes le 14 juillet. Les classes de ressources moyennes+ et 2 X-large+ ont connu les plus longues attentes. Les mises à jour antérieures de cet incident ont révélé des chiffres basés sur les temps d'attente moyens, qui ne reflétaient pas l'impact maximal que certains clients ont pu avoir. Les temps d'attente sont maintenant revenus à la normale. Nous continuons de travailler avec notre fournisseur de cloud pour augmenter la capacité avant la prochaine période de pointe. Merci de votre patience.

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

1. 14 juillet 2026 à 02:49 UTCinvestigating

   Nous enquêtons actuellement sur les erreurs de connexion affectant certains clients utilisant Bitbucket comme leur fournisseur d'identité.

2. 14 juillet 2026 à 03:29 UTCinvestigating

   Notre équipe continue d'étudier les erreurs de connexion affectant certains clients utilisant Bitbucket comme leur fournisseur d'identité.

3. 14 juillet 2026 à 03:51 UTCinvestigating

   Ce qui est touché Certains clients qui se connectent avec une identité liée à Bitbucket sont affectés. Cela peut également inclure les clients qui se connectent avec GitHub mais ont une identité Bitbucket liée sur leur compte. De plus, certains clients connaissent des workflows qui ne démarrent pas ou ne mettent pas à jour. Que pouvez-vous attendre Les clients touchés peuvent voir des erreurs de connexion. Certains clients peuvent également remarquer des flux de travail qui ne démarrent pas ou ne mettent pas à jour comme prévu. Merci de votre patience pendant que nos ingénieurs enquêtent. Prochaine mise à jour Nous fournirons une autre mise à jour dès que nous aurons plus d'informations à partager

4. 14 juillet 2026 à 04:21 UTCmonitoring

   Ce qui est touché Certains clients qui se sont connectés avec une identité liée à Bitbucket ont été touchés. Cela peut également avoir inclus les clients qui se connectent avec GitHub qui ont une identité Bitbucket liée sur leur compte. Certains clients ont également connu des flux de travail qui ne commençaient pas ou ne s'actualisaient pas. Que pouvez-vous attendre Une correction a été déployée. Nous surveillons la situation pour confirmer une reprise complète. Prochaine mise à jour Nous fournirons une mise à jour si quelque chose change

5. 14 juillet 2026 à 05:15 UTCresolved

   La question où les clients se connectent avec une identité liée à Bitbucket a connu des erreurs de connexion, et certains clients ont connu des flux de travail qui n'ont pas commencé ou n'ont pas mis à jour, a été résolue. Ce que vous pouvez encore vivre et faire - Si vous utilisez Bitbucket comme méthode de connexion, veuillez vous déconnecter et réactualiser l'intégration CircleCI Bitbucket sur votre compte. - Si l'un de vos workflows est bloqué ou montre des vérifications d'état manquantes, s'il vous plaît relancez-les pour récupérer la correction. - Si vous continuez à éprouver des problèmes après avoir pris ces mesures, veuillez contacter CircleCI Support. Nous vous remercions de votre patience pendant que notre équipe a travaillé à la mise en place d'un correctif.

6. 14 juillet 2026 à 22:31 UTCpostmortem

   Résumé De 01:33 UTC à 05:18 UTC le 14 Juillet, 2026, les clients avec une identité liée à Bitbucket ont été incapables de se connecter à CircleCI, et certains clients ont connu des flux de travail qui n'ont pas commencé ou mis à jour, en raison d'un changement dans la façon dont le service OAuth de Bitbucket rapporte les autorisations de compte. À 05h07 UTC, nous avons déployé un correctif qui a corrigé la lecture par nos systèmes du champ des permissions mises à jour. Certains clients avaient besoin de se déconnecter et de re-authentifier leur intégration Bitbucket après que nous ayons déployé la solution. Nos systèmes ont continué à traiter l'arriéré des emplois touchés jusqu'à 08:39 UTC. Nous remercions nos clients de leur patience alors que nous avons résolu cet incident. Veuillez contacter notre équipe de soutien pour toute question ou préoccupation. La page d'état de cet incident se trouve [ici] (https://status.circleci.com/incidents/gsyjwybg477g). Historique CircleCI prend en charge la connexion avec un compte GitHub, un compte Bitbucket ou un courriel et un mot de passe. Quand un client se connecte avec une identité liée à Bitbucket, ou quand CircleCI doit rafraîchir l'accès du client en leur nom, nous échangeons un jeton d'autorisation avec le service OAuth de Bitbucket. Cet échange comprend une liste des permissions, ou "scopes", le client nous a accordé, que Bitbucket et CircleCI utilisent pour confirmer ce que CircleCI est autorisé à faire au nom du client. Ce qui s'est passé \(Toutes les heures UTC\) Le 8 avril 2026, [Bitbucket a annoncé un changement à son service OAuth](https://developer.atlassian.com/cloud/bitbucket/changelog/#CHANGE-3139) : il renommerait le champ utilisé pour déclarer les autorisations accordées par un client. Bitbucket a effectué une période de transition au cours de laquelle les noms de champs anciens et nouveaux étaient disponibles, puis a complètement supprimé le nom de champ ancien le 4 mai 2026. Nos systèmes n'avaient pas été mis à jour pour reconnaître le nouveau nom de champ, donc une fois Bitbucket complètement éliminé l'ancien, les demandes qui en dépendaient ont commencé à échouer. À 01:33 le 14 Juillet, 2026, nos systèmes ont commencé à ne pas traiter les informations des permissions retournées pour les comptes liés Bitbucket, parce que nos systèmes attendaient toujours la structure ancienne des permissions. Cela a causé des tentatives de connexion pour tous les comptes liés à Bitbucket, y compris pour les clients qui se connectent avec GitHub mais ont une identité Bitbucket liée à leur compte. À 01h59, la surveillance automatisée a alerté notre équipe d'ingénierie d'un pic d'erreurs sur les systèmes touchés. L'équipe a commencé à enquêter immédiatement, confirmé l'impact client à 02:38, et a alerté les clients via notre page de statut à 02:51. À 3 h, l'équipe avait isolé les échecs au champ de Bitbucket renommé. À partir de 03:17, les mises à jour de l'état du flux de travail pour les pipelines Bitbucket appartenant à des clients ayant un jeton d'accès expiré ont commencé à être abandonnées. Le contrôle des permissions Bitbucket est largement utilisé sur notre plateforme, et ces défaillances de permission ont également affecté certains de nos systèmes internes de traitement de travail. Cela a provoqué un sous-ensemble de workflows qui sont bloqués sans statut final, et a provoqué certaines requêtes de tirage pour afficher des vérifications d'état manquantes ou bloquées. À 04h21, l'équipe a déployé un correctif initial qui a résolu le problème sous-jacent, rétablissant le flux de connexion et renvoyant notre système de permissions internes à un fonctionnement normal. Certains clients touchés devaient se déconnecter et se reconnecter pour récupérer la solution. D'ici 05:07, l'équipe a déployé deux corrections supplémentaires afin que nos systèmes commencent à accepter le nouveau format de champ des permissions de Bitbucket. Nous avons résolu l'incident à 5 h 18. Certains clients ont eu besoin de se déconnecter et de re-authentifier leur intégration Bitbucket avant que leur compte entièrement récupéré. Nos systèmes ont continué à traiter un arriéré d'emplois touchés, revenant à des niveaux normaux d'environ 08:39. ## 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 durcissons notre code d'autorisation contre les modifications de l'API en amont.** Cet incident s'est produit parce que notre système n'a pas géré gracieusement un champ renommé dans une réponse d'un fournisseur d'identité tiers. Nous mettrons immédiatement à jour notre code d'autorisation afin que les champs inattendus ou manquants de GitHub, Bitbucket et GitLab soient manipulés en toute sécurité. **Nous améliorons la façon dont nous suivons les changements des fournisseurs en amont.** Nous surveillons déjà les changements de nos fournisseurs d'identité pour exactement ce genre de changement de rupture, mais nous n'avons pas ajouté ce changement de fournisseur particulier à notre surveillance à temps pour l'attraper avant qu'il ne soit expédié. Nous vérifions et développons cette surveillance afin que les annonces des fournisseurs parviennent à notre équipe avant qu'elles n'affectent les clients. **Nous améliorons la façon dont nous classons et communiquons les incidents dans leurs premières minutes.** La classification initiale de cet incident ne reflétait pas immédiatement la gravité de la situation des clients. Nous perfectionnons nos outils d'incident et nos conseils pour aider les ingénieurs à identifier et à communiquer plus rapidement l'impact client. **Nous améliorons la résilience de notre pipeline de traitement des flux de travail.** Une défaillance en aval de cet incident a fait tomber certaines mises à jour de l'état du processus plutôt que d'être réévaluées ou clairement mises en évidence. Nous examinons le comportement de réessayer et de gérer les erreurs de ce système, de sorte que des défaillances similaires en aval sont plus visibles et plus faciles à récupérer. 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. Veuillez contacter notre équipe de soutien pour toute question ou préoccupation.

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

1. 13 juillet 2026 à 21:52 UTCinvestigating

   Nous avons reçu quelques rapports de problèmes de réseau intermittents entre notre infrastructure mac et un fournisseur de VCS à nouveau. Nous enquêtons et fournirons des mises à jour.

2. 13 juillet 2026 à 22:21 UTCinvestigating

   Nous enquêtons encore sur ces problèmes de réseau intermittents. Nous allons vous remettre à jour sous peu, nous apprécions votre patience.

3. 13 juillet 2026 à 23:13 UTCinvestigating

   Nous avons pu reproduire le problème, mais il semble qu'il soit très intermittent. Nous continuons de travailler avec notre fournisseur d'infrastructure Mac pour aider à diagnostiquer le problème. On va bientôt se remettre à jour.

4. 13 juillet 2026 à 23:35 UTCmonitoring

   Nous avons identifié le problème. Certains clients peuvent rencontrer des emplois qui accrochent ou ne progressent pas pendant Github obtenir des étapes en raison de problèmes de réseau intermittents. Nos ingénieurs surveillent activement. En attendant, nous avons vu du succès avec l'augmentation du no output timeout à 15 - 20 min pour laisser plus de temps pour Github chercher. On peut le faire en suivant ce guide communautaire : https://support.circleci.com/hc/en-us/articles/360007188574-Build-has-Hit-Timeout-Limit

5. 14 juillet 2026 à 13:59 UTCidentified

   Malheureusement, il y a encore des clients qui peuvent rencontrer des emplois qui accrochent ou échouent à progresser pendant Github obtenir des étapes en raison de problèmes de réseautage intermittents avec notre fournisseur d'infrastructure Mac. Nos ingénieurs travaillent activement avec eux pour résoudre ce problème. Nous apprécions votre patience. En attendant, nous avons vu du succès avec l'augmentation du no output timeout à 15 - 20 min pour laisser plus de temps pour Github chercher. On peut le faire en suivant ce guide communautaire : https://support.circleci.com/hc/en-us/articles/360007188574-Build-has-Hit-Timeout-Limit

6. 14 juillet 2026 à 15:35 UTCidentified

   Notre fournisseur d'infrastructure Mac teste les changements de configuration de leur réseau afin d'isoler la source du problème. Nous validons activement si cela résout l'impact et nous ferons un suivi avec une autre mise à jour bientôt. Dans l'intervalle, l'augmentation de no output timeout à 15-20 min continue d'aider: https://support.circleci.com/hc/en-us/articles/360007188574-Build-has-Hit-Timeout-Limit

7. 14 juillet 2026 à 16:31 UTCidentified

   Nous avons identifié le problème comme certaines routes entrantes du fournisseur de VCS touché causant une bande passante disponible significativement plus faible, ce qui a une incidence négative sur les temps de récupération. Nous travaillons avec notre fournisseur d'infrastructure Mac pour tenter de déplacer le trafic entrant vers un autre itinéraire, mais ce processus peut prendre une longue période. Nous continuerons de fournir des mises à jour à mesure qu'elles seront disponibles. Comme nous l'avons dit dans les mises à jour précédentes, augmenter le no output timeout à 15-20 min continue d'aider: https://support.circleci.com/hc/en-us/articles/360007188574-Build-has-Hit-Timeout-Limit

8. 14 juillet 2026 à 16:58 UTCmonitoring

   Notre fournisseur d'infrastructure Mac a déplacé les routes entrantes et nous voyons la récupération dans les temps de récupération VCS. Nous continuerons de surveiller cette question au cours des prochaines heures. On va bientôt se remettre à jour.

9. 14 juillet 2026 à 18:28 UTCmonitoring

   Nous continuons à voir la récupération lente et progressive dans les temps de récupération VCS. Nous allons continuer à surveiller et à mettre à jour bientôt. Nous apprécions votre patience.

10. 14 juillet 2026 à 20:18 UTCinvestigating

    Nous commençons à voir le VCS récupérer les temps se lever à nouveau. Notre équipe d'ingénierie enquête activement et travaille avec notre fournisseur d'infrastructure Mac pour résoudre ce problème. Encore une fois, nous apprécions votre patience.

11. 14 juillet 2026 à 22:15 UTCmonitoring

    Notre fournisseur d'infrastructure Mac a déplacé plus de trafic vers les fournisseurs de réseau de travail et nous commençons à voir une récupération importante dans les temps de récupération VCS. Comme toujours, notre équipe d'ingénieurs continuera de suivre de près cette question et nous fournirons une autre mise à jour bientôt.

12. 14 juillet 2026 à 23:18 UTCresolved

    Nous continuons à voir des VCS importantes récupérer le temps de récupération au cours des dernières heures. Nous allons résoudre cet incident, et notre équipe d'ingénieurs continuera de surveiller de près. Nous apprécions grandement votre patience en travaillant avec notre fournisseur d'infrastructure Mac. Veuillez contacter notre équipe de support si vous avez des problèmes.

13. 16 juillet 2026 à 01:56 UTCpostmortem

    Résumé De 18:00 UTC le 13 juillet, 2026 à 23:18 UTC le 14 juillet, 2026, certains clients occupant des emplois sur la flotte macOS de CircleCI ont connu des emplois qui ont accroché ou échoué à progresser pendant GitHub aller chercher des étapes. Pour ces clients, GitHub va chercher des pas qui prendraient normalement 1-2 minutes et prendraient 20-30 minutes, et chronométrés. Le problème a été causé par un problème de capacité et de routage sur le chemin réseau entre notre fournisseur d'infrastructure Mac et GitHub, et les problèmes de réseau intermittents associés ont ralenti les reprises de GitHub. Pendant tout l'incident, notre équipe a travaillé directement avec notre fournisseur d'infrastructure Mac pour identifier et réacheminer le trafic loin des voies réseau touchées. Nous avons résolu un premier événement à 19h40 UTC le 13 juillet. La question a repris à 21h52 UTC le même jour, nous avons rouvert l'incident, et il a été entièrement résolu par 23h18 UTC le 14 juillet. Notre flotte macOS avait un problème similaire il y a plusieurs semaines. De 20:18 UTC le 24 Juin, 2026 à 03:09 UTC le 25 Juin, 2026, les clients ont connu un [incident similaire](https://status.circleci.com/incidents/gvysjmkf4ct9) affectant la capacité des emplois macOS à atteindre GitHub. Cet incident a également été causé par un problème de routage réseau dans notre fournisseur d'infrastructure Mac. Nous remercions nos clients pour leur patience pendant que nous avons travaillé sur cet incident. Veuillez consulter ci-dessous pour les actions spécifiques que CircleCI et notre fournisseur d'infrastructure Mac prendront. Veuillez contacter notre équipe de soutien pour toute question ou préoccupation. Les pages d'état de cet incident peuvent être consultées [ici](https://status.circleci.com/incidents/n1tc2lw9q7l0) et [ici](https://status.circleci.com/incidents/7cn777wp9qz). Historique Les emplois macOS de CircleCI sont hébergés sur un fournisseur d'infrastructure Mac tiers. Ce fournisseur se connecte à l'internet plus large, y compris les services comme GitHub, sur plusieurs voies réseau en amont redondantes. Lorsque l'un de ces chemins connaît une capacité réduite ou un problème de routage, les tâches qui récupèrent le code ou les dépendances d'une destination le long de ce chemin réseau peuvent ralentir ou s'accrocher de façon intermittente, même lorsque la propre plateforme de CircleCI, le fournisseur d'infrastructure tiers et le service de destination fonctionnent normalement. Ce qui s'est passé \(Toutes les heures UTC\) À 18h00 le 13 juillet, certains clients exécutant des travaux macOS ont commencé à éprouver des défaillances intermittentes et des retards pour récupérer le code et les dépendances de GitHub. Nous avons ouvert une enquête et alerté nos clients via notre page de statut à 18:55. Vers 19h04, notre fournisseur d'infrastructure Mac a identifié une latence accrue sur l'un de ses chemins de réseau et le trafic réacheminé autour. Les temps de récupération se sont rétablis, et nous avons déplacé l'incident à "Surveillance" à 19h29, et à "Résolue" à 19h40. À 20h44 UTC, les clients ont indiqué que le problème était revenu. Nous avons rouvert l'incident et mis à jour notre page de statut à `Enquête' à 21:52. Au cours des deux heures suivantes, nous avons travaillé en étroite collaboration avec notre fournisseur d'infrastructure pour recueillir des données diagnostiques afin d'isoler le chemin de réseau touché. Dans l'intervalle, nous avons publié des directives recommandant aux clients d'augmenter leur réglage `no output timeout` à 15-20 minutes, afin de laisser plus de temps pour GitHub aller à compléter pendant les ralentissements intermittents, et déplacé la page d'état à `Monitoring` à 23:35. Après avoir publié les lignes directrices à 23 h 35 UTC le 13 juillet, nous nous attendions à ce que le réseau sous-jacent s'améliore du jour au lendemain. Ce n'est pas le cas. À 13h59 UTC le 14 juillet, nous avons confirmé que les clients subissaient encore des défaillances intermittentes et avons déplacé la page de statut vers `Investigation`. Notre équipe d'ingénierie a reproduit l'échec directement en utilisant nos propres outils de test, ce qui a aidé à confirmer qu'il s'agissait d'un problème général "git-fetch" plutôt que quelque chose de spécifique à un outil de construction, une image de conteneur ou une mise à jour logicielle. À 15 h 35, nous avons mis à jour la page d'état afin de partager que notre fournisseur d'infrastructure testait les modifications de sa configuration réseau afin d'isoler la source du problème. À 16h31, nous avons mis à jour la page d'état pour partager que nous avions identifié la cause comme une bande passante d'entrée réduite sur une route donnée, et que nous travaillions avec notre fournisseur pour déplacer le trafic vers une autre route. À 16h36, notre fournisseur d'infrastructure a identifié les chemins de réseau touchés et déplacé le trafic loin d'eux, récupérer les temps récupérés, et à 16h58, nous avons mis à jour la page de statut à `Surveillance`. Au début de l'après-midi, certains clients voyaient à nouveau des temps de récupération lents, et nous avons déplacé la page d'état de retour à `Enquête` à 20:18. Notre fournisseur d'infrastructure a identifié deux voies réseau supplémentaires avec des performances dégradées et déplacé le trafic d'eux vers 22:07. Les temps de récupération se sont stabilisés pendant l'heure suivante, et nous avons marqué l'incident "Résolu" à 23:18. Au total, les clients exécutant des emplois Mac peuvent avoir connu des ralentissements d'emploi intermittents ou des échecs pour des parties de la fenêtre entre 18:00 UTC le 13 et 23:18 UTC le 14 juillet. Depuis lors, notre fournisseur d'infrastructure a communiqué des résultats d'essais propres sur l'ensemble de son réseau et croit que le problème de capacité sous-jacent a commencé plus en amont, plus près de GitHub, plutôt que dans son propre réseau. Nous continuons de suivre de près cette question. ## 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 construisons une surveillance automatisée supplémentaire pour la flotte macOS GitHub-fetch performance.** Notre vaste surveillance automatisée n'a pas permis d'attraper cet incident. Nous ajoutons maintenant une surveillance de bout en bout pour GitHub en particulier, afin de détecter les problèmes similaires de manière proactive. **Nous travaillons directement avec notre fournisseur d'infrastructure Mac à une détection plus rapide et proactive.** Nous demandons à notre fournisseur de construire une surveillance qui peut détecter un chemin de réseau dégradé et le contourner automatiquement, plutôt que de compter sur CircleCI pour identifier et demander une nouvelle route lors d'un incident actif. **Nous transformons l'outil de diagnostic que nous avons construit durant cet incident en une capacité permanente.** Cela nous permettra de détecter et de reproduire cette classe de défaillance du réseau sur demande à l'avenir, plutôt que d'assembler l'infrastructure de test lors d'un incident actif. **Nous examinons notre processus d'intervention en cas d'incident pour obtenir une fenêtre de confirmation suffisante avant de marquer un incident lié au réseau. Cet incident a brièvement repris après une résolution précoce et prématurée; nous formalisons une période minimale de surveillance confirmée et propre avant la clôture d'incidents de ce type. Nous continuerons de fournir des mises à jour régulières au fur et à mesure que l'enquête et l'assainissement se poursuivront. **Nous passons activement d'un seul fournisseur pour l'infrastructure Mac** ** à plusieurs fournisseurs.** Cela permettra à CircleCI d'orienter la charge de travail des clients vers le fournisseur le plus disponible et le plus performant. 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. Veuillez contacter notre équipe de soutien pour toute question ou préoccupation.

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

1. 13 juillet 2026 à 18:55 UTCinvestigating

   Nous avons reçu des rapports de problèmes de réseau intermittents entre notre infrastructure Mac et un fournisseur de VCS. Nous enquêtons et fournirons des mises à jour.

2. 13 juillet 2026 à 19:11 UTCidentified

   Nous travaillons avec notre fournisseur d'infrastructure Mac pour tenter une atténuation. Sera de nouveau mis à jour sous peu.

3. 13 juillet 2026 à 19:29 UTCmonitoring

   Notre fournisseur d'infrastructure Mac a mis en place un correctif, nous commençons à voir la récupération. On surveille et on va se remettre à jour.

4. 13 juillet 2026 à 19:40 UTCresolved

   Nous avons confirmé la correction avec notre fournisseur d'infrastructure et des tests réussis à notre fin. Si les clients continuent de voir des pistes ratées, s'il vous plaît courir à nouveau pour une connexion réussie et contacter Support si d'autres problèmes.

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