Historique des pannes de Split

1. 27 octobre 2026 à 19:52 UTCinvestigating

   Nous enquêtons actuellement sur cette question.

2. 27 octobre 2026 à 19:58 UTCinvestigating

   Les pipelines CI sur l'infrastructure VM échouent à l'étape de l'initialisation parce que la tâche est confiée à un délégué à l'extérieur du bassin prévu

3. 27 octobre 2026 à 21:15 UTCidentified

   Le problème a été identifié et une solution est en cours de mise en oeuvre.

4. 27 octobre 2026 à 22:16 UTCmonitoring

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

5. 27 octobre 2026 à 22:24 UTCresolved

   Cet incident a été résolu.

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

1. 19 octobre 2026 à 07:46 UTCinvestigating

   Nous enquêtons actuellement sur cette question.

2. 19 octobre 2026 à 08:02 UTCidentified

   Le problème a été identifié et une solution est en cours de mise en oeuvre.

3. 19 octobre 2026 à 08:04 UTCmonitoring

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

4. 19 octobre 2026 à 08:21 UTCresolved

   Cet incident a été résolu.

5. 23 octobre 2026 à 18:21 UTCpostmortem

   Résumé Le 19 octobre 2026, entre 12h10 et 12h55, les clients de Prod4 ont connu des erreurs et une indisponibilité intermittente des services de pipelines Harness. Les exécutions de pipelines lourds ont entraîné une forte augmentation du CPU et de l'utilisation de la mémoire sur le service de pipeline, et pendant une courte période toutes les instances de service n'étaient pas disponibles. L'ingénierie de Harness a réduit le service à la fois verticalement et horizontalement, ce qui a rétabli le service. Un correctif pour le comportement sous-jacent est en cours de déploiement. ## **La cause de la mort** Le 19 octobre, un grand nombre d'exécutions simultanées avec de très grands graphiques d'exécution ont entraîné une forte augmentation des ressources en grappes. Le service stocke et récupère ce graphique d'exécution complète à des fins de visualisation et de progression des pipelines vers les états suivants. Nos auto-scalaers sur Prod4 ont pris plus de temps que d'habitude pour l'échelle des ressources en raison d'une forte augmentation du CPU et de la mémoire. Dans le cadre de la correction, la mise à jour du graphique d'exécution va maintenant traiter les changements de graphique progressivement au lieu du graphique complet. Il est mis en œuvre par étapes et sera complètement déployé au plus tôt. ## **Impact** * Utilisateurs touchés: Clients sur Prod4. * Symptôme : non-disponibilité de la fonctionnalité du pipeline sur la plateforme Harness. * Données: aucune perte de données. * Solution suggérée : Aucune exigence de la part des clients. L'ingénierie de Harness a résolu le problème. * Durée de l'impact: environ 20 minutes d'indisponibilité totale et de performance dégradée pendant 25 minutes. Harnais a poursuivi la surveillance après la récupération et confirmé la stabilité de la plateforme avec les clients. **Réparation** **Immédiate** L'ingénierie de Harness a mis à l'échelle le service pipelinier à la fois verticalement \(plus de ressources par instance\) et horizontalement \(plus d'instances\), et supprimé les instances dans un état malsain. Le nombre d'instances stabilisé et le service normal ont été rétablis. Le système restera à l'échelle jusqu'à ce que la correction soit complètement déployée. ** Correction permanente et mesures à prendre** Pour éviter que de tels problèmes ne se reproduisent, Harness est 1. Tuning le processus auto de guérison / d'escalade de sorte que l'impact est mimimal à aucun. 2. Optimiser le flux du graphique d'exécution afin que les grands graphiques puissent être traités plus rapidement.

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

1. 15 octobre 2026 à 10:10 UTCinvestigating

   Nous enquêtons actuellement sur cette question.

2. 15 octobre 2026 à 10:10 UTCidentified

   Le problème a été identifié et une solution est en cours de mise en oeuvre.

3. 15 octobre 2026 à 10:27 UTCresolved

   Cet incident a été résolu.

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

1. 15 octobre 2026 à 08:04 UTCinvestigating

   Nous enquêtons actuellement sur cette question.

2. 15 octobre 2026 à 08:05 UTCidentified

   Le problème a été identifié et une solution est en cours de mise en oeuvre.

3. 15 octobre 2026 à 08:09 UTCmonitoring

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

4. 15 octobre 2026 à 08:15 UTCresolved

   Cet incident a été résolu.

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

1. 13 octobre 2026 à 01:06 UTCinvestigating

   Nous enquêtons actuellement sur cette question.

2. 13 octobre 2026 à 01:07 UTCidentified

   Le problème a été identifié et une solution est en cours de mise en oeuvre.

3. 13 octobre 2026 à 01:56 UTCmonitoring

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

4. 13 octobre 2026 à 04:29 UTCresolved

   Cet incident a été résolu.

5. 23 octobre 2026 à 03:16 UTCpostmortem

   . .

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

1. 12 octobre 2026 à 15:25 UTCinvestigating

   Nous connaissons actuellement des erreurs HTTP 429 (limite de taux) lorsque Harness Cloud construit l'accès à Maven Central, ce qui peut avoir un impact sur l'exécution de la construction. Notre équipe travaille activement avec Sonatype pour résoudre le problème le plus rapidement possible. Nous fournirons d'autres mises à jour à mesure que nous progresserons.

