Historique des pannes de Harness

1. 8 septembre 2026 à 21:52 UTCinvestigating

   Nous enquêtons actuellement sur cette question.

2. 8 septembre 2026 à 22:53 UTCinvestigating

   Nous poursuivons nos recherches sur le problème.

3. 8 septembre 2026 à 23:31 UTCinvestigating

   Nous continuons d'enquêter sur cette question.

4. 8 septembre 2026 à 23:52 UTCidentified

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

5. 9 septembre 2026 à 00:29 UTCidentified

   Nous continuons de travailler sur une solution à ce problème.

6. 9 septembre 2026 à 00:39 UTCmonitoring

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

7. 9 septembre 2026 à 04:30 UTCresolved

   Cet incident a été résolu.

8. 9 septembre 2026 à 23:23 UTCpostmortem

   ### Summary On September 8, 2026, customers in Prod 1 and Prod 2 experienced elevated platform latency and pipeline failures. The issue was caused by a regression in a newly released capability that triggered cascading failures under high load. Because the capability was behind a feature flag, it was quickly disabled, and service was restored after a brief monitoring period.  ### Customer Impact * Customers encountered slowness and failures during pipeline execution and UI operations. Some API calls returned errors or timed out. * No data loss or corruption occurred. ### Root Cause The new capability introduced a regression that created contention on a shared backend resource used by multiple Harness components. This saturated the shared platform infrastructure and caused the cascading failures. ### Mitigation * Disabled the capability across all environments * Temporarily increased platform capacity to restore stability ### Next Steps To prevent recurrence, Harness will: 1. **Permanently fix the capability** by profiling and eliminating the sub-optimal code path and query 2. **Improve detection** by enhancing alerting for resource-intensive queries on high-frequency platform paths

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

1. 5 septembre 2026 à 09:40 UTCinvestigating

   Nous enquêtons actuellement sur cette question.

2. 5 septembre 2026 à 09:40 UTCresolved

   Cet incident a été résolu.

3. 9 septembre 2026 à 18:22 UTCpostmortem

   ## **Summary** Between 12:34am PST and 12:38am PST on 5th September, the Delegate service manager experienced some elevated exceptions when attempting to write to the database. Consequently, delegate connections were dropped, causing them to disconnect. Delegate automatically re-attempts registration back to the `delegate service manager`  and majority of the delegates got connected back after the incident. For Docker and ECS delegates the automatic restart is not enabled unless these delegates have health monitoring enabled. For these delegates a manual restart is needed and was recommended.  Post restart the delegate would re-connect and the issue was resolved. ## **Root cause** On Prod2 cluster we identified a performance bottleneck in the delegate service that, under certain conditions, can increase database write latency and delay heartbeat processing which leads to delegates being disconnected. ## **Impact** All K8s delegates and \`Docker/ECS\` delegates got connected back immediately within 4 mins and started to function normally. The impact can be scoped to those specific types of delegates that didn’t have health monitoring enabled.  ## **Remediation** * Immediate: We have added additional monitoring and increased resources for handling the influx of traffic.  * Permanent: We have identified a hotspot in the code that can cause high latency when writing to a database which we are actively working on resolving.  ## **Action Items** To prevent such issues from happening again, Harness will work on the following: 1. Increased targeted monitoring and alerting to initiate timely mitigation and prevent this from happening again. 2. Fix the identified delegate service managers database client reconnect failures 3. Fix the hotpots that can cause query latency.

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

1. 3 septembre 2026 à 10:00 UTCinvestigating

   L'exécution du pipeline est bloquée dans Prod1. Nous enquêtons sur la question.

2. 3 septembre 2026 à 10:28 UTCmonitoring

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

3. 3 septembre 2026 à 11:40 UTCresolved

   Cet incident a été résolu.

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

1. 28 août 2026 à 07:04 UTCinvestigating

   Nous enquêtons actuellement sur cette question.

2. 28 août 2026 à 07:16 UTCidentified

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

3. 28 août 2026 à 07:29 UTCmonitoring

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

4. 28 août 2026 à 07:35 UTCresolved

   Cet incident a été résolu.

5. 2 septembre 2026 à 22:15 UTCpostmortem

   Résumé Entre le 27 et le 28 août 2026, les clients ont connu un problème où certains pipelines, déploiements et ressources connexes apparaissaient comme non trouvés dans l'interface utilisateur Harness et l'API, même si les données sous-jacentes étaient demeurées intactes. (en milliers de dollars) Le problème s'est posé lors d'une mise à jour prévue de l'infrastructure interne qui a affecté la communication entre les services de plate-forme interne. Par conséquent, les demandes qui dépendaient de la résolution du compte, de l ' organisation et de la portée du projet n ' ont pas pu être réglées avec succès, ce qui a conduit à une erreur dans les réponses qui n ' ont pas été rendues aux clients des entités existantes. (en milliers de dollars) L'ingénierie a identifié le problème, repoussé le changement et rétabli le service normal. Aucune donnée client n'a été perdue ou supprimée pendant l'incident. (en milliers de dollars) La cause profonde Le problème a été causé par une erreur de configuration introduite lors d'une mise à jour du routage du service interne prévue dans Production. Un service de plate-forme interne chargé de résoudre le contexte de compte, d'organisation et de projet n'a pas pu valider les demandes d'autres services Harness après l'application du changement. Étant donné que cette étape de validation est nécessaire avant que de nombreuses entités ne lisent et que des mesures liées au pipeline puissent être prises, les demandes rejetées ont fait surface aux clients car il n'y avait pas d'erreurs pour les ressources qui continuaient d'exister normalement. La question se limitait à l'environnement de production touché et a été résolue en renouvelant le changement et en rétablissant la voie de communication précédente. (en milliers de dollars) Impact * Certains clients ont vu des pipelines, des déploiements et des entités connexes existants apparaître comme non trouvés dans l'interface utilisateur et l'API. * Certaines opérations liées au pipeline, y compris la progression de l'exécution, les démarrages déclenchés par le webhook, l'évaluation programmée du déclenchement et la liste des entités, ont été temporairement perturbées. * La question a affecté la disponibilité et la visibilité des entités existantes, mais elle n'a pas supprimé les données ni modifié la configuration des clients. * Aucun accès non autorisé n'a eu lieu, et aucune perte de données client n'a été observée. Réparation * **Immédiate :** Réinitialisé la mise à jour de la configuration de l'infrastructure et restauré le chemin de communication de service déjà en service. * **Validation du recouvrement:** Vérifié que les vérifications des entités touchées, les opérations de pipeline et les API dépendantes fonctionnaient normalement après le renversement. * ** Permanent :** Corrigé le traitement de configuration associé à la mise à jour de sorte que des problèmes similaires n'interfèrent pas avec l'authentification du service au service dans les futurs déploiements. Éléments d'action Pour éviter que de tels problèmes ne se reproduisent, Harness 1. Améliorer la validation de la configuration en améliorant les essais préalables au déploiement afin de vérifier la communication interne avant de déplacer le trafic de production. 2. Améliorer la surveillance et l'alerte des défaillances d'authentification interne afin que les problèmes puissent être détectés plus tôt. 3. Améliorer le traitement des erreurs de sorte que les défaillances de dépendance sont moins susceptibles d'apparaître aux clients comme ressources erreurs non trouvées.

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

