Prod2 était indisponible par intermittence
Pending
Composants affectés
Platform
- investigating
Nous enquêtons actuellement sur cette question.
- resolved
Cet incident a été résolu.
Traduit automatiquement depuis la mise à jour officielle de l'incident.
82 Split incidents · avril 2026 — official updates, affected components, duration and resolution details.
Nous enquêtons actuellement sur cette question.
Cet incident a été résolu.
Traduit automatiquement depuis la mise à jour officielle de l'incident.
L'exécution du pipeline est bloquée dans Prod1. Nous enquêtons sur la question.
Un correctif a été mis en place et nous suivons les résultats.
Cet incident a été résolu.
Traduit automatiquement depuis la mise à jour officielle de l'incident.
Nous enquêtons actuellement sur cette question.
Le problème a été identifié et une solution est en cours de mise en oeuvre.
Un correctif a été mis en place et nous suivons les résultats.
Cet incident a été résolu.
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.
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.
Nous continuons d'enquêter sur cette question.
Nous avons repris le changement qui a causé cette question dans tous les groupes.
Cet incident a été résolu.
Traduit automatiquement depuis la mise à jour officielle de l'incident.
Nous enquêtons actuellement sur cette question.
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.
Un correctif a été mis en place et nous suivons les résultats.
Cet incident a été résolu.
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.
Nous enquêtons actuellement sur cette question.
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
Notre fournisseur de cloud est confronté à un incident actif et nous suivons.
Nous continuons d'enquêter sur cette question.
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.
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
Cet incident a été résolu.
# 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.
Nous enquêtons actuellement sur cette question.
Le problème a été identifié et une solution est en cours de mise en oeuvre.
Un correctif a été mis en place et nous suivons les résultats.
Cet incident a été résolu.
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.
Nous enquêtons actuellement sur cette question.
Nous continuons d'enquêter sur cette question.
Le problème a été identifié et une solution est en cours de mise en oeuvre.
Un correctif a été mis en place et nous suivons les résultats.
Nous restons à l'affût de tout autre problème.
Cet incident a été résolu.
** 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.
We are currently investigating a Harness component that is experiencing issues. We are working to identify the cause and restore normal operations as soon as possible.
We are continuing to investigate this issue.
The issue has been identified and a fix is being implemented.
This incident has been resolved.
## Summary Customers on Prod1, Prod2, and Prod3 \(US\) clusters experienced failures when loading SEI 2.0 dashboards on August 6, 2026, from 7:22 AM PDT to 9:03 AM PDT. Customers calling the SEI 2.0 API also experienced similar failures. No customer data was lost, and ingestion of all integration data continued to work uninterrupted. SEI customers using 1.0 were not impacted. ## Root Cause The incident was caused by resource exhaustion on the nodes serving queries. This resource degradation developed in a pattern that did not cross our existing alerting thresholds early enough to provide sufficient warning or allow mitigation before customer impact occurred. ## Impact Customers on Prod1, Prod2, and Prod3 \(US\) clusters were unable to load SEI 2.0 dashboards during the incident window. **Duration:** August 6, 2026, 7:22 AM PDT – 9:03 AM PDT \(~1 hour 41 minutes\) ### What was not impacted? * Data ingestion and processing * SEI 1.0 customers * Integrations and metadata flows No customer data was lost. ## Remediation Upon identifying the root cause, our team took immediate corrective action by adding capacity to restore the affected systems. Services were fully recovered, and all dashboards resumed normal operation at 9:03 AM PDT. ## Action Items To prevent from such issues happening again, Harness is/has Proactively added capacity updates have been applied to prevent this issue from recurring #### Enhanced Monitoring and Alerting Additional monitoring and alerting have been put in place to detect anomalies early, focused on a leading indicator, which in this case was thread pool exhaustion, before they can impact dashboard availability and data rendering. #### System Patch in Progress We are working with our vendor to apply a patch to remediate this and similar issues completely.
Nous surveillons les pipelines bloqués dans le prod2. Les nouvelles exécutions passent alors que nous surveillons constamment les services.
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.
Cet incident a été résolu.
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.
We are currently investigating this issue.
We are continuing to investigate this issue.
We have identified the issue and started to implement the fix , prod2 is restored.
We are continuously rolling out fixes to all Clusters, Prod EU1 has been resolved.
We are continuously rolling out fixes to all Clusters, Prod3 has been resolved.
This incident has been resolved.
# 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.
Nous enquêtons actuellement sur cette question.
Un correctif a été mis en place et nous suivons les résultats.
Cet incident a été résolu.
Traduit automatiquement depuis la mise à jour officielle de l'incident.
Nous enquêtons actuellement sur cette question.
Le problème a été identifié et une solution est en cours de mise en oeuvre.
Un correctif a été mis en place et nous suivons les résultats.
Cet incident a été résolu.
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.
Nous enquêtons actuellement sur cette question.
Le problème a été identifié et une solution est en cours de mise en oeuvre.
Un correctif a été mis en place et nous suivons les résultats.
Cet incident a été résolu.
# **Summary** On July 31, 2026, artifact uploads performed through pipeline in the EU1 cluster began failing with an authentication error. Uploads initiated manually \(outside of a pipeline\) were not affected, and the ability to retrieve existing artifacts \(downloads\) was also unaffected — this was isolated to the specific pipeline upload path in one cluster. # **Impact** * Artifact uploads performed through pipeline in the EU1 cluster failed with an authentication error for approximately 4 hours and 34 minutes. * Retrieving existing artifacts \(downloads\) was not affected. * Manually uploading artifacts outside of a pipeline was not affected. * Other clusters/regions were not affected by this issue. # **Root Cause** The component responsible for handling pipeline-based artifact uploads is distributed as a container image. In the EU1 cluster, this image is retrieved from an internal registry that mirrors a public image source; in other clusters, the same image is retrieved directly from the public source. A publishing error in our release process caused a new build of this component to be published using a version label that was already in use, rather than being assigned a new, unique version. As a result, two different images ended up associated with the same version label in the public source. Our internal registry mirrors images from the public source via an automated replication process. Because of how that replication was triggered, it copied the original \(earlier\) image associated with that version label rather than the corrected one. This meant the EU1 cluster — which pulls from the internal mirror — ended up running a different, defective image than other clusters, which pull directly from the public source and therefore received the corrected image. The defective image contained an authentication issue that caused pipeline uploads to fail. # **Mitigation** * Reverted the affected account to the last known-good version of the upload component, immediately restoring pipeline uploads. * Published a corrected, permanent version of the component to resolve the issue across all clusters. # **Next steps** * Fix the upload step to remove the underlying container-related defect that made this failure mode possible. * Update our release pipeline for this component so that publishing an image can never overwrite an existing version — every publish must create a new, distinct version going forward.
Traduit automatiquement depuis la mise à jour officielle de l'incident.
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.
Un correctif a été mis en place et nous suivons les résultats.
Nous restons à l'affût de tout autre problème.
Cet incident a été résolu.
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.
Nous enquêtons actuellement sur cette question.
Un correctif a été mis en place et nous suivons les résultats.
Cet incident a été résolu.
Traduit automatiquement depuis la mise à jour officielle de l'incident.
Nous enquêtons actuellement sur cette question.
Nous continuons d'enquêter sur cette question.
Le problème a été identifié et une solution est en cours de mise en oeuvre.
Nous continuons de travailler sur une solution à ce problème.
Un correctif a été mis en place et nous suivons les résultats.
Nous restons à l'affût de tout autre problème.
Cet incident a été résolu.
# Résumé Lors d'un récent déploiement de production, un défaut dans notre outillage de déploiement interne a provoqué deux services critiques avec des valeurs de configuration incorrectes et non-production dans notre environnement de production Cela a conduit à un ensemble connexe de quatre symptômes distincts: un comportement de configuration incorrect, des défaillances intermittentes de connexion/accès, un problème d'accès à un magasin de fichiers affectant un environnement client, et des mises à jour d'état du pipeline retardées dans l'interface utilisateur. (en milliers de dollars) Nous avons identifié et mettons en oeuvre un correctif permanent pour le défaut de configuration sous-jacent, et avons déjà mis en place des changements de ressources et de capacité qui résolvent le symptôme de retard de l'assurance-chômage. (en milliers de dollars) À aucun moment durant cet incident, les exécutions de pipelines ont eux-mêmes perdu, corrompu ou laissé dans un état bloqué. Lorsque le comportement d'exécution était affecté, il se limitait aux retards dans la visibilité de l'état, et non dans le traitement sous-jacent. # Détails de l'incident ## Valeurs de configuration de production incorrectes appliquées Notre équipe d'ingénierie a confirmé un défaut dans le pipeline de déploiement du gestionnaire de services qui a causé le déploiement de certains services de production en utilisant des valeurs de configuration destinées à un environnement différent, plutôt que la configuration de production correcte. (en milliers de dollars) ** Cause de la mort** (en milliers de dollars) Le service chargé de récupérer la configuration remplace lors des requêtes de déploiement une API interne qui retourne un maximum de 1000 résultats par requête. Le nombre total de services dans l'environnement a récemment dépassé cette limite. Par conséquent, tout service au-delà des 1 000 premiers retournés n'a pas été inclus dans la réponse, et le pipeline de déploiement est retombé silencieusement aux valeurs de configuration par défaut pour ces services. C'est un défaut de pagination confirmé dans l'outil de déploiement, pas un problème avec les valeurs de configuration elles-mêmes. (en milliers de dollars) **Résolution** (en milliers de dollars) L'ingénierie a confirmé le mécanisme et met actuellement en oeuvre une correction permanente pour éliminer cette lacune liée aux limites dans le pipeline de déploiement. ## Erreurs de connexion/d'accès Au cours du déploiement du gestionnaire de services mentionné ci-dessus, certains utilisateurs ont connu des pannes intermittentes de connexion ou d'accès. Dans le cadre de l'exploitation normale, les instances déjà en service devraient continuer à desservir le trafic sans interruption pendant qu'un nouveau déploiement est en cours. Dans cet incident, ce comportement de repli n'a pas eu lieu comme prévu, contribuant aux défaillances d'accès pendant la fenêtre de déploiement. ## Problème d'accès au magasin de fichiers On a relevé un problème d'accès aux magasins de fichiers qui était propre à l'environnement Prod-3 et qui touchait l'environnement d'un seul client. ** Cause de la mort** Ceci est lié à une configuration de permission IAM / stockage-bucket sur le gestionnaire de service, potentiellement déclenchée par une activité de retour. ## Mises à jour de l'état d'exécution des pipelines retardés dans l'interface utilisateur Certains utilisateurs ont observé que le graphique d'exécution du pipeline dans l'interface utilisateur était lent à se rafraîchir et ne reflétait pas rapidement le dernier état. Fait important, il ne s'agissait que d'un retard de visibilité : il n'y a eu aucun impact sur les exécutions réelles de pipelines, et aucune exécution n'a été bloquée ou échouée à la suite de cette question. ** Cause de la mort** Le graphique d'exécution du pipeline repose sur un flux de messages \(le log d'orchestration\) pour recevoir des mises à jour d'état. Pendant la fenêtre d'incident, le traitement des consommateurs de ce flux est tombé derrière \(high consumer lag\), ce qui a retardé la rapidité avec laquelle les mises à jour de l'état ont atteint l'interface utilisateur. Cela s'explique par le fait que la base de données sous-jacente se trouvait au milieu d'une opération d'échelle planifiée en même temps, et qu'un pic de trafic pendant cette fenêtre a encore aggravé le retard. Les utilisateurs ont ressenti cela comme une lenteur apparente du pipeline, même si les exécutions sous-jacentes fonctionnaient normalement. **Résolution** Nous avons augmenté la capacité de ressources des composants touchés pour maintenir plus de 50 % de la salle de tête de secours à l'avenir, réduisant la sensibilité aux pics de charge semblables. Ce changement a été mis en œuvre et est actuellement validé dans le cadre du durcissement à long terme de cette partie de la plateforme. # Résumé de l'impact * Le gestionnaire de services et le gestionnaire de licences ont exécuté avec des valeurs de configuration incorrectes dans les environnements Prod-1 et Prod-3. * Certains utilisateurs ont connu des pannes intermittentes de connexion ou d'accès pendant la fenêtre de déploiement affectée. * Un environnement client dans Prod-3 a connu un problème d'accès à la librairie de fichiers. * Les utilisateurs des environnements touchés ont vu des mises à jour de l'état de l'exécution de pipeline retardées dans l'interface utilisateur; les exécutions de pipeline sous-jacentes ont continué à fonctionner correctement et n'ont pas été perdues, bloquées ou corrompues. # Actions préventives Les mesures correctives et préventives suivantes ont été identifiées. (en milliers de dollars) **Actions correctives et préventives** Oui. Correction de la limite de pagination dans le service de recherche de configuration pour que tous les services soient retournés et évalués, quel que soit le nombre total. Ajouter des garanties afin qu'un service qui ne peut pas récupérer sa configuration échoue en toute sécurité \(par exemple alertes et bloque le déploiement\) plutôt que de revenir silencieusement à des défauts de non-production. Autres Augmenter Postgres and measing-pipeline resource headroom \(cible: plus de 50 % de capacité de secours\) pour réduire la sensibilité aux événements de charge et de mise à l'échelle. Autres (en milliers de dollars) Nous reconnaissons l'impact de cet incident sur plusieurs domaines de la plateforme et apprécions votre patience alors que nous travaillons sur une résolution complète.
Traduit automatiquement depuis la mise à jour officielle de l'incident.
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.
Le problème a été identifié et une solution est en cours de mise en oeuvre.
Un correctif a été mis en place et nous suivons les résultats.
Cet incident a été résolu.
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.
Nous enquêtons actuellement sur cette question.
Le problème a été identifié et une solution est en cours de mise en oeuvre.
Un correctif a été mis en place et nous suivons les résultats.
Cet incident a été résolu.
# 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.
Nous enquêtons actuellement sur cette question.
Le problème a été identifié et une solution est en cours de mise en oeuvre.
Un correctif a été mis en place et nous suivons les résultats.
Nous restons à l'affût de tout autre problème.
Cet incident a été résolu.
# Résumé Entre le 19 juin et le 17 juillet 2026, l'étape Git Clone intégrée — et toute étape de pipeline utilisant le plugin clone drone-git — a échoué sur ARM64 Kubernetes construire une infrastructure avec l'erreur exec /usr/local/bin/clone: erreur de format exec. AMD64 \(Intel/AMD\) construit, Windows construit, et le chemin binaire sans conteneur VM n'a pas été affecté. La cause profonde était un défaut dans notre processus interne d'édition d'images qui a fait que les images de drone-git marquées ARM64 contiennent en fait des binaires AMD64. Nous avons identifié et atténué le problème le jour même où il a été signalé en retournant l'image de drone-git à la dernière version connue-bonne. Aucune action client ou modification de configuration n'était requise. Cause racine Le 19 juin 2026, une remise en état de la sécurité a restructuré la façon dont l'image drone-git est construite. Les constructions AMD64 ont été mises à jour correctement, mais le pipeline de construction ARM64 n'a pas construit de fichiers ARM64 directement — il a adapté le fichier de construction AMD64 par substitution de texte et l'a compilé sur l'infrastructure ARM64. Le changement du 19 juin a modifié le fichier AMD64 de sorte que la substitution silencieusement non-op'd au lieu d'échouer, de sorte que le pipeline a publié une image marquée ARM64 dont les binaires Git Clone et Git LFS étaient encore compilés pour AMD64. # Impact * Affecté : l'étape Git Clone intégrée, et toute étape de pipeline utilisant le plugin clone drone-git, fonctionnant sur ARM64 Kubernetes construire l'infrastructure, sur tous les comptes, entre le 6 juillet et le 17 juillet 2026. * Symptom : Les constructions ont échoué à l'étape Git Clone avec exec /usr/local/bin/clone : erreur de format exec. * Non affecté: AMD64 \(Intel/AMD\) Kubernetes et VM construit, Windows construit, le chemin d'exécution sans conteneur VM, et notre variante d'image durcie. # Atténuation Nous avons renvoyé la version drone-git utilisée dans tous les services touchés à la dernière version connue. Cela a complètement résolu les défaillances d'exécution ARM64; aucun changement de configuration du client n'a été nécessaire. # Prochaines étapes Pour empêcher que de tels problèmes ne se reproduisent. * Reconstruisez le pipeline de publication d'images ARM64 pour construire nos fichiers de construction ARM64 directement, plutôt que d'adapter les fichiers de construction AMD64. * Améliorer la validation automatisée après publication à chaque sortie d'image : vérifier que l'architecture binaire correspond à la balise d'image, et exécuter un test de fumée fonctionnelle avant qu'une image soit considérée comme libérable. * Étendre la couverture de test automatisée pour inclure les scénarios de construction de Kubernetes ARM64. * Retirez les versions d'images intermédiaires touchées de la circulation une fois la version corrigée validée.
Traduit automatiquement depuis la mise à jour officielle de l'incident.