2. 12 octobre 2026 à 19:31 UTCresolved

   Cet incident a été résolu.

3. 23 octobre 2026 à 03:06 UTCpostmortem

   tldr: \(Il y avait une brève limitation du taux par le centre de la machine) Plus de détails à suivre

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

1. 8 octobre 2026 à 10:23 UTCmonitoring

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

2. 8 octobre 2026 à 10:53 UTCresolved

   Cet incident a été résolu.

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

1. 6 octobre 2026 à 21:46 UTCinvestigating

   Nous enquêtons actuellement sur cette question.

2. 6 octobre 2026 à 21:47 UTCinvestigating

   Nous continuons d'enquêter sur cette question.

3. 6 octobre 2026 à 22:03 UTCidentified

   Le problème a été identifié et une solution est en cours de mise en oeuvre.

4. 6 octobre 2026 à 22:30 UTCmonitoring

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

5. 6 octobre 2026 à 22:30 UTCmonitoring

   Un correctif a été mis en place et nous suivons les résultats. nous avons confirmation de cette correction du problème.

6. 6 octobre 2026 à 22:44 UTCresolved

   Cet incident a été résolu.

7. 23 octobre 2026 à 02:12 UTCpostmortem

   1. Résumé Le 6 octobre 2026, les pipelines contenant une étape IaCM n'ont pu démarrer sur Prod1 pendant environ deux heures. Les utilisateurs touchés ont vu une erreur lorsque le pipeline a tenté de créer son plan d'exécution. Les pipelines qui n'utilisaient pas l'étape IaCM ont continué à circuler normalement tout au long de la période. La cause sous-jacente était un défaut d'enregistrement interne dans le service qui s'occupe de l'exécution de l'étape IaCM : dans une condition de timing spécifique et rare, le propre système d'enregistrement de ce service pourrait finir par s'attendre indéfiniment, ce qui a à son tour bloqué le processus plus large chargé de préparer les plans d'exécution du pipeline. Le problème a été déclenché par une explosion inhabituelle d'activité de log depuis le pipeline d'un client. Nous avons résolu l'impact immédiat en retournant le service à sa version stable précédente, et un correctif de code permanent est actuellement en test. 2. Impact * Tous les pipelines utilisant une étape IaCM sur Prod1 n'ont pas pu démarrer pendant environ deux heures. * Plusieurs clients du groupe Prod1 ont été touchés. * Les pipelines qui n'ont pas utilisé l'étape IaCM n'ont pas été touchés et ont continué à fonctionner normalement. * Aucune donnée n'a été perdue à la suite de cet incident. * Comme effet secondaire du renversement utilisé pour résoudre cet incident, une correction non liée pour un client \(en prolongeant la durée de validité d'un certain jeton d'authentification pendant les pipelines à long terme\) a été temporairement retournée. Cette solution a été réappliquée le soir même. 3. Cause profonde Le service responsable des étapes du pipeline IaCM enregistre son activité par une file d'attente interne : des messages journaux sont placés sur la file d'attente, et un seul travailleur d'arrière-plan lit en permanence et écrit les messages. Séparément, ce service dispose d'un filtre qui peut réécrire la gravité de certains messages journal à nouveau sur cette même file d'attente. Dans une condition de timing spécifique et étroite, cela a créé une impasse, si la file d'attente s'est avérée complètement pleine au moment exact où un message réécrit a été remis sur elle, le seul travailleur responsable de libérer de l'espace sur la file d'attente serait lui-même coincé en attendant que l'espace soit libéré, une condition qu'il ne pourrait jamais résoudre, car c'était la seule chose qui aurait pu libérer cet espace. Une fois que cela s'est produit, toutes les autres parties du service qui devaient enregistrer quelque chose sont également devenues bloquées à attendre, ce qui s'est encastré dans le processus de création de pipeline-plan-échec pour tout pipeline utilisant une étape IaCM. 4. Résolution * Renvoyé le service à sa dernière version stable, qui a résolu l'incident immédiat. 5. Actions préventives 1. **Optimiser le défaut sous-jacent**: Optimiser et synchroniser le filtre de journalisation afin que la gravité d'un message se reproduise sur le thread qui a généré la ligne de journal, plutôt que d'être soumis à nouveau dans la file d'attente du même travailleur de fond, éliminant complètement la condition d'impasse. 2. **Enhance monitoring on logging-queue health**: ajoutez des mesures et alertez sur cette file d'attente interne de sorte que cette classe de pages de saturation notre équipe sur appel automatiquement plutôt que de compter sur les rapports clients. 3. ** Évaluer les limites et effectuer des essais de haute contrainte avec de très grands pipelines**:

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

1. 16 octobre 2026 à 10:41 UTCresolved

   Le 7 octobre 2026, de 08:00 UTC à 11:00 UTC (1:30 PM à 16:30 PM IST), certaines exécutions de pipelines sur le groupe Pro 7 ont vu des échecs intermittents dans les évaluations des étapes de la politique (OPA).

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

1. 6 octobre 2026 à 12:54 UTCmonitoring

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

2. 6 octobre 2026 à 15:35 UTCresolved

   Cet incident a été résolu.