1. 26 août 2026 à 08:38 UTCinvestigating

   Nous enquêtons actuellement sur un problème signalé dans les pipelines IACM dans les grappes de harnais Prod-1, Prod-2, Prod-4 et EU1.

2. 26 août 2026 à 08:43 UTCinvestigating

   Nous continuons d'enquêter sur cette question.

3. 26 août 2026 à 09:05 UTCmonitoring

   Nous avons repris le changement qui a causé cette question dans tous les groupes.

4. 26 août 2026 à 09:10 UTCresolved

   Cet incident a été résolu.

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

1. 24 août 2026 à 00:57 UTCinvestigating

   Nous enquêtons actuellement sur cette question.

2. 24 août 2026 à 01:01 UTCinvestigating

   Nous enquêtons actuellement sur les rapports selon lesquels l'interface utilisateur Gestion des fonctionnalités et expérimentation (FME) ne peut pas être chargée. Les clients qui tentent d'accéder à la console FME peuvent rencontrer des erreurs ou des pages non-répondantes. L'évaluation des panneaux et le trafic SDK ne seraient pas affectés. Une nouvelle mise à jour suivra sous peu.

3. 24 août 2026 à 01:08 UTCmonitoring

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

4. 24 août 2026 à 01:12 UTCresolved

   Cet incident a été résolu.

5. 27 août 2026 à 23:36 UTCpostmortem

   Résumé * À partir de **23:42 UTC** le 23 août 2026, plusieurs clients FME ont signalé des défaillances dans le chargement de l'interface utilisateur FME. * FME UI Artifacts servis à partir du CDN a expiré en raison d'une politique de conservation, ce qui a causé FME UI de ne pas charger. * Toute demande d'affichage change par l'API, la livraison de changement et le pipeline de données continue de fonctionner sans interruption. La cause profonde * L'interface utilisateur FME est fournie par un CDN. Les artefacts de l'interface utilisateur ont été expulsés en raison d'une politique de rétention, ce qui a fait que l'interface utilisateur n'a pas pu charger tous les utilisateurs. Impact * L'interface utilisateur FME n'a pas pu charger tous les utilisateurs dans tous les environnements de production. Qu'est-ce qui n'a pas été touché ? * Fonctionnalité SDK et évaluation du drapeau d'exécution * Appels API Admin * Données de configuration du drapeau client * Aucune perte de données n'est survenue Réparation * L'interface utilisateur FME a été restaurée dans le CDN par un déploiement * Récupération confirmée dans tous les environnements de production avant la fermeture de l'incident. Éléments d'action * Améliorer la politique de rétention des biens de sorte que la version actuellement en activité ne soit jamais soumise à l'expulsion.

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

1. 20 août 2026 à 15:37 UTCinvestigating

   Nous enquêtons actuellement sur cette question.

2. 20 août 2026 à 16:05 UTCinvestigating

   La lenteur peut causer l'un ou l'autre des symptômes suivants: - Pipelines ne commençant pas - Retards dans l ' exécution - Les pipelines étant annulés en raison de délais

3. 20 août 2026 à 16:22 UTCinvestigating

   Notre fournisseur de cloud est confronté à un incident actif et nous suivons.

4. 20 août 2026 à 16:32 UTCinvestigating

   Nous continuons d'enquêter sur cette question.

5. 20 août 2026 à 16:50 UTCidentified

   Notre fournisseur de cloud a confirmé un incident continu touchant plusieurs régions. Les pipelines d'exploitation n'ont pas subi de défaillances en conséquence, bien que certains utilisateurs puissent continuer de connaître une lenteur. Nous surveillons la situation de près et fournirons des mises à jour à mesure que de plus amples renseignements seront disponibles.

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

   Nous observons des latences améliorées dans l'ensemble de la chaîne après la correction mise en place par notre fournisseur de cloud. Nous continuons de suivre de près la situation et nous fournirons d'autres mises à jour au besoin. Nous avons noté des exécutions bloquées pour CI pour deux clients, que nous enquêtons

7. 20 août 2026 à 19:23 UTCresolved

   Cet incident a été résolu.

8. 26 août 2026 à 04:57 UTCpostmortem

   # Résumé Le 20 août 2026, à partir d'environ 15h00 UTC, la plateforme Harness a connu une dégradation des performances généralisée dans tous les environnements de production. Les exécutions de pipelines qui se terminent normalement en deux minutes environ ont pris de sept à dix minutes. La prestation continue, l'intégration continue, l'orchestration des pipelines et la gestion des fonctionnalités et l'expérimentation ont tous été touchés. Google Cloud Platform a connu un incident multi-produits dans la région de us-west1 affectant Bigtable, Compute Engine, Google Kubernetes Engine et les I/S à disques persistants. La dégradation a fait passer la latence d'exploitation de la base de données d'environ 2 ms à plus de 10 ms au 95e percentile, ce qui a entraîné un décalage dans le traitement des messages et une propagation à tous les services qui dépendent de l'accès opportun à la base de données. (en milliers de dollars) # Impact C'était une dégradation, pas une panne. Les pipelines ont continué d'être exécutés et achevés avec succès; ils étaient lents plutôt que défaillants. Aucune donnée n'a été perdue, et aucun travail client n'a été abandonné à la suite de cet incident. * La cause de la mort L'infrastructure de production de Harness dans les environnements touchés fonctionne sur les disques persistants de Google Cloud Platform dans la région de us-west1. Lorsque cette couche de stockage s'est dégradée, l'effet s'est propagé à travers la plate-forme dans une chaîne prévisible: **Dégradation des E/S à disque persistant en nous-Ouest1.** Google Cloud Platform a connu un incident multi-produits affectant Bigtable, Compute Engine, Google Kubernetes Engine, et des performances de disques persistants. Il s'agissait d'une défaillance de l'infrastructure dans l'environnement du fournisseur, en dehors du contrôle de Harness. * Les actions préventives** Bien que Harness ne puisse pas empêcher une défaillance de l'infrastructure du fournisseur de cloud. Les actions ci-dessous visent à en détecter un plus rapidement et à être mieux placées pour agir. **Action** Oui. Continuer d'effectuer des essais préalables de routine sur les défaillances de la base de données inter-régions ciblées, comme cela a été fait au cours de cet incident, afin de vérifier l'état de préparation aux défaillances plutôt que d'en tenir compte. Évaluer l'état de préparation à l'échec de plusieurs régions pour les scénarios futurs dans lesquels la latence interrégionale serait inacceptable

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