3. 10 octobre 2026 à 01:57 UTCpostmortem

   Résumé Les clients de Prod 2 ont connu des échecs intermittents de quelques étapes de vérification au démarrage. Les étapes touchées ont échoué peu après le lancement avec un message indiquant la vérification continue\(CV\) ne pouvait pas atteindre un service d'harnais interne. La question est née d'une récente mise à jour du service qui a introduit la mise en commun des connexions pour améliorer les performances et la fiabilité avec un réglage continu incompatible avec le temps d'arrêt du service destinataire. Aucune donnée client n'a été perdue ou corrompue. Impact client Les clients utilisant CV Vérifier les étapes sur Prod-2 ont vu des défaillances intermittentes pendant la fenêtre de l'incident. Le taux d'échec était faible — la majorité des exécutions se sont déroulées avec succès tout au long de la fenêtre. Pipelines qui n'ont pas utilisé CV Vérifier les étapes n'étaient pas affectées. Cause profonde Une mise à jour récente du service CV a introduit la mise en commun de la connexion à un composant de plate-forme interne, avec une durée de conservation plus longue que le temps de repos de ce composant. Les connexions au ralenti assez longtemps ont été fermées silencieusement par le serveur; le service CV n'a pas détecté cela et n'a pas de logique de réessayer pour de telles défaillances, les faisant apparaître directement comme des défaillances de vérification des étapes. La question était intermittente parce qu'elle n'affectait que les connexions qui s'étaient avérées inactives assez longtemps pour expirer. Atténuation La durée de maintien de la connexion a été réduite pour tomber dans le délai d'attente du service récepteur. Les défaillances sont tombées à près de zéro immédiatement, et aucune autre défaillance de ce type n'a été observée dans aucun environnement de production. Prochaines étapes Pour prévenir les récidives, Harness : * **Manipulation de la connexion:** Ajusté la fonction de veille par défaut et activé automatiquement sur les pannes de connexion de sorte que les erreurs de connexion statique sont traitées de manière transparente. * ** Ajouter la résilience au démarrage de l'étape :** Introduire une réessayer avec l'arrière-plan pour l'appel de service interne au démarrage de l'étape de vérification, de sorte que les défaillances transitoires isolées ne se présentent pas comme des défaillances immédiates de l'étape. * **Améliorer l'alerte :** Surveillance améliorée des taux d'erreur de connexion interne.

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

1. 6 octobre 2026 à 11:58 UTCinvestigating

   Nous enquêtons actuellement sur cette question.

2. 6 octobre 2026 à 11:59 UTCinvestigating

   Nous continuons d'enquêter sur cette question.

3. 6 octobre 2026 à 12:24 UTCidentified

   Le problème a été identifié et une solution est en cours de mise en oeuvre.

4. 6 octobre 2026 à 16:21 UTCresolved

   Cet incident a été résolu.

5. 9 octobre 2026 à 18:48 UTCpostmortem

   Résumé Le **mardi 6 octobre 2026**, les pipelines IaCM qui utilisent le plugin **OpenTofu** dans **Prod1** ont échoué par intermittence pour un compte de productionAffected runs ont injecté des secrets avec succès, puis des étapes ultérieures ont été chronométrées ou ont échoué l'authentification. Le même pipeline a souvent réussi à réessayer, sans changement de configuration. Les exécutions ont duré environ 90 minutes. D'autres modules Harness n'ont pas été largement touchés. Nous n'avons aucun rapport de perte de données client. Les pipelines qui ont fini à l'intérieur de la durée de vie du jeton n'ont pas été touchés par ce défaut. La cause profonde L'IaCM met en place des jetons d'authentification minés qui ont expiré après une heure. Les contrôles de politique plus tard à long terme ont ensuite rejeté le jeton, de sorte que l'étape s'est arrêtée ou a échoué à l'authentification. Cette durée de vie d'une heure a été fixée. Des descentes d'environ 90 minutes ont franchi la limite d'une heure, c'est pourquoi les pannes se sont produites sur des pipelines plus longs et ont souvent été éliminées sur une réessayer plus courte. Un ensemble séparé d'erreurs de plan dans le même compte provient de la configuration des justificatifs dans l'espace de travail du client et est en dehors de cet incident. Impact * ** Superficie du produit:** pipelines IaCM utilisant les plugins IaCM parlant à OPA sdk. * **Expérience client :** timeouts intermittents et pannes d'authentification après injection secrète, sur des parcours de plus d'une heure. * **Environnement:** Prod1, un compte de production * **Données :** Aucune perte de données. (en milliers de dollars) Réparation * **Immédiate :** Ouverture d'une page d'état pour le compte Prod1 touché, et envoi d'un changement intérimaire de gestionnaire IaCM pour une classe des échecs observés pendant que le plugin fix a été construit. * ** Permanent :** Expédié un plugin OpenTofu hotfix donc l'expiration du jeton est configurable. En production, la durée de vie a été portée à environ 6 heures, de sorte qu'un long pipeline ne dépasse pas le jeton. Le hotfix a été validé en QA et déployé sur Prod1. Nous nous excusons pour la perturbation causée. Si vous avez d'autres questions, veuillez communiquer avec votre personne-ressource de soutien Harness.

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

1. 5 octobre 2026 à 22:01 UTCinvestigating

   Nous enquêtons actuellement sur cette question.

2. 5 octobre 2026 à 23:50 UTCidentified

   Le problème a été identifié et une solution est en cours de mise en oeuvre.

3. 6 octobre 2026 à 00:26 UTCmonitoring

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

4. 6 octobre 2026 à 00:26 UTCmonitoring

   Nous restons à l'affût de tout autre problème.

5. 6 octobre 2026 à 00:39 UTCresolved

   Vérifié la correction et résolu les problèmes de SSO.

6. 9 octobre 2026 à 16:17 UTCpostmortem

   ## Okta Application SP-Initiative SSO Login Défauts (en milliers de dollars) # Résumé (en milliers de dollars) Entre le 5 octobre 2026, 18:18 UTC et le 6 octobre 2026, 00:26 UTC, certains clients Harness n'ont pas pu se connecter au serveur MCP hébergé par l'intermédiaire de SAML Single Sign-On \(SSO\). L'authentification principale des utilisateurs du portail Harness est restée pleinement opérationnelle. Les utilisateurs touchés ont vu des erreurs de connexion ou ont été redirigés vers une page SSO non valide au lieu de remplir la connexion. (en milliers de dollars) Le problème a été causé par la rupture des changements dans une version mise à niveau du service d'identité Harness HarnessID. Nous l'avons réparé avec une série de hotfixes, et la connexion SSO a été entièrement restaurée pour tous les clients touchés. (en milliers de dollars) # Impact (en milliers de dollars) Les utilisateurs se connectant à Harness MCP via SAML SSO n'ont pas pu compléter l'authentification. Les séances de GCP existantes qui reposaient sur l'OSS ne pouvaient pas être rafraîchies, de sorte que certains utilisateurs devaient se connecter à nouveau et ne pouvaient pas. Les connexions non-OSS au MCP hébergé ont fonctionné pendant la plupart des incidents. Aucune donnée client n'a été perdue ou exposée. Les clients utilisant leur propre configuration générique d'application SAML 2.0 à Okta n'ont pas été touchés. Cause racine Le 29 septembre 2026, une version mise à jour de l'application Harness a été publiée au réseau d'intégration Okta. La mise à jour a ajouté une prise en charge pour enregistrer plusieurs URLs \(ACS\), de sorte que les clients exécutant Harness dans plusieurs régions ou environnements pourraient configurer plus d'une URL de callback. (en milliers de dollars) Harness inclut une valeur AssertionConsumerServiceURL dans la requête d'authentification SAML qu'il envoie à Okta. Avant cette mise à jour, Okta n'a pas validé cette valeur pour les instances d'application sans URL ACS supplémentaires configurées et a plutôt renvoyé l'affirmation SAML à l'URL ACS par défaut de l'application. Après la mise à jour, cette validation est devenue active dans toutes les instances d'application existantes, y compris celles où le client n'avait jamais configuré une URL ACS supplémentaire. Comme la valeur demandée n'était pas présente dans la liste enregistrée de l'instance, Okta a renvoyé une erreur HTTP 400. (en milliers de dollars) La mise à jour de l'application a fait l'objet de l'examen standard de publication OIN d'Octa, qui comprend une vérification de la compatibilité avec les installations existantes de l'intégration publiée. Cette modification du comportement de validation pour les instances sans URL ACS supplémentaire configurée n'a pas été mise en évidence au cours de cet examen, il a donc atteint les clients au moment de la publication. # Réparation ** Réponse immédiate** (en milliers de dollars) Deux solutions ont été publiées sur la page d'état : se connecter à partir de la tuile Harness dans Okta \(IdP-initiated login\), qui n'a pas été affecté, ou enregistrer l'URL Okta SSO de l'application dans le champ URL ACS supplémentaire de l'application Harness Okta. Harness a engagé chaque client touché signalé directement et a validé leur signature. (en milliers de dollars) **Résolution** (en milliers de dollars) Le renvoi de l'application à la version précédente a été délibérément évité, car cela ne ferait que reporter la même perturbation à la prochaine version. Chaque client touché a plutôt été débloqué par l'enregistrement d'URL ACS, et nous travaillons avec Okta pour rendre la validation d'URL ACS conditionnelle à nouveau, de sorte que les instances sans URL ACS supplémentaire configuré se comportent exactement comme elles l'ont fait auparavant, et aucune action client n'est requise. # Éléments d'action Pour éviter que ces problèmes ne se reproduisent, Harness prendra les mesures suivantes : (en milliers de dollars) 1. Travailler avec Okta pour restaurer la validation conditionnelle d'URL ACS, de sorte que les instances sans URL ACS supplémentaires configurées se comportent exactement comme avant et aucune action client n'est requise. 2. Publier un guide de configuration dédié pour l'application OIN Harness dans la documentation Harness, y compris la réponse \(ACS\) exigences URL. 3. Ajouter une étape de vérification indépendante en fonction des configurations client existantes pour toute mise à jour future de l'application Okta publiée, en plus de son propre avis. 4. Migrer l'authentification de l'utilisateur vers l'ID Harness, qui supprime entièrement la dépendance sur ce comportement de validation.

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

1. 29 septembre 2026 à 20:31 UTCinvestigating

   Nous enquêtons actuellement sur cette question.

2. 29 septembre 2026 à 20:31 UTCidentified

   Le problème a été identifié et une solution est en cours de mise en oeuvre.