1. 20 août 2026 à 14:32 UTCinvestigating

   Nous enquêtons actuellement sur cette question.

2. 20 août 2026 à 14:47 UTCidentified

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

3. 20 août 2026 à 14:56 UTCmonitoring

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

4. 20 août 2026 à 15:02 UTCresolved

   Cet incident a été résolu.

5. 23 août 2026 à 21:45 UTCpostmortem

   Résumé Le 20 août 2026, entre 10:24 et 14:55 UTC, un sous-ensemble de FME écrit a échoué. Les écrits faits à partir de l'interface utilisateur FME et les écrits faits avec les jetons d'accès Harness \(PAT et SAT\) n'ont pas été affectés. L'évaluation du drapeau de course a continué à fonctionner normalement. La question a été atténuée par le retour d'un changement récent d'authentification dans un service de gouvernance partagée, et les écrits touchés sont retournés à la normale par 14:55 UTC. Statut: [https://status.harness.io/incidents/rhthgm7d5dkz] (https://status.harness.io/incidents/rhthgm7d5dkz) Cause profonde Un changement dans la façon dont un service de gouvernance partagée a authentifié les appels entrants a entraîné le rejet de certains écrits de la FME. Ceux-ci ont utilisé des justificatifs de service à service que le service de gouvernance ne pouvait plus vérifier après le changement. FME fait face à une défaillance de gouvernance pour le client comme HTTP 499, le même statut utilisé lorsqu'une politique de gouvernance refuse intentionnellement un changement. Parce que 499 est une réponse valide et attendue dans ce chemin de refus, les échecs ne ressemblaient pas à une panne sur nos alertes, et l'incident a été identifié à partir des rapports des clients plutôt que de la détection interne. Impact * Un sous-ensemble d'écritures FME a échoué pendant la fenêtre, principalement celles faites à l'aide des anciennes clés de l'API Split ou de la planification des demandes de modification. * Les écrits faits à partir de l'interface utilisateur FME n'ont pas été touchés. * Les écrits utilisant les jetons d'accès Harness \(PAT et SAT\) n'ont pas été touchés. * L'évaluation du drapeau de course s'est poursuivie normalement. * Aucune perte de données n'est survenue. Échec écrit ne s'est pas appliqué. (en milliers de dollars) Réparation Réversion du changement d'authentification des services de gouvernance. Les écrits touchés sont revenus à la normale immédiatement. Éléments d'action Pour éviter que ces problèmes ne se reproduisent, * Harness retournera une erreur distincte \(not 499\) lorsqu'une écriture échoue parce que la gouvernance n'a pas pu être évaluée, donc il n'est pas confondu avec un déni de politique intentionnel. * Ajouter l'alerte sur l'évaluation de la gouvernance elle-même, plutôt que de compter sur le code d'état du client. * Développer le soutien à l'authentification pour les évaluations des politiques. * Étendre la couverture automatisée pour d'autres scénarios d'écriture.

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

1. 19 août 2026 à 13:22 UTCinvestigating

   Nous enquêtons actuellement sur cette question.

2. 19 août 2026 à 14:55 UTCinvestigating

   Nous continuons d'enquêter sur cette question.

3. 19 août 2026 à 15:13 UTCidentified

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

4. 19 août 2026 à 15:22 UTCmonitoring

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

5. 19 août 2026 à 15:33 UTCmonitoring

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

6. 19 août 2026 à 16:07 UTCresolved

   Cet incident a été résolu.

7. 26 août 2026 à 17:20 UTCpostmortem

   ** Résumé** Le 19 août 2026, entre 12 h 35 et 17 h 29 UTC, le service Harness Application Security a connu une perturbation importante touchant à la fois la console orientée vers le client et le pipeline d'ingestion de données dans les régions de SaaS Production et US1. (en milliers de dollars) ** Cause de la mort** Le service de configuration interne qui fournit les paramètres d'exécution à presque tous les autres composants est devenu surchargé et est entré dans un cycle de redémarrage répété. Parce que tant de services en dépendent, les effets étaient larges : les pages consoles telles que les politiques de protection, les vues de posture, les journaux d'activités, l'inventaire des API et la politique personnalisée n'ont pas réussi à charger ou à sortir, et le traitement en aval s'est arrêté en attendant la configuration qu'il ne pouvait obtenir. # ** Impact client** **Dimensions******Détail** - Oui. Console \(UI\) impact.De nombreuses pages n'ont pas été chargées ou chronométrées, y compris les politiques de protection, les pages d'événements de posture et les vues de posture à l'intérieur des tableaux de bord et des pages d'information, les requêtes de journal d'activités, les écrans d'inventaire d'API, la politique personnalisée, et les vues et widgets de données sensibles. Autres L'impact de l'ingestion Le traitement de la télémétrie de sécurité s'est fortement dégradé et, dans certains chemins, s'est arrêté entièrement. Le retard des consommateurs a augmenté au cours des étapes de normalisation, de regroupement, de détection des anomalies, de génération et de traitement connexe. Autres Perte de données Un sous-ensemble de télémétrie ingéré pendant la perturbation a été définitivement abandonné. Autres (en milliers de dollars) **Mitigation** Plusieurs mesures d'atténuation intermédiaires supplémentaires CPU et mémoire, seuils de contrôle de santé assouplis, un redémarrage de la base de données et un plus grand pool de connexions ont amélioré le problème. L'invalidation de la nouvelle caractéristique dans les deux régions touchées a permis de rétablir fortement et durablement le débit. L'incident a été résolu à 17h29 UTC. (en milliers de dollars) * Les actions préventives** Les mesures suivantes sont engagées et suivies à l'interne jusqu'à leur achèvement. La fonction qui a déclenché cet incident demeure désactivée et ne sera pas réactivée tant que les travaux ci-dessous ne seront pas terminés et validés. **Action** Oui. C'est vrai. OPtimiser le code en harmonisant les paramètres tels que l'éviction et la rétention de cache , évaluer la pagination basée sur le curseur pour la récupération de règles en vrac lorsque les nombres de règles grandissent Ajouter un index de base de données spécialement conçu pour le modèle d'accès à la portée des services. Remédier à la sémantique de récupération de pipeline afin que les consommateurs rejouent en toute sécurité après la perte de marqueur de position au lieu de sauter l'arriéré Un mandat a été mis en place pour les configurations qui modifient les modèles de demandes en aval : regroupement à faible volume, puis à moyen volume, puis à grand volume. Ajouter une protection contre la contre-pression et contre la concurrence au service de configuration : rupture de circuit, files d'attente limitées et isolation du temps libre. Améliorer l'observabilité en instrumentant des mesures plus détaillées

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

1. 6 août 2026 à 14:30 UTCinvestigating

   Nous enquêtons actuellement sur un volet Harness qui connaît des problèmes. Nous nous efforçons d'identifier la cause et de rétablir les opérations normales dès que possible.

2. 6 août 2026 à 14:32 UTCinvestigating

   Nous continuons d'enquêter sur cette question.

3. 6 août 2026 à 15:46 UTCidentified

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

4. 6 août 2026 à 16:01 UTCresolved

   Cet incident a été résolu.

5. 10 août 2026 à 18:24 UTCpostmortem

   Résumé Les clients des groupes Prod1, Prod2 et Prod3 \(US\) ont subi des défaillances lors du chargement des tableaux de bord SEI 2.0 le 6 août 2026, de 7h22 à 9h03. Les clients appelant l'API SEI 2.0 ont également connu des défaillances similaires. Aucune donnée client n'a été perdue, et l'ingestion de toutes les données d'intégration a continué à fonctionner sans interruption. Les clients SEI utilisant 1.0 n'ont pas été touchés. La cause profonde L'incident a été causé par l'épuisement des ressources sur les nœuds servant aux requêtes. Cette dégradation des ressources s'est développée selon un modèle qui n'a pas franchi les seuils d'alerte existants suffisamment tôt pour fournir un avertissement suffisant ou permettre l'atténuation avant que l'impact du client ne se produise. Impact Les clients des groupes Prod1, Prod2 et Prod3 \(US\) n'ont pas pu charger les tableaux de bord SEI 2.0 pendant la fenêtre d'incident. **Durée:** 6 août 2026, 7h22 PDT – 9h03 PDT \(~1 heure 41 minutes\) Qu'est-ce qui n'a pas été touché ? * ingestion et traitement des données * SEI 1.0 clients * Intégrations et flux de métadonnées Aucune donnée client n'a été perdue. Réparation Après avoir identifié la cause fondamentale, notre équipe a pris des mesures correctives immédiates en ajoutant la capacité de restaurer les systèmes touchés. Les services ont été entièrement récupérés, et tous les tableaux de bord ont repris l'exploitation normale à 9h03 PDT. Éléments d'action Pour éviter que de tels problèmes ne se reproduisent, Harness est/a Des mises à jour proactives des capacités ont été appliquées pour éviter que ce problème ne se reproduise Surveillance et alerte accrues D'autres mesures de surveillance et d'alerte ont été mises en place pour détecter les anomalies dès le départ, en mettant l'accent sur un indicateur de premier plan, qui, dans ce cas, était l'épuisement de la réserve de fils, avant qu'ils ne puissent influer sur la disponibilité du tableau de bord et le rendu des données. #### Système en cours Nous travaillons avec notre fournisseur pour appliquer un correctif pour corriger complètement ce problème et d'autres.

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

1. 6 août 2026 à 13:50 UTCmonitoring

   Nous surveillons les pipelines bloqués dans le prod2. Les nouvelles exécutions passent alors que nous surveillons constamment les services.

2. 6 août 2026 à 16:58 UTCmonitoring

   Nous surveillons les pipelines bloqués dans le prod2. Pour les clients qui voient encore des pipelines bloqués, nous vous demandons d'avorter et de redémarrer.

3. 6 août 2026 à 18:21 UTCresolved

   Cet incident a été résolu.

4. 17 août 2026 à 18:40 UTCpostmortem

   Résumé Le 6 août 2026 \(matin PDT\), certains clients exploitant des pipelines dans l'environnement de production de Prod2 ont observé des exécutions de pipelines qui ont cessé de progresser — étapes qui n'ont pas progressé et n'ont pas produit d'autres sorties ou mises à jour de l'état. Le problème a été signalé par les clients touchés. Les ingénieurs de Harness ont identifié la cause, atténué l'impact, et les exécutions de pipeline sont revenues à l'exploitation normale. La question a été causée par une expression de pipeline autoréférentielle. Un webhook Git a déclenché un pipeline qui faisait référence au contenu de la charge utile du webhook, et la charge utile elle-même contenait d'autres copies de cette même expression. Chaque ronde de résolution d'expression a donc produit plus d'expressions à résoudre, doublant chaque fois la quantité de travail. Cela a épuisé les ressources de l'instance de service traitant cette exécution, et d'autres exécutions assignées à la même instance ont été incapables de progresser pendant qu'il était dans cet état. ## **Impact** Pendant la fenêtre de l'incident \(environ 6h11 à 11h23 PDT le 6 août 2026\): * Les exécutions de pipelines de certains clients sur Prod2 ont arrêté à mi-exécution et n'ont pas progressé. * Les exécutions touchées n'ont pas produit de nouveaux résultats ni mis à jour de l'état d'avancement, et ont dû être avortées et réactivées après l'atténuation. * Le comportement était limité aux exécutions en cours de traitement par l'instance de service concernée - les pipelines traités par d'autres instances continuaient de s'exécuter normalement. Il n'y a pas eu de perte de données**. Les définitions des pipelines, l'historique d'exécution et l'état stocké n'ont pas été modifiés. La majorité des pipelines de Prod2 ont continué à être exécutés avec succès tout au long de l'incident; l'impact principal a été que certaines exécutions en vol n'ont pu être achevées et ont dû être réexécutées une fois la question atténuée. ## **La cause de la mort** Les pipelines Harness supportent les expressions qui sont résolues au moment de l'exécution — par exemple, une expression qui insère le contenu de la charge utile Git webhook qui a déclenché le pipeline. Dans ce cas, un message de commit Git contenait le texte littéral de l'expression de charge utile elle-même, deux fois, et le pipeline faisait référence à cette même expression de charge utile. Parce que le message de commit fait partie de la charge utile webhook, résolution de l'expression insérée la charge utile entière — y compris les deux copies littérales de l'expression portée dans le message de commit. Ces copies nouvellement insérées ont ensuite été traitées comme des expressions à résoudre, et chaque passe a inséré deux autres copies complètes de la charge utile. La taille de la valeur en cours de traitement et le travail requis pour la traiter ont donc doublé sur chaque passage et ont augmenté de façon exponentielle plutôt que convergente. Harness a une protection visant à arrêter exactement cela : la résolution d'expression est limitée par une profondeur maximale de nidification, au-delà de laquelle la résolution s'arrête et le pipeline échoue avec une erreur explicite. Un défaut dans cette sauvegarde signifiait que la limite n'était pas appliquée dans ce cas précis d'autoréférentiel, de sorte que la résolution n'a pas été vérifiée. La résolution d'expression fonctionne en ligne sur les fils qui commencent les étapes du pipeline. Comme chaque passe consommait progressivement plus de mémoire et de CPU sans jamais terminer, l'instance de service exécutant ce travail a cessé de progresser, et chaque exécution attribuée à cette instance s'est arrêtée — ce que les clients ont rapporté. * **Mitigation** Harness a pris les mesures d'atténuation immédiates suivantes : * Identifié le pipeline et le modèle d'expression responsable de la résolution fugueuse. * Il a arrêté l'instance de service concernée pour qu'elle n'entreprenne aucun autre travail. Les autres cas sains ont pris et traité les exécutions en attente normalement. * Confirmé que les exécutions de pipelines sont revenues à la normale et ont fermé l'incident. Ces actions ont rétabli le comportement normal d'exécution du pipeline et résolu l'impact face au client. ## **Actions** Afin de réduire le risque de récidive et d'améliorer la détection, les mesures suivantes sont mises en œuvre à différents stades: * Correction du défaut dans la protection de la profondeur d'expression et de la détection de boucle de sorte que les expressions autoréférentielles soient capturées et échouent rapidement avec une erreur claire au lieu de consommer des ressources sans lien. * Empêcher les expressions de charge utile d'être résolues à partir du contenu de charge utile de déclenchement, en supprimant entièrement le chemin autoréférentiel. * Resserrer la profondeur de nidification maximale d'expression et évaluer la détection explicite des boucles en plus de la limite de profondeur existante. * Améliorer les tests automatisés dans les environnements de préproduction qui reproduisent les modèles d'expression autoréférentiels et vérifier que la sauvegarde les détecte et les arrête. * Ajouter la surveillance de cette tendance dans les exécutions par pipeline afin qu'elle soit détectée de manière proactive.

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

1. 4 août 2026 à 12:07 UTCinvestigating

   We are currently investigating this issue.

2. 4 août 2026 à 12:17 UTCinvestigating

   We are continuing to investigate this issue.

3. 4 août 2026 à 13:00 UTCinvestigating

   We have identified the issue and started to implement the fix , prod2 is restored.

4. 4 août 2026 à 13:09 UTCinvestigating

   We are continuously rolling out fixes to all Clusters, Prod EU1 has been resolved.

5. 4 août 2026 à 13:16 UTCinvestigating

   We are continuously rolling out fixes to all Clusters, Prod3 has been resolved.

6. 4 août 2026 à 15:28 UTCresolved

   This incident has been resolved.

7. 6 août 2026 à 17:02 UTCpostmortem

   # Executive Summary On August 4, 2026, between approximately 3:36 PM and 9:00 PM IST, customers using Infrastructure as Code Management \(IaCM\) on Prod0 and Prod1 were unable to access the Variable Sets settings page. The page rendered blank with no error message, and customers with Variable Sets attached to their workspaces could not view or manage them for the duration of the incident. Prod2, Prod3, and EU1 were not affected. Separately, during the same window, a scheduled maintenance action caused the IaCM settings tab to temporarily disappear across all environments. This was identified and reversed within the incident bridge call before significant customer impact occurred. We deployed a hotfix that restored full access to the Variable Sets page on Prod0 and Prod1 the same evening, and we are implementing permanent safeguards described below to prevent this class of issue from recurring. # Impact * Customers with the Variable Sets feature enabled on Prod0 and Prod1 were unable to view or manage Variable Sets for approximately 5–6 hours. * No data was lost or corrupted, this was a UI routing failure only; underlying Variable Sets data and configuration were not affected. * Prod2, Prod3, and EU1 were not affected by this issue. * A secondary issue, a scheduled feature flag operation caused the IaCM settings tab to temporarily disappear across all environments during the incident bridge call. This was identified and reversed within minutes. External customer exposure for this secondary issue is still being confirmed. # Root Cause A platform routing change released on July 18, 2026 updated how IaCM settings pages are resolved in the user interface. As part of that change, any settings page that had not been explicitly re-registered in the new routing structure became unreachable. The Variable Sets page had not been re-registered under the new routing structure, making it inaccessible in the environments where the routing change had been deployed — Prod0 and Prod1. Because the failure occurred at the routing layer rather than within the page itself, the page rendered blank with no visible error rather than showing a clear failure message. # Remediation ## Immediate We deployed a hotfix that re-registered the Variable Sets page in the updated routing structure, restoring access for all affected customers on Prod0 and Prod1. ## Permanent We are adding automated end-to-end tests that navigate to settings pages with relevant feature flags enabled, configured as a required gate in our release pipeline. We are also documenting and enforcing the routing constraint through static analysis so that settings pages are never inadvertently left out of the routing structure during future platform changes. # Action Items To prevent such issues from happening again, 1. Enhance automated tests, that navigate to settings pages with relevant feature flags enabled, configured as a blocking gate in the release pipeline, so this class of regression is caught before it reaches production. 2. Establish an explicit checklist step for future platform-wide architectural changes that verifies all existing settings pages remain accessible in the updated routing structure before the change is promoted to production.

1. 3 août 2026 à 03:08 UTCinvestigating

   Nous enquêtons actuellement sur cette question.

2. 3 août 2026 à 03:37 UTCmonitoring

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

3. 3 août 2026 à 05:53 UTCresolved

   Cet incident a été résolu.

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

1. 31 juillet 2026 à 20:22 UTCinvestigating

   Nous enquêtons actuellement sur cette question.

2. 1 août 2026 à 02:41 UTCidentified

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

3. 1 août 2026 à 05:45 UTCmonitoring

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

4. 1 août 2026 à 09:11 UTCresolved

   Cet incident a été résolu.

5. 21 août 2026 à 04:19 UTCpostmortem

   Résumé Entre le 25 juillet et le 4 août 2026, les tableaux de bord de l'exécution des pipelines et les pages d'aperçu des grappes Harness Prod 2 et Prod 3 présentaient des données qui se situaient entre derrière le temps réel. Les pipelines eux-mêmes ont continué de construire, de déployer et d'exécuter normalement tout au long; la question a été limitée à la rapidité avec laquelle les enregistrements d'exécution ont été copiés dans la base de données qui sert de reporting et de tableau de bord. (en milliers de dollars) **Aucune donnée client n'a été perdue.** Chaque enregistrement affecté est resté stocké durablement et a été rejoué dans la datastore analytique une fois la limitation sous-jacente supprimée. Harness a migré les clusters touchés vers une version horizontalement évolutive et soutenue par la file d'attente du composant de réplication le 1er août 2026 et a complété les remblayages de données ciblés pour tous les comptes touchés. * La cause de la mort Harness maintient un composant de saisie de données de changement qui reproduit continuellement les enregistrements d'exécution de pipelines de la datastore opérationnelle primaire en une datastore de séries chronologiques séparée optimisée pour les tableaux de bord et les requêtes de rapport. Tableaux de bord lus exclusivement à partir de la datastore analytique. Lorsque la réplication tombe derrière, les tableaux de bord rendent une vue précise mais plus ancienne du monde, tandis que l'exécution elle-même n'est pas affectée. Ceci a été causé par une augmentation soutenue et nette du volume d'écriture de base de données d'un autre module de plate-forme Harness partageant le même chemin de réplication a dépassé le plafond de débit de l'ancienne version mono-instance de ce composant toujours en cours d'exécution dans Prod 2 et Prod 3. Un arriéré s'est formé et a augmenté. (en milliers de dollars) (en milliers de dollars) * Les actions préventives** Harness a mené à bien ou s'est engagé à prendre les mesures suivantes pour prévenir ces problèmes. **Action** Oui. Finissez l'alerte de retard de réplication afin que tout retard dépassant un seuil défini soit notifié. Ajouter un panneau de décalage de réplication au panneau de surveillance standard de la plate-forme afin que la santé du pipeline soit visible sur appel par défaut. Réduisez l'amplification de l'écriture à partir de modules co-titulaires en limitant le débit de chaque module ou en filtrant l'entité sur le flux de réplication

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

1. 31 juillet 2026 à 13:48 UTCinvestigating

   Nous enquêtons actuellement sur cette question.

2. 1 août 2026 à 02:34 UTCidentified

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

3. 1 août 2026 à 02:44 UTCmonitoring

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

4. 1 août 2026 à 23:49 UTCresolved

   Cet incident a été résolu.

5. 13 août 2026 à 00:50 UTCpostmortem

   Résumé Le 31 juillet 2026, les chargements d'artefacts effectués par pipeline dans le cluster EU1 ont commencé à échouer avec une erreur d'authentification. Les chargements initiés manuellement \(en dehors d'un pipeline\) n'ont pas été affectés, et la capacité de récupérer des artefacts existants \(downloads\) n'a pas été affectée, ce qui a été isolé du chemin de chargement spécifique du pipeline dans un cluster. # **Impact** * Les téléchargements d'artefact effectués par pipeline dans le cluster EU1 ont échoué avec une erreur d'authentification pendant environ 4 heures et 34 minutes. * La récupération des artefacts existants \(téléchargements\) n'a pas été affectée. * Le téléchargement manuel d'objets à l'extérieur d'un pipeline n'a pas été affecté. * D'autres groupes/régions n'ont pas été touchés par cette question. La cause de la mort La composante responsable de la manutention des chargements d'artefacts en pipeline est distribuée sous forme d'image de conteneur. Dans le cluster EU1, cette image est extraite d'un registre interne qui reflète une source d'image publique; dans d'autres clusters, la même image est extraite directement de la source publique. Une erreur de publication dans notre processus de publication a fait publier une nouvelle compilation de ce composant en utilisant une étiquette de version déjà utilisée, plutôt que d'être assignée à une nouvelle version unique. Par conséquent, deux images différentes ont fini par être associées à la même étiquette de version dans la source publique. Notre registre interne reflète les images de la source publique par un processus de réplication automatisé. En raison de la façon dont cette réplication a été déclenchée, elle a copié l'image \(earlier\) originale associée à cette étiquette de version plutôt que celle corrigée. Cela signifie que le cluster EU1 — qui tire du miroir intérieur — a fini par utiliser une image différente et défectueuse que d'autres clusters, qui tire directement de la source publique et a donc reçu l'image corrigée. L'image défectueuse contenait un problème d'authentification qui a causé l'échec des téléchargements de pipelines. ♪ **Mitigation** * Réinitialisé le compte touché à la dernière version connue de la composante de téléchargement, rétablissant immédiatement les téléchargements de pipeline. * Publié une version corrigée et permanente de la composante pour résoudre le problème dans tous les groupes. ** Prochaines étapes** (en milliers de dollars) * Correction de l'étape de téléchargement pour supprimer le défaut sous-jacent lié au conteneur qui a rendu ce mode de défaillance possible. * Mettez à jour notre pipeline de publication pour ce composant afin que la publication d'une image ne puisse jamais écraser une version existante — chaque publication doit créer une nouvelle version distincte à l'avenir.

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

1. 30 juillet 2026 à 05:59 UTCinvestigating

   Résumé Nous sommes confrontés par intermittence à des problèmes de connectivité réseau avec notre Build VM incapable de se connecter à des ressources externes. Nous enquêtons actuellement sur la question.

2. 30 juillet 2026 à 08:07 UTCmonitoring

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

3. 30 juillet 2026 à 08:07 UTCmonitoring

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

4. 31 juillet 2026 à 03:22 UTCresolved

   Cet incident a été résolu.

5. 7 août 2026 à 19:32 UTCpostmortem

   Résumé À partir du 4 août 2026, les coureurs de CI dans les régions nous-west1 et nous-central1 ont vécu des temps de connexion intermittents d'environ 134 secondes lorsqu'ils ont atteint des services externes tels que GitHub et Bitbucket sur des passerelles réseau sortantes. Impact * Les coureurs d'IC dans les régions touchées ont connu des temps de connexion intermittents d'environ 134 secondes lorsqu'ils ont atteint des services externes \(p. ex., GitHub, Bitbucket\) sur nos passerelles réseau sortantes. * La question était intermittente plutôt que constante — les connexions ont réussi sous charge normale, et les défaillances ont été groupées pendant les périodes de volume de trafic sortant élevé. * Aucune donnée n'a été perdue ou corrompue. Il s'agissait d'un problème de connectivité et de capacité de réseau, et non d'intégrité des données. * nous-ouest1 et nous-central1 étions les régions touchées; d'autres régions n'ont pas été touchées par cette question. La cause profonde (en milliers de dollars) Notre balanceur de charge distribue le trafic sortant sur plusieurs passerelles NAT en utilisant une méthode de hachage basée sur les détails de connexion \(adresse source/destination et port\). Pour toute connexion unique, ces détails restent constants pour la vie de cette connexion. Nous avons eu une poussée soutenue du trafic pendant quelques secondes qui a encombré les passerelles (en milliers de dollars) Éléments d'action Pour éviter que ces problèmes ne se reproduisent, Harness, Augmenter la capacité de connexion sortante sur nos passerelles NAT en fournissant des interfaces réseau externes supplémentaires, donnant à chaque passerelle un pool de connexions sensiblement plus grand qu'elle peut servir simultanément.

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

1. 27 juillet 2026 à 09:09 UTCinvestigating

   Nous enquêtons actuellement sur cette question.

2. 27 juillet 2026 à 09:22 UTCmonitoring

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

3. 27 juillet 2026 à 13:33 UTCresolved

   Cet incident a été résolu.

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

1. 27 juillet 2026 à 07:52 UTCinvestigating

   Nous enquêtons actuellement sur cette question.

2. 27 juillet 2026 à 08:13 UTCinvestigating

   Nous continuons d'enquêter sur cette question.

3. 27 juillet 2026 à 09:04 UTCidentified

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

4. 27 juillet 2026 à 09:05 UTCidentified

   Nous continuons de travailler sur une solution à ce problème.

5. 27 juillet 2026 à 09:07 UTCmonitoring

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

6. 27 juillet 2026 à 09:09 UTCmonitoring

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

7. 27 juillet 2026 à 13:33 UTCresolved

   Cet incident a été résolu.

8. 7 août 2026 à 18:15 UTCpostmortem

   # Summary During a recent production deployment, a defect in our internal deployment tooling caused two critical services   to run with incorrect, non-production configuration values in our production environment This led to a related set of four distinct symptoms: incorrect configuration behavior, intermittent login/access failures, a filestore access issue affecting one customer environment, and delayed pipeline status updates in the UI. ‌ We have identified and are implementing a permanent fix for the underlying configuration defect, and have already put in place resource and capacity changes that resolve the UI delay symptom. ‌ At no point during this incident were pipeline executions themselves lost, corrupted, or left in a stuck state. Where execution behavior was affected, it was limited to delays in status visibility, not in the underlying processing. # Incident Details ## Incorrect Production Configuration Values Applied Our engineering team confirmed a defect in the Service Manager deployment pipeline that caused certain production services to be deployed using configuration values intended for a different environment, rather than the correct production configuration. ‌ **Root Cause** ‌ The service responsible for fetching configuration overrides during deployment queries an internal API that returns a maximum of 1,000 results per request. The total number of services in the environment recently grew beyond that limit. As a result, any service beyond the first 1,000 returned was not included in the response, and the deployment pipeline silently fell back to default configuration values for those services. This is a confirmed pagination defect in the deployment tooling, not an issue with the configuration values themselves. ‌ **Resolution** ‌ Engineering has confirmed the mechanism and is implementing a permanent fix to remove this limit-related gap in the deployment pipeline. ## Intermittent Login / Access Failures During the Service Manager deployment referenced above, some users experienced intermittent login or access failures. Under normal operation, previously running instances should continue serving traffic without interruption while a new deployment is in progress. In this incident, that fallback behavior did not occur as expected, contributing to access failures during the deployment window. ## Filestore Access Issue A filestore access issue was identified that was specific to the Prod-3 environment and affected a single customer's environment. **Root Cause** This is related to an IAM / storage-bucket permission configuration on Service Manager, potentially triggered by rollback activity.  ## Delayed Pipeline Execution Status Updates in UI Some users observed that the pipeline execution graph in the UI was slow to refresh and did not reflect the latest status promptly. Importantly, this was a visibility delay only: there was no impact to actual pipeline executions, and no executions were stuck or failed as a result of this issue. **Root Cause** The pipeline execution graph relies on a message stream \(the orchestration log\) to receive status updates. During the incident window, consumer processing of this stream fell behind \(high consumer lag\), which delayed how quickly status updates reached the UI. This was caused by the fact that the underlying database was in the middle of a planned scaling operation at the same time, and a traffic spike during that window further exacerbated the delay. Users experienced this as apparent pipeline slowness, even though the underlying executions were running normally. **Resolution** We have increased resource capacity for the affected components to maintain more than 50% spare headroom going forward, reducing sensitivity to similar load spikes. This change has been implemented and is currently being validated as part of longer-term hardening for this part of the platform. # Impact Summary * Service Manager and License Manager ran with incorrect configuration values in the Prod-1 and Prod-3 environments. * Some users experienced intermittent login or access failures during the affected deployment window. * One customer environment in Prod-3 experienced a filestore access issue. * Users across affected environments saw delayed pipeline execution status updates in the UI; underlying pipeline executions continued to run correctly and were not lost, stuck, or corrupted. # Preventive Actions The following corrective and preventive actions have been identified. ‌ | **Corrective / Preventive Action** | | --- | | Correct the pagination limit in the configuration-lookup service so that all services are returned and evaluated, regardless of total count. | | Add safeguards so that a service which cannot retrieve its configuration fails safely \(e.g. alerts and blocks the deployment\) rather than silently falling back to non-production defaults. | | Increase Postgres and messaging-pipeline resource headroom \(target: greater than 50% spare capacity\) to reduce sensitivity to concurrent load and scaling events. | ‌ _We recognize the impact this incident had across multiple areas of the platform and appreciate your patience as we work through a complete resolution._

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

1. 22 juillet 2026 à 14:55 UTCinvestigating

   Nous enquêtons sur un problème touchant les tableaux de bord AIDI. Les utilisateurs peuvent connaître des temps de charge accrus ou des défaillances intermittentes lors de l'accès aux tableaux de bord. Notre équipe s'emploie activement à identifier la cause profonde et à rétablir des performances normales. Nous fournirons des mises à jour à mesure que de plus amples renseignements seront disponibles.

2. 22 juillet 2026 à 14:58 UTCidentified

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

3. 22 juillet 2026 à 15:25 UTCmonitoring

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

4. 22 juillet 2026 à 23:16 UTCresolved

   Cet incident a été résolu.

5. 10 août 2026 à 18:17 UTCpostmortem

   Résumé Les clients sur les clusters Prod1, Prod2 et Prod3 ont connu des défaillances de charge de widget intermittent et augmenté les temps de charge lors de l'accès aux tableaux de bord AIDI 2.0 le 22 juillet 2026. Tous les widgets n'ont pas été affectés simultanément la question se manifestant par des échecs sporadiques plutôt qu'une panne complète. Aucune donnée client n'a été perdue. Les clients SEI 1.0 n'ont pas été touchés. La cause profonde Au fil du temps, un processus de maintenance systématique de la base de données n'a pas fonctionné sur certaines tables de notre base de données analytique, ce qui a amené ces tables à accumuler un grand volume de métadonnées internes utilisées pour suivre les enregistrements supprimés. Lorsque la base de données a planifié des requêtes contre ces tables, elle a chargé toutes ces métadonnées accumulées en mémoire, ce qui a provoqué une utilisation de la mémoire sur les nœuds touchés à pic à plusieurs reprises. Ces pics répétés ont déclenché un mécanisme de sécurité automatique qui redémarre un noeud lorsqu'il détecte une pression de mémoire excessive, et les nœuds touchés ont commencé à redémarrer dans une boucle. Cela a causé des performances de requêtes intermittentes et dégradées sur les tableaux de bord AIDI 2.0 pour la durée de l'incident. Impact Les clients des clusters Prod1, Prod2 et Prod3 ont peut-être connu des pannes de charge de widget intermittentes ou des temps de charge accrus sur les tableaux de bord AIDI 2.0. **Durée:** 22 juillet 2026, 07:58 PDT – 16:16 PDT \(~8 heures 18 minutes\), avec des défaillances de widget intermittent; le système a été redémarré et sous surveillance active à partir de 08:25 PDT. Qu'est-ce qui n'a pas été touché ? * ingestion et traitement des données * SEI 1.0 clients * Intégrations et flux de métadonnées Aucune donnée client n'a été perdue. Réparation Lors de l'identification du problème, les nœuds de base de données touchés ont été redémarrés à 08h25 PDT, ce qui a rétabli la stabilité initiale. Nous avons continué à surveiller de près le système, et lorsque la dégradation intermittente a été observée par la suite, nous avons appliqué plusieurs corrections supplémentaires : * Paramètres de configuration de la base de données ajustés pour limiter la quantité de mémoire utilisée pour le traitement des métadonnées accumulées, et paramètres de planification des requêtes ajustés pour réduire la pression de mémoire. * Rang de tâches de nettoyage pour réduire l'arriéré de métadonnées accumulées sur les tables touchées. * Capacité accrue des nœuds de base de données touchés de fournir une salle de tête supplémentaire. Ces changements ont progressivement stabilisé le système, et l'incident a été complètement résolu à 16:16 PDT. Éléments d'action Pour prévenir les récidives, nous mettons en œuvre les mesures suivantes : 1. Nous avons mis à niveau le moteur qui inclut les améliorations sous-jacentes qui gèrent les pics de mémoire causés par les fichiers supprimés excessifs. 2. Nous avons déployé des travaux de compactage automatisés pour les tables nouvellement introduites afin d'empêcher la suppression de l'accumulation de fichiers à l'avenir.

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

1. 17 juillet 2026 à 17:16 UTCinvestigating

   Nous enquêtons actuellement sur cette question.

2. 17 juillet 2026 à 17:34 UTCidentified

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

3. 17 juillet 2026 à 18:12 UTCmonitoring

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

4. 17 juillet 2026 à 21:56 UTCresolved

   Cet incident a été résolu.

5. 4 août 2026 à 02:48 UTCpostmortem

   # Résumé Le 17 juillet 2026, à la suite d'un déploiement de code de routine, les clients des anciennes versions de délégation \(858xx et ci-dessous\) ont commencé à vivre des développements d'IC retardés sur les constructions hébergées par Harness Cloud en utilisant notre capacité de construction-queue globale. Les constructions touchées ont connu une pause inattendue pouvant aller jusqu'à environ 8 minutes à l'étape de « l'attente de l'infrastructure » avant de continuer, plutôt que de procéder à la sous-seconde prévue. La lenteur globale de la construction était intermittente. # Impact * Toutes les constructions d'IC étaient potentiellement retardées; l'impact était le plus prononcé pour les constructions sur l'infrastructure hébergée par Harness Cloud à l'aide de la fonction de lecture de construction globale. * Les constructions touchées ont connu une pause inexpliquée d'environ 8 minutes avant de continuer, suivie d'un « démarrage froid » plus lent puisqu'une fente de calcul pré-réservée n'était pas disponible. * Les comptes fonctionnant sur les nouvelles versions \(858xx et ci-dessus\) n'ont pas été touchés. * Aucune construction n'a complètement échoué à cause de ce problème, et aucune donnée n'a été perdue. Cause racine La cause profonde était un changement de code interne qui a par inadvertance cassé comment un enregistrement de saisie de build-queueing spécifique a été lu à partir de notre base de données une fois les constructions qui avaient déjà été en attente sous la version précédente du code rencontré la nouvelle version déployée. Nous avons résolu l'impact immédiat en nettoyant les dossiers touchés et en rétablissant le changement de code sous-jacent, et nous mettons en place plusieurs mesures de protection pour empêcher que cette catégorie de problèmes ne se répète. (en milliers de dollars) # Prochaines étapes Nous évaluons le risque d'une récidive similaire aussi faible que les actions suivantes sont sous-estimées. Le chemin de code spécifique qui a causé cet incident a déjà été retourné, et nous mettons en œuvre des sauvegardes structurelles afin que cette classe générale d'enjeux ne puisse pas se reproduire, peu importe où dans la base de code il pourrait autrement se produire. **Actions correctives et préventives** Oui. Ajouter des identifiants explicites et stables à toutes les classes de données internes qui sont stockées dans notre base de données, de sorte que les futures réorganisations internes de code ne peuvent pas briser la capacité du système de lire les enregistrements précédemment stockés. Autres Introduire des tests de rétro-compatibilité et de rétro-compatibilité dans notre environnement de pré-production, spécialement conçu pour attraper cette classe d'enjeux avant d'atteindre la production. Autres

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