3. 29 septembre 2026 à 20:57 UTCidentified

   Nous avons identifié un problème qui ne s'applique qu'à l'ouverture de session SP via l'application Harness Okta publiée. Après une mise à jour récente de cette application, ces tentatives de connexion ont retourné une erreur HTTP 400 lorsque l'URL SSO configurée était absente des URL ACS supplémentaires. Les configurations générales SAML 2.0 en Okta ne sont pas affectées. Solutions immédiates : Utilisez la connexion IDP. Commencez la connexion à partir de la tuile d'application Harness à Okta. Ou Ajoutez votre URL SSO Harness à des URLs ACS supplémentaires dans l'application Harness Okta publiée.

4. 2 octobre 2026 à 00:33 UTCresolved

   Cet incident a été résolu.

5. 7 octobre 2026 à 18:30 UTCpostmortem

   1. Résumé À partir du 29 septembre 2026, les clients qui se connectent à Harness par l'intermédiaire de l'application Harness publiée dans le réseau d'intégration Okta \(OIN\) n'ont pas été en mesure de compléter la connexion SSO lancée par SP. Les utilisateurs touchés ont reçu une erreur HTTP 400 de Okta au lieu d'être connectés. La question a été introduite par un changement dans la manière dont Okta a validé l'URL de réponse demandée \(ACS\) pour les installations existantes de l'application Harness publiée. Des solutions de rechange ont été publiées dans l'heure qui a suivi le premier rapport, et chaque client touché a été débloqué. 2. Impact (en milliers de dollars) * Impact a été limité aux clients utilisant l'application Harness publiée de l'Okta Integration Network pour l'ouverture de session SP \(commencer la connexion de Harness\). Ces tentatives ont retourné une erreur HTTP 400 de Okta. * IdP-initiad login, a commencé à partir de la tuile Harness à Okta, a continué à travailler tout au long. * Les clients utilisant leur propre configuration d'application SAML 2.0 générique en Okta n'ont pas été touchés. * Aucune donnée client n'a été perdue ou exposée. 3. Cause profonde Le 29 septembre 2026, une version mise à jour de l'application Harness a été publiée au réseau d'intégration Okta. La mise à jour a ajouté une prise en charge pour enregistrer plusieurs URLs \(ACS\), de sorte que les clients exécutant Harness dans plusieurs régions ou environnements pourraient configurer plus d'une URL de callback. Harness inclut une valeur AssertionConsumerServiceURL dans la requête d'authentification SAML qu'il envoie à Okta. Avant cette mise à jour, Okta n'a pas validé cette valeur pour les instances d'application qui n'avaient pas d'URL ACS supplémentaire configurée, et a simplement renvoyé l'affirmation SAML à l'URL ACS par défaut de l'application. Après la mise à jour, cette validation est devenue active sur toutes les instances existantes de l'application, y compris celles où le client n'avait jamais configuré une URL ACS supplémentaire. Comme la valeur demandée n'était pas présente dans la liste enregistrée de l'instance, Okta a rejeté la requête d'authentification avec une erreur HTTP 400. La mise à jour de l'application a fait l'objet de l'examen standard de publication OIN d'Okta, qui comprend une vérification de compatibilité avec les installations existantes d'une intégration publiée. Ce changement dans le comportement de validation pour les instances sans URL ACS supplémentaire configuré n'a pas été mis en évidence au cours de cet examen, il a donc atteint les clients à la sortie. 4. Réparation ** Réponse immédiate** Deux solutions de rechange ont été publiées sur la page d'état : se connecter à partir de la tuile Harness dans Okta \(IdP-initiated login\), qui n'était pas affecté; ou enregistrer l'URL Okta SSO de l'application dans le champ URL ACS supplémentaire de l'application Harness Okta. L'assistance a engagé chaque client concerné directement et validé la connexion avec eux. (en milliers de dollars) **Résolution** Le renvoi de l'application à la version précédente a été délibérément évité, car cela ne ferait que reporter la même perturbation à la prochaine version. Chaque client affecté a plutôt été débloqué à travers l'enregistrement d'URL ACS, et nous travaillons avec Okta pour rendre la validation d'URL ACS conditionnelle à nouveau, de sorte que les instances sans URL ACS supplémentaire configuré se comportent exactement comme elles l'ont fait avant et aucune action client n'est requise. 5. Mesures à prendre Pour éviter que de tels problèmes ne se reproduisent, nous travaillons sur **Mesures à prendre** Oui. En travaillant avec Okta pour restaurer la validation conditionnelle d'URL ACS, les instances sans URL ACS supplémentaires configurées se comportent exactement comme avant et aucune action client n'est requise. Autres Publier un guide de configuration dédié pour l'application Harness OIN dans la documentation Harness, y compris les exigences d'URL \(ACS\) de réponse. Ajouter une étape de vérification indépendante en fonction des configurations client existantes pour toute mise à jour future à l'application Okta publiée, en plus de son propre avis. Migrer l'authentification de l'utilisateur vers l'ID Harness, qui supprime la dépendance sur ce comportement de validation entièrement. Autres

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

1. 29 septembre 2026 à 18:45 UTCinvestigating

   Nous enquêtons actuellement sur cette question.

2. 29 septembre 2026 à 21:55 UTCmonitoring

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

3. 29 septembre 2026 à 22:01 UTCresolved

   Cet incident a été résolu.

4. 2 octobre 2026 à 22:40 UTCpostmortem

   Résumé Entre environ **11:37 AM et 3:01 PM PDT \(18:37–22:01 UTC\) le 29 septembre 2026**, les clients utilisant Harness CI auto-hosted Linux cloud runders dans **prod1/prod2 \(us-west1\)** ont connu des défaillances de réseau intermittentes pendant l'exécution de pipelines — principalement Git/network timeouts lors de la récupération du code source. ** Cause de la mort** Ceci était principalement dû à la saturation de notre NAT qui a été ultérieurement exacerbée par une capacité de calcul temporaire du fournisseur de cloud, empêchant ainsi la fourniture de nouveaux VM. Impact * Les clients utilisant l'auto-hébergement Linux CI construit dans nous-west1 vu ** défaillances de build/pipeline intermittente**, pas une panne complète. * Erreurs observées face au client inclus Git récupérer timeouts, p.ex. `Échec de connexion au port github.com 443: Connexion timed out` **Réparation** * **Immédiate:** Rééquilibrer la charge ARM build-VM à partir de la trajectoire saturée us-west1 vers central1 \(partiellement limitée par la capacité central1\); redémarrer les passerelles cloud NAT, qui ont stabilisé le réseau de pipelines. ** Mesures à prendre** 1. Sécuriser la capacité supplémentaire de passerelle/IP NAT \(En cours\) 2. Améliorer la détection de saturation NAT et alerter avant l'impact client. 3. Évaluer les contingences de capacité entre les régions afin que la pénurie de calcul d'une seule région ne bloque pas l'atténuation des défaillances.

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

1. 29 septembre 2026 à 14:41 UTCinvestigating

   Nous enquêtons actuellement sur cette question.

2. 29 septembre 2026 à 15:54 UTCmonitoring

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

3. 29 septembre 2026 à 15:57 UTCmonitoring

   Nous restons à l'affût de tout autre problème.

4. 29 septembre 2026 à 18:49 UTCresolved

   Cet incident a été résolu.

5. 2 octobre 2026 à 05:37 UTCpostmortem

   ** Résumé** Les clients de Prod-2 ont connu des taux de défaillance élevés dans les pipelines de vérification continue. Les tâches de vérification n'ont pas permis de compléter ou de signaler des erreurs parce que les travailleurs de la collecte de données CV ne pouvaient communiquer avec le service de plate-forme qui coordonne leur travail. Ceci a été causé par un pic de trafic inattendu à l'un de nos systèmes de moteur. Le service a été rétabli en éliminant la composante de plate-forme touchée. Aucune perte de données ou corruption n'est survenue. (en milliers de dollars) ** Impact client** Les clients utilisant la vérification continue sur Prod-2 ont vu que les travaux de pipeline de vérification échouent ou se terminent pendant la fenêtre de l'incident. Une fraction importante des cas d'emploi de vérification qui ont eu lieu pendant cette période s'est soldée par une défaillance opérationnelle. Les pipelines qui n'utilisent pas CV ont continué à fonctionner normalement. (en milliers de dollars) ** Cause de la mort** Une grande opération d'approvisionnement automatique a créé un nombre important de travailleurs de surveillance de CV persistants dans une fenêtre courte, qui a submergé un composant de plate-forme partagée. L'augmentation soudaine des appels sortants simultanés a épuisé les connexions réseau disponibles sur chaque instance de service. (en milliers de dollars) **Mitigation** La limite d'échelle maximale pour le service CV a été relevée, ce qui lui a permis d'accroître sa capacité de répondre à la demande. Les défaillances se sont arrêtées peu de temps après la fin de l'élimination. (en milliers de dollars) **Prochaines étapes** Pour prévenir les récidives, Harness : * **Augmenter la capacité de la salle de tête et ajouter des garde-corps :** Augmenter la limite d'échelle du service CV pour maintenir la salle de tête sous les charges d'éclatement, et introduire des limites tarifaires pour la fourniture en vrac de services surveillés. * **Améliorer la résilience :** Ajouter un dispositif exponentiel d'arrimage et d'arrimage pour les retraites des travailleurs, et utiliser un pool de connexion réutilisable pour réduire les frais généraux et empêcher les défaillances transitoires de s'accumuler sous haute concurrence. * **Améliorer la surveillance et l'alerte :** Améliorer l'alerte pour les taux de croissance anormale des travailleurs par compte, de sorte que des conditions similaires sont détectées et appliquées plus tôt.

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

1. 29 septembre 2026 à 13:12 UTCresolved

   Le 28 septembre 2026, nous avons observé un problème avec la copie des fichiers du Harness Filestore pendant l'étape d'exportation, où les fichiers étaient copiés comme fichiers nuls/vides. Par conséquent, tous les pipelines utilisant les API Filestore ont été bloqués pendant la fenêtre de l'incident. La question a été soulevée en raison d'un déploiement d'un drapeau qui a été retourné une fois le problème découvert. Toutes les opérations sont de retour à la normale.

2. 1 octobre 2026 à 17:28 UTCpostmortem

   Résumé Le 28 septembre 2026, certains clients de Prod-2 ont connu des défaillances dans les étapes du pipeline CD qui lisent le contenu de File Store en utilisant les expressions du pipeline \(p. ex., `\). Les expressions touchées sont retournées nulles au lieu du contenu du fichier attendu, ce qui entraîne une défaillance ou une mauvaise conduite des étapes dépendantes. Le problème était lié à une mise à jour de la plate-forme qui resserrait les vérifications d'autorisation sur les API de File Store. La mise à jour a été repoussée, et les expressions File Store fonctionnent normalement depuis. Impact client * Seules les étapes de pipeline sur Prod-2 qui lisent le contenu de File Store via les expressions ont été affectées. Les pipelines qui n'utilisent pas les expressions File Store n'ont pas été touchés. * Expressions touchées résolues à null, ce qui provoque des étapes qui dépendent de la configuration ou des paramètres des fichiers pour échouer ou produire une sortie incorrecte. * Aucun contenu de File Store n'a été modifié. Aucun fichier, secret, identification ou artefact n'a été exposé, et aucune donnée n'a été perdue. Cause profonde Dans le cadre d'une initiative de sécurité continue, Harness a effectué des vérifications d'autorisation plus strictes dans plusieurs API de plate-forme, y compris l'API qui sert le contenu de File Store. Lorsqu'un pipeline évalue une expression File Store, un service interne Harness appelle un autre pour récupérer le fichier. Les nouvelles vérifications d'autorisation ont échoué, ce qui a entraîné le rejet des demandes et le renvoi des expressions nulles. Atténuation Une fois que la mise à jour de la plate-forme a été identifiée comme la cause, elle a été repoussée dans l'environnement de production. Les expressions File Store ont été résolues correctement depuis le retour. Aucune action client n'est requise. ### Mesures préventives et prochaines étapes * ** API affectées par la vérification :** Examinez toutes les IPA où les vérifications d'autorisation plus strictes ont été appliquées pour s'assurer que les appels internes de service à service sont correctement comptabilisés. * ** Amélioration de la couverture des tests :** Améliorer les suites de test automatisées pour inclure l'évaluation de l'expression File Store dans les chemins d'exécution des pipelines

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

1. 23 septembre 2026 à 20:17 UTCinvestigating

   Nous étudions actuellement les problèmes de connectivité touchant les clients dont les environnements sont protégés par les pare-feu Palo Alto Networks. Ces pare-feu bloquent les connexions aux API Harness, ce qui peut entraîner: - Exécutions de pipelines échouées - Incapacité à déployer des applications - Timeouts intermittents lors de l'accès aux fonctionnalités de la plateforme Harness - Défauts d'intégration avec des outils tiers - Connectivité déléguée avec la plateforme Harness Ce problème n'est pas causé par une panne de service Harness, mais plutôt par les règles de pare-feu de votre côté réseau. Nous conseillons aux clients de faire une exception pour nos paramètres DNS.

2. 24 septembre 2026 à 08:43 UTCmonitoring

   Atténuation disponible: Trafic d'harnais bloqué par la politique de sécurité du réseau Nous avons identifié un problème où certains clients pourraient ne pas être en mesure d'accéder à Harness parce que le trafic d'Harness est classé dans la catégorie "AI-Platform" par les contrôles de sécurité du réseau de Palo Alto, puis bloqué par la politique de firewall/INET du client. Si vous rencontrez ce problème: Veuillez contacter l'équipe Réseau/Firewall/CyberSecurity de votre organisation et demander que le trafic d'harnais requis soit autorisé par votre politique Palo Alto. En tant qu'atténuation, les clients peuvent autoriser la catégorie d'URL de la liste de l'AI-Platform pour les paramètres d'Harness requis, ou ajouter les domaines d'Harness/FQDN touchés à la liste approuvée/d'autorisation de leur organisation, conformément à leurs politiques de sécurité. Une fois la politique de pare-feu mise à jour, l'accès à Harness devrait être rétabli. Important: La politique de pare-feu est gérée par l'équipe réseau/sécurité du client. Si le paramètre Harness est incorrectement classé par Palo Alto, les clients peuvent également demander un examen de catégorie URL de Palo Alto Networks.

3. 25 septembre 2026 à 17:10 UTCresolved

   Après consultation avec Palo Alto Networks, nous pouvons confirmer que le 23 septembre 2026, app.harness. io a été classé comme un service de plate-forme d'IA par l'équipe des réseaux Palo Alto. Palo Alto Networks a envoyé un avis aux clients en août sur la reclassification. Ce changement peut placer le service de plate-forme d'IA sous une politique différente de app.harness. Les règles précédentes de io catégorisation, ordinateur et Internet Info. La politique appliquée dépend des paramètres du client. Harnais Les clients devraient discuter de cette catégorisation et des alertes avec leur équipe de réseau interne et les réseaux Palo Alto.

4. 13 octobre 2026 à 04:50 UTCpostmortem

   .

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

1. 22 septembre 2026 à 16:40 UTCinvestigating

   Nous enquêtons actuellement sur cette question.

2. 22 septembre 2026 à 17:14 UTCidentified

   Le problème a été identifié et une solution est en cours de mise en oeuvre.

3. 22 septembre 2026 à 18:01 UTCmonitoring

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

4. 22 septembre 2026 à 18:38 UTCresolved

   Cet incident a été résolu.

5. 2 octobre 2026 à 22:05 UTCpostmortem

   # Résumé Le 22 septembre 2026, trois de nos passerelles réseau sortantes dans une région sont devenues malsaines et ont commencé à rejeter un petit pourcentage de nouvelles tentatives de connexion sortante. La question a été résolue le même jour complètement sans autre récurrence ni effet de suivi. La cause sous-jacente était un tampon de surveillance de la circulation interne saturé sur ces passerelles, ce qui a causé leurs contrôles de santé à réagir trop lentement et être marqué malsain. # Impact * Seulement trois exemples de passerelles dans une région ont été touchés; d'autres régions et d'autres passerelles dans la même région n'ont pas été touchés. * Il n'y a pas eu d'échec en cascade, le problème a été entièrement résolu avec une seule série de redémarrages de passerelle, et aucun problème de suivi n'est apparu après. Cause racine Nos passerelles réseau sortantes gèrent un composant interne qui surveille le trafic réseau pour la visibilité opérationnelle. Sous un trafic élevé soutenu, le tampon interne de ce composant est devenu saturé, ce qui a créé une contre-pression assez sévère pour ralentir les propres réponses de contrôle de santé de la passerelle au-delà du délai imparti par notre régulateur de charge. Une fois ce délai dépassé, l'équilibreur de charge a marqué les passerelles touchées malsaines et a commencé à rejeter une partie des nouvelles connexions destinées à eux. L'acheminement réel des paquets a continué à fonctionner normalement tout au long de l'incident. Il s'agissait plus particulièrement d'un problème de contrôle et de contrôle de la santé, et non d'une défaillance de la capacité de transmission de base des passerelles. Résolution Les trois instances de passerelle touchées ont été redémarrées manuellement, ce qui a effacé le tampon de surveillance saturé et a immédiatement rétabli le comportement normal de contrôle de santé. Les refus de connexion ont cessé dès que le redémarrage était terminé, et aucune autre intervention n'était nécessaire. # Actions préventives **Action** Oui. Remplacer l'approche actuelle de surveillance du trafic sur toutes les passerelles par une mise en œuvre plus efficace et moins directe qui ne peut pas saturer ainsi, et qui alerte bien avant tout impact visible du client. Mettre en place un remplacement automatique et périodique des passerelles à long terme sur un calendrier fixe, de sorte qu'aucun cas ne peut accumuler le genre de dégradation liée à l'âge observée dans cet incident. Autres Migrer les instances de passerelle vers une infrastructure optimisée par le réseau avec une capacité de réseau sensiblement plus dédiée, mieux adaptée à un trafic à haut débit soutenu. Améliorer l'utilisation du tampon de surveillance existant pendant le remplacement à plus long terme. Améliorer l'alerte spécifiquement sur la latence de réponse de la passerelle de contrôle de santé, pour attraper les signes précoces de dégradation avant qu'il devienne client-visible. Autres

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

1. 22 septembre 2026 à 14:00 UTCidentified

   Le problème a été identifié et une solution est en cours de mise en oeuvre.

2. 22 septembre 2026 à 14:08 UTCmonitoring

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

3. 22 septembre 2026 à 14:20 UTCresolved

   Cet incident a été résolu.

4. 2 octobre 2026 à 22:10 UTCpostmortem

   Comme la cause racine précédente.

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

1. 21 septembre 2026 à 16:39 UTCinvestigating

   Nous enquêtons actuellement sur cette question.

2. 21 septembre 2026 à 17:12 UTCidentified

   Le problème a été identifié et une solution est en cours de mise en oeuvre.

3. 21 septembre 2026 à 18:27 UTCmonitoring

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

4. 21 septembre 2026 à 18:33 UTCresolved

   Cet incident a été résolu.

5. 29 septembre 2026 à 22:39 UTCpostmortem

   Résumé Le 21 septembre 2026, les clients de Prod 2 ont connu une dégradation puis des tableaux de bord de déploiement largement indisponibles pendant environ trois heures. Le problème est dû à un ensemble de requêtes analytiques derrière ces tableaux de bord qui lisent beaucoup plus de données qu'ils n'en ont besoin, ce qui a épuisé la capacité de la base de données qui les dessert. Un redémarrage en roulis des tableaux de bord du service affecté a été entièrement restauré, et la plate-forme est stable depuis. Impact client Pages de tableau de bord chargées lentement ou chronométrées entre 14:48 et 18:11 UTC. L'exécution et l'enregistrement du déploiement des pipelines sont effectués sur une infrastructure distincte et continuent de fonctionner normalement. Aucune perte de données ou corruption n'est survenue. La cause profonde Les requêtes du tableau de bord manquaient d'un filtre dans la colonne utilisée pour diviser la plus grande table en segments hebdomadaires, de sorte que chaque requête lisait toutes les données historiques au lieu de seulement la période demandée. La justesse n'a jamais été affectée — les tableaux de bord ont retourné les bons résultats; seule la quantité de données lues pour les produire était excessive. Au fur et à mesure que le volume des données augmentait, le coût de ces lectures dépassait ce que la base de données pouvait servir, et les relevés des requêtes défaillantes ajoutaient une charge supplémentaire, de sorte que la condition n'était pas claire avant que le service ait été redémarré. Atténuation * Effectué un redémarrage en roulis du service affecté, qui a arrêté le cycle de ré-essai et permis à la base de données de terminer ses travaux exceptionnels * Latence confirmée du tableau de bord et utilisation de la connexion à la base de données sont revenues à des niveaux normaux Prochaines étapes Pour prévenir les récidives, Harness : * Ajouter le filtre de la plage de temps manquante aux requêtes de tableau de bord concernées afin que chaque lit seulement la période demandée * Remplacez les relevés immédiats par des relevés restreints. * Améliorer la détection en ajoutant des alertes sur l'utilisation de la connexion à la base de données et les coûts d'exécution par demande

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