Das Problem wurde identifiziert und ein Fix wird implementiert.
identified
Wir arbeiten weiter an einer Lösung für dieses Problem.
monitoring
Ein Fix wurde implementiert und wir überwachen die Ergebnisse.
resolved
Dieser Vorfall wurde behoben.
postmortem
### 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
Automatisch aus der offiziellen Störungsmeldung übersetzt.
Prod2 war zeitweise nicht verfügbar
Beginn 5. September 2026 um 09:40 UTC · 1m
Pending
Betroffene Komponenten
Platform
investigating
Wir untersuchen derzeit dieses Problem.
resolved
Dieser Vorfall wurde behoben.
postmortem
## **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.
Automatisch aus der offiziellen Störungsmeldung übersetzt.
Pipelines stecken in Prod1 fest
Beginn 3. September 2026 um 10:00 UTC · 1h 40m
IssuesGeringfügiger Vorfall
Betroffene Komponenten
Continuous Delivery - Next Generation (CDNG)
investigating
Die Pipeline-Ausführung ist in Prod1 stecken geblieben. Wir untersuchen das Problem.
monitoring
Ein Fix wurde implementiert und wir überwachen die Ergebnisse.
resolved
Dieser Vorfall wurde behoben.
Automatisch aus der offiziellen Störungsmeldung übersetzt.
Entitäten in Harness werden nicht in Prod3 geladen
Beginn 28. August 2026 um 07:04 UTC · 32m
IssuesGeringfügiger Vorfall
Betroffene Komponenten
Platform
investigating
Wir untersuchen derzeit dieses Problem.
identified
Das Problem wurde identifiziert und ein Fix wird implementiert.
monitoring
Ein Fix wurde implementiert und wir überwachen die Ergebnisse.
resolved
Dieser Vorfall wurde behoben.
postmortem
## Zusammenfassung
Zwischen dem 27. August und dem 28. August 2026 kam es zu einem Problem, bei dem einige Pipelines, Bereitstellungen und verwandte Ressourcen als nicht in der Harness-Benutzeroberfläche und -API gefunden erschienen, obwohl die zugrunde liegenden Daten intakt blieben.
Das Problem trat während eines geplanten Updates der internen Infrastruktur auf, das die Kommunikation zwischen internen Plattformdiensten beeinflusste. Infolgedessen konnten Anfragen, die von Konto, Organisation und Projektumfang abhängig waren, nicht erfolgreich abgeschlossen werden, was dazu führte, dass falsche, nicht gefundene Antworten an Kunden für bestehende Einheiten zurückgegeben wurden.
Engineering identifizierte das Problem, rollte die Änderung zurück und stellte den normalen Service wieder her. Während des Vorfalls gingen keine Kundendaten verloren oder wurden gelöscht.
## Wurzelursache
Das Problem wurde durch einen Konfigurationsfehler verursacht, der während eines geplanten internen Service-Routing-Updates in der Produktion eingeführt wurde.
Ein interner Plattformdienst, der für die Lösung von Konto, Organisation und Projektkontext verantwortlich ist, konnte nach der Änderung keine Anfragen von anderen Harness-Diensten validieren. Da dieser Validierungsschritt erforderlich ist, bevor viele Entitätslesungen und Pipeline-bezogene Aktionen fortgesetzt werden können, tauchten die fehlgeschlagenen Anfragen an die Kunden als nicht gefundene Fehler für Ressourcen auf, die normalerweise weiterhin existierten.
Das Problem beschränkte sich auf die betroffene Produktionsumgebung und wurde durch das Zurücksetzen der Änderung und die Wiederherstellung des vorherigen Servicekommunikationspfades behoben.
## Auswirkungen
* Einige Kunden haben gesehen, dass bestehende Pipelines, Bereitstellungen und verwandte Entitäten als nicht in der Benutzeroberfläche und API zu finden erscheinen.
* Einige Pipeline-bezogene Operationen, einschließlich Ausführungsfortschritt, Webhook-ausgelöste Starts, geplante Trigger-Auswertung und Entity-Listing, wurden vorübergehend unterbrochen.
* Das Problem betraf die Verfügbarkeit und Sichtbarkeit bestehender Entitäten, es wurden jedoch keine Daten entfernt oder Kundenkonfigurationen geändert.
* Es gab keinen unbefugten Zugriff und es wurde kein Verlust von Kundendaten beobachtet.
## Sanierung
* **Sofort:** Das Update der Infrastrukturkonfiguration wurde wiederhergestellt und der zuvor funktionierende Dienstkommunikationspfad wiederhergestellt.
* **Validierung der Wiederfindung:** Überprüfen Sie, ob die betroffenen Entity-Lookups, Pipeline-Operationen und abhängigen APIs nach dem Rollback normal funktionierten.
* **Dauerhaft:** Die mit dem Update verbundene Konfigurationsbehandlung wurde korrigiert, sodass ähnliche Probleme die Service-to-Service-Authentifizierung in zukünftigen Rollouts nicht beeinträchtigen.
## Aktionspunkte
Um zu verhindern, dass sich solche Probleme wiederholen, wird Harness
1. Verbesserung der Konfigurationsvalidierung durch Verbesserung der Vorbereitungstests zur Überprüfung der internen Servicekommunikation vor einer Verschiebung des Produktionsverkehrs.
2. Verbesserte Überwachung und Alarmierung auf interne Authentifizierungsfehler, damit Probleme früher erkannt werden können.
3. Verbesserung der Fehlerbehandlung, so dass Abhängigkeitsfehler den Kunden weniger wahrscheinlich als nicht gefundene Ressource erscheinen.
Automatisch aus der offiziellen Störungsmeldung übersetzt.
Pipelines scheitern für IACM-Kunden
Beginn 26. August 2026 um 08:38 UTC · 32m
IssuesGeringfügiger Vorfall
Betroffene Komponenten
Infrastructure as Code Management (IaCM)Infrastructure as Code Management (IaCM)Infrastructure as Code Management (IaCM)Infrastructure as Code Management (IaCM)
investigating
Wir untersuchen derzeit ein Problem, das in IACM-Pipelines in Prod-1, Prod-2, Prod-4 und EU1-Geschirrclustern gemeldet wurde.
investigating
Wir werden dieses Problem weiter untersuchen.
monitoring
Wir haben die Änderung, die dieses Problem verursacht hat, in allen Clustern rückgängig gemacht.
resolved
Dieser Vorfall wurde behoben.
Automatisch aus der offiziellen Störungsmeldung übersetzt.
Feature Management & Experimentation (FME) Benutzeroberfläche nicht verfügbar
Beginn 24. August 2026 um 00:57 UTC · 16m
OutageSchwerwiegender Vorfall
Betroffene Komponenten
FME
investigating
Wir untersuchen derzeit dieses Problem.
investigating
Wir untersuchen derzeit Berichte, dass die Benutzeroberfläche für Feature Management & Experimentation (FME) nicht geladen werden kann. Kunden, die versuchen, auf die FME-Konsole zuzugreifen, können auf Fehler oder nicht reagierende Seiten stoßen. Es wird nicht angenommen, dass die Feature-Flag-Auswertung und der SDK-Verkehr betroffen sind. Ein weiteres Update wird in Kürze folgen.
monitoring
Ein Fix wurde implementiert und wir überwachen die Ergebnisse.
resolved
Dieser Vorfall wurde behoben.
postmortem
## Zusammenfassung
* Ab **23:42 UTC** am 23. August 2026 meldeten mehrere FME-Kunden Ausfälle beim Laden der FME-Benutzeroberfläche.
* FME UI Artefakte, die vom CDN serviert wurden, sind aufgrund einer Aufbewahrungsrichtlinie abgelaufen, was dazu führte, dass FME UI nicht geladen wurde.
* Jede Flag-Anfrage ändert sich über die API, die Änderungsbereitstellung und die Datenpipeline funktionierte ohne Unterbrechung weiter.
## Wurzelursache
* Die FME UI wird von einem CDN bedient. Die UI-Artefakte wurden aufgrund einer Aufbewahrungsrichtlinie vertrieben, wodurch die Benutzeroberfläche nicht für alle Benutzer geladen werden konnte.
## Auswirkungen
* Die FME-Benutzeroberfläche konnte nicht für alle Benutzer in allen Produktionsumgebungen geladen werden.
### Was war nicht betroffen?
* SDK-Funktionalität und Laufzeitflag-Auswertung
Admin API Calls
* Konfigurationsdaten des Kundenflags
* Kein Datenverlust aufgetreten
## Sanierung
* FME UI wurde im CDN durch eine Bereitstellung wiederhergestellt
* Die Wiederherstellung wurde in allen Produktionsumgebungen bestätigt, bevor der Vorfall abgeschlossen wurde.
## Aktionspunkte
* Verbessern Sie die Aufbewahrungsrichtlinien für Vermögenswerte, damit die derzeit aktive Version niemals einer Räumung unterliegt.
Automatisch aus der offiziellen Störungsmeldung übersetzt.
Alle Module laufen in Prod1/2/3/4 aufgrund eines Cloud-Provider-Vorfalls langsam
Beginn 20. August 2026 um 15:37 UTC · 3h 46m
OutageSchwerwiegender Vorfall
Betroffene Komponenten
PlatformPlatformPlatformPlatform
investigating
Wir untersuchen derzeit dieses Problem.
investigating
Die Langsamkeit kann eines der folgenden Symptome verursachen:
Pipelines starten nicht
- Verzögerungen bei der Ausführung
Pipelines werden aufgrund von Timeouts gestrichen
investigating
Unser Cloud-Anbieter steht vor einem aktiven Vorfall und wir verfolgen ihn.
investigating
Wir werden dieses Problem weiter untersuchen.
identified
Unser Cloud-Anbieter hat einen anhaltenden Vorfall bestätigt, der mehrere Regionen betrifft. Harness-Pipelines haben keine Ausfälle erlebt, obwohl einige Benutzer weiterhin Langsamkeit erleben können. Wir beobachten die Situation genau und werden Updates bereitstellen, sobald mehr Informationen verfügbar werden.
monitoring
Wir beobachten verbesserte Latenzen auf der ganzen Linie nach dem Fix von unserem Cloud-Anbieter implementiert. Wir beobachten die Situation weiterhin genau und werden weitere Updates bereitstellen, wenn dies gerechtfertigt ist.
Wir haben einige festgefahrene Hinrichtungen für CI für einige Kunden festgestellt, die wir untersuchen
resolved
Dieser Vorfall wurde behoben.
postmortem
# Zusammenfassung
Am 20. August 2026, ab ca. 15:00 Uhr UTC, erlebte die Harness-Plattform eine weit verbreitete Leistungsminderung in allen Produktionsumgebungen. Pipeline-Ausführungen, die normalerweise in etwa zwei Minuten abgeschlossen sind, dauerten sieben bis zehn Minuten. Continuous Delivery, Continuous Integration, Pipeline-Orchestrierung und Feature Management & Experimentation waren alle betroffen.
Die Google Cloud Platform erlebte einen Multi-Produkt-Vorfall in der US-West1-Region, der Bigtable, Compute Engine, Google Kubernetes Engine und Persistent-Disk-I/O betraf. Die Degradation erhöhte die Latenz des Datenbankbetriebs von etwa 2 ms auf über 10 ms beim 95. Perzentil, was wiederum zu einer Verzögerung bei der Verarbeitung von Nachrichten in der Warteschlange führte und sich auf jeden Dienst ausbreitete, der von einem rechtzeitigen Datenbankzugriff abhängt.
# Auswirkungen
Dies war eine Verschlechterung, kein Ausfall. Pipelines fuhren fort, überall erfolgreich auszuführen und abzuschließen; sie waren langsam, anstatt zu scheitern. Es gingen keine Daten verloren, und infolge dieses Vorfalls wurde keine Kundenarbeit eingestellt.
# **Wurzelursache**
Die Nutzung der Produktionsinfrastruktur in den betroffenen Umgebungen läuft auf persistenten Festplatten der Google Cloud Platform in der Region us-west1. Wenn diese Speicherschicht abgebaut wurde, verbreitete sich der Effekt in einer vorhersehbaren Kette durch die Plattform:
**Persistent-disk I/O-Abbau in us-west1.** Die Google Cloud Platform erlebte einen Multi-Produkt-Vorfall, der Bigtable, Compute Engine, Google Kubernetes Engine und Persistenzdatenträger-Performance betraf. Dies war ein Infrastrukturfehler in der Umgebung des Anbieters, der sich der Kontrolle von Harness entzog.
# **Vorbeugende Maßnahmen**
Obwohl Harness einen Ausfall der Cloud-Provider-Infrastruktur nicht verhindern kann. Die folgenden Aktionen zielen darauf ab, einen schneller zu erkennen und besser positioniert zu sein, um darauf zu reagieren.
| **Action**
| --- |
Fortsetzung der routinemäßigen Vortests von gezielten bereichsübergreifenden Datenbank-Failovers, wie sie während dieses Vorfalls durchgeführt wurden, um die Failover-Bereitschaft eher verifiziert als angenommen zu halten.
| Bewertung der Vollstapel-Multi-Region-Failover-Bereitschaft für Zukunftsszenarien, in denen eine regionenübergreifende Latenz inakzeptabel wäre |
Automatisch aus der offiziellen Störungsmeldung übersetzt.
FME API-Schreiboperationen begannen mit der Rückgabe von 499 Fehlern
Beginn 20. August 2026 um 14:32 UTC · 30m
IssuesGeringfügiger Vorfall
Betroffene Komponenten
FME
investigating
Wir untersuchen derzeit dieses Problem.
identified
Das Problem wurde identifiziert und ein Fix wird implementiert.
monitoring
Ein Fix wurde implementiert und wir überwachen die Ergebnisse.
resolved
Dieser Vorfall wurde behoben.
postmortem
### Zusammenfassung
Am 20. August 2026, zwischen 10:24 und 14:55 UTC, scheiterte eine Teilmenge der FME-Schreiben. Writes aus der FME-Benutzeroberfläche und Writes mit Harness-Zugriffstoken (PATs und SATs) waren nicht betroffen. Die Runtime-Flag-Bewertung funktionierte weiterhin normal. Das Problem wurde gemildert, indem eine kürzliche Authentifizierungsänderung in einem Shared-Governance-Service rückgängig gemacht wurde, und betroffene Schreibvorgänge wurden um 14:55 UTC wieder normalisiert. Status: [https://status.harness.io/incidents/rhthgm7d5dkz](https://status.harness.io/incidents/rhthgm7d5dkz)
### Wurzelursache
Eine Änderung in der Art und Weise, wie ein Shared Governance Service eingehende Anrufe authentifizierte, führte dazu, dass einige FME-Schreiben abgelehnt wurden. Diese Schreibvorgänge verwendeten Service-to-Service-Anmeldeinformationen, die der Governance-Service nach der Änderung nicht mehr überprüfen konnte. FME zeigt einen Governance-Fehler an den Client als HTTP 499, den gleichen Status, der verwendet wird, wenn eine Governance-Richtlinie eine Änderung absichtlich ablehnt. Da 499 eine gültige, erwartete Antwort in diesem Deny-Pfad ist, sahen die Ausfälle nicht wie ein Ausfall in unseren Warnungen aus, und der Vorfall wurde aus Kundenberichten und nicht aus der internen Erkennung identifiziert.
### Auswirkungen
* Eine Teilmenge von FME-Schreiben ist während des Fensters fehlgeschlagen, hauptsächlich solche, die mit Legacy-Split-API-Schlüsseln oder Änderungsanforderungen erstellt wurden.
* Writes aus der FME UI wurden nicht betroffen.
* Schreibt mit Harness-Zugriffstoken (PATs und SATs) wurden nicht beeinflusst.
* Die Laufzeitflag-Auswertung wurde normal fortgesetzt.
* Es ist kein Datenverlust aufgetreten. Failed Writes gelten nicht.
### Sanierung
Die Änderung der Governance-Service-Authentifizierung wurde rückgängig gemacht. Betroffene schreiben sofort wieder normal.
### Aktionspunkte
Um zu verhindern, dass sich solche Probleme wiederholen,
* Harness gibt einen eindeutigen Fehler zurück (nicht 499), wenn ein Schreiben fehlschlägt, weil die Governance nicht bewertet werden konnte, so dass sie nicht mit einer absichtlichen Politikverweigerung verwechselt wird.
* Fügen Sie eine Warnung zum Governance-Evaluierungsaufruf selbst hinzu, anstatt sich auf den Client-Statuscode zu verlassen.
* Erweitern Sie die Authentifizierungsunterstützung für Richtlinienbewertungen.
* Erweitern Sie die automatisierte Abdeckung für zusätzliche Schreibszenarien.
Automatisch aus der offiziellen Störungsmeldung übersetzt.
Datenaufnahme verzögert sich auf Traceable US-Produktion
Beginn 19. August 2026 um 13:22 UTC · 2h 44m
OutageSchwerwiegender Vorfall
Betroffene Komponenten
US - app.traceable.ai / api.traceable.ai
investigating
Wir untersuchen derzeit dieses Problem.
investigating
Wir werden dieses Problem weiter untersuchen.
identified
Das Problem wurde identifiziert und ein Fix wird implementiert.
monitoring
Ein Fix wurde implementiert und wir überwachen die Ergebnisse.
monitoring
Wir werden weiterhin auf weitere Probleme achten.
resolved
Dieser Vorfall wurde behoben.
postmortem
**Zusammenfassung**
Am 19. August 2026 zwischen 12:35 und 17:29 UTC erlebte der Harness Application Security Service eine erhebliche Störung, die sowohl die kundenorientierte Konsole als auch die Datenaufnahme-Pipeline in den Regionen SaaS Production und US1 betraf.
**Wurzelursache**
Der interne Konfigurationsdienst, der die Laufzeiteinstellungen für fast alle anderen Komponenten bereitstellt, wurde überlastet und trat in einen wiederholten Neustartzyklus ein. Da so viele Dienste davon abhängen, waren die Auswirkungen breit: Konsolenseiten wie Schutzrichtlinien, Haltungsansichten, Aktivitätsprotokolle, API-Inventar und benutzerdefinierte Richtlinien konnten nicht geladen oder zeitversetzt werden, und die nachgelagerte Verarbeitung blieb stehen, während sie auf die Konfiguration wartete, die sie nicht erhalten konnte.
# **Kundenauswirkungen**
| **Dimension** | **Detail** |
| --- | ---
| Auswirkungen auf die Konsole \(UI\) | Mehrere Seiten konnten nicht geladen oder zeitgesteuert werden, einschließlich Schutzrichtlinien, Haltungsereignisseiten und Haltungsansichten in Dashboards und Einblicksseiten, Aktivitätsprotokollabfragen, API-Inventarbildschirmen, benutzerdefinierten Richtlinien und Ansichten von sensiblen Daten und Widgets. |
| Ingestion Impact | Security Telemetry Processing verschlechterte sich stark und stoppte auf einigen Wegen vollständig. Der Verbraucherrückstand wuchs in den Phasen Normalisierung, Gruppierung, Anomalieerkennung, Generierung und verwandter Verarbeitung. |
| Datenverlust | Eine Teilmenge der Telemetrie, die während der Störung aufgenommen wurde, wurde dauerhaft fallen gelassen. |
**Abschwächung**
Mehrere Zwischenminderungen zusätzliche CPU und Speicher, entspannte Health-Check-Schwellenwerte, ein Datenbankneustart und ein größerer Verbindungspool haben das Problem gelindert. Deaktivierung der neuen Funktion in beiden betroffenen Regionen wiederhergestellt Durchsatz scharf und dauerhaft. Der Vorfall wurde um 17:29 UTC gelöst.
# **Vorbeugende Maßnahmen**
Die folgenden Aktionen werden festgelegt und intern bis zum Abschluss verfolgt. Die Funktion, die diesen Vorfall ausgelöst hat, bleibt deaktiviert und wird erst wieder aktiviert, wenn die unten stehende Arbeit abgeschlossen und validiert ist.
| **Action**
| --- |
| |
| OPtimieren Sie den Code durch Tuning-Parameter wie Cache-Räumung und Retention , bewerten Sie die Cursor-basierte Paginierung für den Massenregelabruf, wenn die Regelzahl wächst |
| Fügen Sie einen zweckgebundenen Datenbankindex für das Service-Scoping-Zugriffsmuster hinzu |
| Beheben Sie die Semantik der Pipeline-Wiederherstellung, damit Verbraucher nach Positionsmarkerverlust sicher spielen können, anstatt den Rückstand zu überspringen |
| Mandatsstufen-Rollout für Konfigurationsüberschreibungen, die nachgelagerte Anforderungsmuster verändern: Cluster mit niedrigem Volumen, dann mit mittlerem Volumen, dann mit hohem Volumen |
| Fügen Sie dem Konfigurationsdienst Gegendruck- und Parallelitätsschutz hinzu: Stromkreisunterbrechung, begrenzte Warteschlangen und Timeout-Isolation |
| Erhöhen Sie die Beobachtbarkeit durch Instrumentierung detaillierterer Metriken |
Automatisch aus der offiziellen Störungsmeldung übersetzt.
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.
investigating
We are continuing to investigate this issue.
identified
The issue has been identified and a fix is being implemented.
resolved
This incident has been resolved.
postmortem
## 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.
Überwachung - Pipelines stecken - Prod2
Beginn 6. August 2026 um 13:50 UTC · 4h 31m
IssuesGeringfügiger Vorfall
Betroffene Komponenten
Continuous Delivery - Next Generation (CDNG)
monitoring
Wir überwachen die steckengebliebenen Pipelines in prod2. Die neuen Hinrichtungen gehen vorüber, da wir die Dienste kontinuierlich überwachen.
monitoring
Wir überwachen die steckengebliebenen Pipelines in prod2. Für die Kunden, die immer noch steckengebliebene Pipelines sehen, bitten wir Sie, abzubrechen und neu auszulösen.
resolved
Dieser Vorfall wurde behoben.
postmortem
## **Zusammenfassung**
Am 6. August 2026 (morgendliche PDT) beobachteten einige Kunden, die Pipelines in der Prod2-Produktionsumgebung betrieben, Pipelineausführungen, die keine Fortschritte mehr machten - Phasen, die nicht vorankamen und keine weiteren Output- oder Statusaktualisierungen produzierten. Das Problem wurde von betroffenen Kunden gemeldet. Harness-Ingenieure identifizierten die Ursache, milderten die Auswirkungen und Pipeline-Ausführungen kehrten in den normalen Betrieb zurück.
Das Problem wurde durch einen selbstreferenziellen Pipeline-Ausdruck verursacht. Ein Git-Webhook löste eine Pipeline aus, die sich auf den Inhalt der Webhook-Nutzlast bezog, und die Nutzlast selbst enthielt weitere Kopien desselben Ausdrucks. Jede Runde der Ausdrucksauflösung erzeugte daher mehr aufzulösende Ausdrücke, wodurch sich der Arbeitsaufwand jedes Mal verdoppelte. Dies erschöpfte die Ressourcen der Dienstinstanz, die diese Ausführung verarbeitete, und andere, derselben Instanz zugewiesene Ausführung konnte nicht fortschreiten, während sie sich in diesem Zustand befand.
## **Auswirkungen**
Während des Ereignisfensters \(ca. 6:11 Uhr bis 11:23 Uhr PDT am 6. August 2026\):
* Einige Kunden Pipeline-Ausführungen auf Prod2 ins Stocken geraten Mitte Ausführung und machte keine weiteren Fortschritte.
* Betroffene Executions erzeugten keine neuen Schritt-Outputs oder Status-Updates und mussten nach der Minderung abgebrochen und erneut ausgeführt werden.
* Das Verhalten beschränkte sich auf die Ausführung, die von der betroffenen Serviceinstanz verarbeitet wurde – Pipelines, die von anderen Instanzen bearbeitet wurden, wurden weiterhin normal ausgeführt.
Es gab ** keinen Datenverlust **. Pipeline-Definitionen, Ausführungshistorie und gespeicherter Zustand waren nicht betroffen. Die meisten Pipelines auf Prod2 wurden während des gesamten Vorfalls weiterhin erfolgreich ausgeführt; die Hauptauswirkungen waren, dass einige Ausführungsvorgänge während des Fluges nicht abgeschlossen werden konnten und erneut ausgeführt werden mussten, sobald das Problem behoben war.
## **Wurzelursache**
Harness-Pipelines unterstützen Ausdrücke, die zur Laufzeit aufgelöst werden – zum Beispiel ein Ausdruck, der den Inhalt der Git-Webhook-Nutzlast einfügt, die die Pipeline ausgelöst hat.
In diesem Fall enthielt eine Git-Commit-Nachricht zweimal den wörtlichen Text des Nutzlastausdrucks selbst, und die Pipeline referenzierte denselben Nutzlastausdruck. Da die Commit-Nachricht Teil der Webhook-Nutzlast ist, hat das Auflösen des Ausdrucks die gesamte Payload eingefügt - einschließlich der beiden wörtlichen Kopien des Ausdrucks, die in der Commit-Nachricht enthalten sind. Diese neu eingefügten Kopien wurden dann als aufzulösende Ausdrücke behandelt, und jeder Durchlauf fügte zwei weitere vollständige Kopien der Nutzlast ein. Die Größe des zu verarbeitenden Wertes und die zu seiner Verarbeitung erforderliche Arbeit verdoppelten sich daher bei jedem Durchlauf und wuchsen exponentiell, anstatt sich anzunähern.
Harness hat einen Schutz, der genau dies verhindern soll: Die Ausdrucksauflösung wird durch eine maximale Verschachtelungstiefe begrenzt, ab der die Auflösung endet und die Pipeline mit einem expliziten Fehler ausfällt. Ein Fehler in dieser Sicherung bedeutete, dass der Grenzwert in diesem speziellen selbstreferenziellen Fall nicht angewendet wurde, so dass die Auflösung ungeprüft fortgesetzt wurde.
Ausdrucksauflösung läuft inline auf den Threads, die Pipeline-Schritte starten. Da jeder Durchlauf progressiv mehr Speicher und CPU verbrauchte, ohne jemals abgeschlossen zu sein, hörte die Dienstinstanz, die diese Arbeit ausführte, auf, Fortschritte zu machen, und jede Ausführung, die dieser Instanz zugewiesen wurde, blieb stehen - was Kunden berichteten.
## **Abschwächung**
Harness hat die folgenden sofortigen Minderungsschritte abgeschlossen:
* Identifizierte die Pipeline und das Ausdrucksmuster, das für die außer Kontrolle geratene Auflösung verantwortlich ist.
* Stoppte die betroffene Serviceinstanz, damit sie keine weiteren Arbeiten übernehmen würde. Die verbleibenden gesunden Instanzen nahmen ab und verarbeiteten normalerweise Schlangenausführungen.
* Bestätigt, dass Pipeline-Ausführungen wieder normalisiert wurden und der Vorfall geschlossen wurde.
Diese Aktionen stellten das normale Pipeline-Ausführungsverhalten wieder her und lösten die Auswirkungen auf den Kunden.
## **Aktionspunkte**
Um das Rezidivrisiko zu verringern und die Erkennung zu verbessern, sind die folgenden Maßnahmen in verschiedenen Phasen implementiert:
* Beheben Sie den Fehler in der Ausdruckstiefe und Schleifenerkennung, damit selbstreferenzielle Ausdrücke abgefangen werden und schnell mit einem klaren Fehler versagen, anstatt Ressourcen ohne Grenzen zu verbrauchen.
* Verhindern Sie, dass Nutzlastausdrücke aus dem Trigger-Nutzlastinhalt aufgelöst werden, wodurch der selbstreferenzielle Pfad vollständig entfernt wird.
* Verschärfung der maximalen Ausdrucksverschachtelungstiefe und Auswertung der expliziten Schleifenerkennung zusätzlich zur vorhandenen Tiefengrenze.
* Verbessern Sie automatisierte Tests in Vorproduktionsumgebungen, die selbstreferenzielle Ausdrucksmuster reproduzieren, und überprüfen Sie, ob der Schutz sie erkennt und stoppt.
* Fügen Sie die Überwachung dieses Musters in Pipeline-Ausführungen hinzu, damit es proaktiv erkannt wird.
Automatisch aus der offiziellen Störungsmeldung übersetzt.
Editing 'Variable Sets' in the IaCM module is experiencing issue
Beginn 4. August 2026 um 12:07 UTC · 3h 21m
IssuesGeringfügiger Vorfall
Betroffene Komponenten
Infrastructure as Code Management (IaCM)Infrastructure as Code Management (IaCM)Infrastructure as Code Management (IaCM)Infrastructure as Code Management (IaCM)
investigating
We are currently investigating this issue.
investigating
We are continuing to investigate this issue.
investigating
We have identified the issue and started to implement the fix , prod2 is restored.
investigating
We are continuously rolling out fixes to all Clusters, Prod EU1 has been resolved.
investigating
We are continuously rolling out fixes to all Clusters, Prod3 has been resolved.
resolved
This incident has been resolved.
postmortem
# 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.
Legacy Dashboards - Degradiert
Beginn 3. August 2026 um 03:08 UTC · 2h 45m
IssuesGeringfügiger Vorfall
Betroffene Komponenten
Custom Dashboards
investigating
Wir untersuchen derzeit dieses Problem.
monitoring
Ein Fix wurde implementiert und wir überwachen die Ergebnisse.
resolved
Dieser Vorfall wurde behoben.
Automatisch aus der offiziellen Störungsmeldung übersetzt.
UI-Dashboards hinken hinterher (CI)
Beginn 31. Juli 2026 um 20:22 UTC · 12h 48m
Pending
Betroffene Komponenten
Continuous Integration Enterprise(CIE) - Linux Cloud BuildsContinuous Integration Enterprise(CIE) - Windows Cloud BuildsContinuous Integration Enterprise(CIE) - Mac Cloud BuildsContinuous Integration Enterprise(CIE) - Self Hosted RunnersContinuous Integration Enterprise(CIE) - Self Hosted RunnersContinuous Integration Enterprise(CIE) - Self Hosted RunnersContinuous Integration Enterprise(CIE) - Windows Cloud BuildsContinuous Integration Enterprise(CIE) - Windows Cloud BuildsContinuous Integration Enterprise(CIE) - Linux Cloud BuildsContinuous Integration Enterprise(CIE) - Mac Cloud BuildsContinuous Integration Enterprise(CIE) - Linux Cloud BuildsContinuous Integration Enterprise(CIE) - Mac Cloud Builds
investigating
Wir untersuchen derzeit dieses Problem.
identified
Das Problem wurde identifiziert und ein Fix wird implementiert.
monitoring
Ein Fix wurde implementiert und wir überwachen die Ergebnisse.
resolved
Dieser Vorfall wurde behoben.
postmortem
# **Zusammenfassung**
Zwischen dem 25. Juli und dem 4. August 2026 zeigten Pipelineausführungs-Dashboards und Übersichtsseiten in den Clustern Harness Prod 2 und Prod 3 Daten an, die in Echtzeit dazwischen lagen. Pipelines selbst bauten, implementierten und ausgeführten weiterhin normal; das Problem beschränkte sich darauf, wie schnell Ausführungsdatensätze in die Datenbank kopiert wurden, die Berichts- und Dashboardansichten bedient.
**Es gingen keine Kundendaten verloren.** Jeder betroffene Datensatz blieb dauerhaft gespeichert und wurde in den Analysedatenspeicher wiedergegeben, sobald die zugrunde liegende Einschränkung entfernt wurde. Harness migrierte die betroffenen Cluster am 1. August 2026 auf eine horizontal skalierbare, Warteschlangen-gestützte Version der Replikationskomponente und führte gezielte Daten-Backfills für alle betroffenen Konten durch.
# **Wurzelursache**
Harness unterhält eine Change-Data-Capture-Komponente, die kontinuierlich Pipeline-Ausführungsdatensätze aus dem primären Betriebsdatenspeicher in einen separaten Zeitreihen-Datenspeicher repliziert, der für Dashboards und Berichtsabfragen optimiert ist. Dashboards lesen ausschließlich aus dem Analytics-Datenspeicher. Wenn die Replikation zurückfällt, stellen Dashboards eine genaue, aber ältere Ansicht der Welt dar, während die Ausführung selbst nicht betroffen ist. Dies wurde durch einen starken, anhaltenden Anstieg des Datenbankschreibvolumens von einem anderen Harness-Plattformmodul verursacht, das sich den gleichen Replikationspfad teilt und die Durchsatzobergrenze der älteren Single-Instance-Version dieser Komponente, die noch in Prod 2 und Prod 3 läuft, überschritten hat. Ein Backlog bildete sich und wuchs.
# **Vorbeugende Maßnahmen**
Harness hat die folgenden Maßnahmen abgeschlossen oder sich verpflichtet, um solche Probleme zu verhindern.
| **Action**
| --- |
| Feintune die Replikationsverzögerung Warnung, so dass jede Verzögerung über einen definierten Schwellenwert hinaus benachrichtigt wird |
| Fügen Sie ein Replikations-Lag-Panel zum Standard-Plattform-Monitoring-Board hinzu, damit der Zustand der Pipeline standardmäßig für den Bereitschaftsdienst sichtbar ist |
| Schreibverstärkung von Co-Tenant-Modulen durch pro-Module-Ratenbegrenzung oder Entitätsfilterung im Replikationsstrom reduzieren |
Automatisch aus der offiziellen Störungsmeldung übersetzt.
Harness Artifact Registry Upload scheitert an Pipeline - EU1-Region
Beginn 31. Juli 2026 um 13:48 UTC · 1d 10h
IssuesGeringfügiger Vorfall
Betroffene Komponenten
Artifact Registry
investigating
Wir untersuchen derzeit dieses Problem.
identified
Das Problem wurde identifiziert und ein Fix wird implementiert.
monitoring
Ein Fix wurde implementiert und wir überwachen die Ergebnisse.
resolved
Dieser Vorfall wurde behoben.
postmortem
# **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.
Automatisch aus der offiziellen Störungsmeldung übersetzt.
Intermittierende externe Netzwerkverbindungsprobleme bei Build-VMs
Beginn 30. Juli 2026 um 05:59 UTC · 21h 24m
IssuesGeringfügiger Vorfall
Betroffene Komponenten
Continuous Integration Enterprise(CIE) - Linux Cloud BuildsContinuous Integration Enterprise(CIE) - Linux Cloud BuildsContinuous Integration Enterprise(CIE) - Linux Cloud BuildsContinuous Integration Enterprise(CIE) - Linux Cloud BuildsContinuous Integration Enterprise(CIE) - Linux Cloud Builds
investigating
Zusammenfassung - Wir stehen gelegentlich vor Netzwerkverbindungsproblemen mit unseren Build-VMs, die keine Verbindung zu externen Ressourcen herstellen können.
Wir untersuchen derzeit das Problem.
monitoring
Ein Fix wurde implementiert und wir überwachen die Ergebnisse.
monitoring
Wir werden weiterhin auf weitere Probleme achten.
resolved
Dieser Vorfall wurde behoben.
postmortem
## Zusammenfassung
Ab dem 4. August 2026 erlebten CI-Läufer in den US-West1- und US-Central1-Regionen zeitweise Verbindungszeiten von etwa 134 Sekunden, wenn sie externe Dienste wie GitHub und Bitbucket über Outbound-Netzwerk-Gateways erreichten.
## Auswirkungen
* CI-Läufer in den betroffenen Regionen erlebten zeitweise Verbindungszeiten von etwa 134 Sekunden beim Erreichen externer Dienste (z. B. GitHub, Bitbucket) über unsere Outbound-Netzwerk-Gateways.
* Das Problem war eher intermittierend als konstant - Verbindungen waren unter normaler Last erfolgreich und Ausfälle gruppierten sich in Zeiten mit hohem ausgehenden Verkehrsaufkommen.
* Es wurden keine Daten verloren oder beschädigt. Dies war ein Problem der Netzwerkverbindung und -kapazität, kein Problem der Datenintegrität.
* us-west1 und us-central1 waren die betroffenen Regionen; andere Regionen waren von diesem Problem nicht betroffen.
## Wurzelursache
Unser Load Balancer verteilt ausgehenden Datenverkehr über mehrere NAT-Gateways mit einer Hashing-Methode basierend auf Verbindungsdetails (Quelle / Zieladresse und Port). Für jede einzelne Verbindung bleiben diese Details für die Lebensdauer dieser Verbindung konstant. Wir hatten einen anhaltenden Verkehrsanstieg für ein paar Sekunden, der die Gateways überlastete
## Aktionspunkte
Um zu verhindern, dass solche Probleme wieder passieren Harness wird,
Erhöhen Sie die Outbound-Verbindungskapazität auf unseren NAT-Gateways, indem Sie zusätzliche externe Netzwerkschnittstellen bereitstellen und jedem Gateway einen wesentlich größeren Pool von Verbindungen geben, den es gleichzeitig bedienen kann.
Automatisch aus der offiziellen Störungsmeldung übersetzt.
Prod3 Filestore scheitert mit HTTP 500-Fehlern
Beginn 27. Juli 2026 um 09:09 UTC · 4h 24m
OutageSchwerwiegender Vorfall
Betroffene Komponenten
Continuous Delivery (CD) - FirstGen - EOS
investigating
Wir untersuchen derzeit dieses Problem.
monitoring
Ein Fix wurde implementiert und wir überwachen die Ergebnisse.
resolved
Dieser Vorfall wurde behoben.
Automatisch aus der offiziellen Störungsmeldung übersetzt.
Die Prod3 & Prod1 Umgebung erlebt intermittierende Ausfälle. Wir untersuchen derzeit das Problem.
Das Problem wurde identifiziert und ein Fix wird implementiert.
identified
Wir arbeiten weiter an einer Lösung für dieses Problem.
monitoring
Ein Fix wurde implementiert und wir überwachen die Ergebnisse.
monitoring
Wir werden weiterhin auf weitere Probleme achten.
resolved
Dieser Vorfall wurde behoben.
postmortem
# 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._
Automatisch aus der offiziellen Störungsmeldung übersetzt.
Wir untersuchen ein Problem, das sich auf AIDI-Dashboards auswirkt. Benutzer können beim Zugriff auf Dashboards erhöhte Ladezeiten oder intermittierende Ausfälle feststellen. Unser Team arbeitet aktiv daran, die Ursache zu identifizieren und die normale Leistung wiederherzustellen. Wir werden Updates bereitstellen, sobald weitere Informationen verfügbar sind.
identified
Das Problem wurde identifiziert und ein Fix wird implementiert.
monitoring
Ein Fix wurde implementiert und wir überwachen die Ergebnisse.
resolved
Dieser Vorfall wurde behoben.
postmortem
## Summary
Customers on Prod1, Prod2, and Prod3 clusters experienced intermittent widget load failures and increased load times when accessing AIDI 2.0 dashboards on July 22, 2026. Not all widgets were affected simultaneously the issue manifested as sporadic failures rather than a full outage.
No customer data was lost. SEI 1.0 customers were not impacted.
## Root Cause
Over time, a routine database maintenance process failed to run on certain tables in our analytics database, causing those tables to accumulate a large volume of internal metadata used to track deleted records. When the database planned queries against these tables, it loaded all of this accumulated metadata into memory, causing memory usage on the affected nodes to spike repeatedly. These repeated spikes triggered an automatic safety mechanism that restarts a node when it detects excessive memory pressure, and the affected nodes began restarting in a loop as a result. This caused intermittent, degraded query performance on AIDI 2.0 dashboards for the duration of the incident.
## Impact
Customers on Prod1, Prod2, and Prod3 clusters may have experienced intermittent widget load failures or increased load times on AIDI 2.0 dashboards.
**Duration:** July 22, 2026, 07:58 PDT – 16:16 PDT \(~8 hours 18 minutes\), with intermittent widget failures; system was restarted and under active monitoring from 08:25 PDT onward.
### 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 issue, the affected database nodes were restarted at 08:25 PDT, which restored initial stability. We continued to monitor the system closely, and when intermittent degradation was still observed afterward, we applied several additional fixes:
* Adjusted database configuration settings to limit the amount of memory used for processing accumulated metadata, and tuned query-planning settings to reduce memory pressure.
* Ran cleanup jobs to reduce the backlog of accumulated metadata on the affected tables.
* Increased capacity on the affected database nodes to provide additional headroom.
These changes progressively stabilized the system, and the incident was fully resolved at 16:16 PDT.
## Action Items
To prevent recurrence, we are implementing the following:
1. We have upgraded the backend which includes underlying improvements that handle memory spikes caused by excessive delete files.
2. We have rolled out automated compaction jobs for newly introduced tables to prevent delete file accumulation going forward.
Automatisch aus der offiziellen Störungsmeldung übersetzt.
Geminderte CI-Leistung
Beginn 17. Juli 2026 um 17:16 UTC · 4h 40m
IssuesGeringfügiger Vorfall
Betroffene Komponenten
Continuous Integration Enterprise(CIE) - Windows Cloud BuildsContinuous Integration Enterprise(CIE) - Self Hosted RunnersContinuous Integration Enterprise(CIE) - Linux Cloud BuildsContinuous Integration Enterprise(CIE) - Mac Cloud Builds
investigating
Wir untersuchen derzeit dieses Problem.
identified
Das Problem wurde identifiziert und ein Fix wird implementiert.
monitoring
Ein Fix wurde implementiert und wir überwachen die Ergebnisse.
resolved
Dieser Vorfall wurde behoben.
postmortem
# Zusammenfassung
Am 17. Juli 2026 begannen Kunden mit älteren Delegiertenversionen (858xx und darunter) nach einer routinemäßigen Codebereitstellung mit verzögerten CI-Builds auf Harness Cloud-gehosteten Builds mit unserer globalen Build-Warteschlangen-Fähigkeit. Betroffene Builds erlebten eine unerwartete Pause von bis zu etwa 8 Minuten in der Phase "Warten auf Infrastruktur", bevor sie fortfuhren, anstatt innerhalb der erwarteten Untersekundenzeit fortzufahren. Insgesamt Aufbau Langsamkeit war intermittierend.
# Auswirkungen
* Alle CI-Builds waren potenziell verzögerungsbehaftet; die Auswirkungen waren bei Builds auf Harness Cloud-gehosteter Infrastruktur mit der globalen Build-Warteschlangen-Funktion am stärksten ausgeprägt.
* Betroffene Builds erlebten eine unerklärliche Pause von bis zu ca. 8 Minuten vor dem Weiterfahren, gefolgt von einem langsameren "Kaltstart", da ein vorreservierter Rechenplatz nicht verfügbar war - dies wurde den Benutzern als langsame Builds und nicht als Buildfehler angezeigt.
* Konten, die auf neueren Delegiertenversionen (858xx und höher) ausgeführt werden, waren nicht betroffen.
* Keine Builds scheiterten als direkte Folge dieses Problems und es gingen keine Daten verloren.
# Wurzelursache
Die Ursache war eine interne Codeänderung, die versehentlich brach, wie ein bestimmter Build-Warteschlangen-Datensatz aus unserer Datenbank zurückgelesen wurde, sobald Builds, die bereits unter der vorherigen Version des Codes in der Warteschlange standen, auf die neu bereitgestellte Version stießen. Wir haben die unmittelbaren Auswirkungen behoben, indem wir die betroffenen Datensätze bereinigt und die zugrunde liegende Codeänderung rückgängig gemacht haben, und wir implementieren mehrere Sicherheitsvorkehrungen, um zu verhindern, dass sich diese Klasse von Problemen wiederholt.
# Nächste Schritte
Wir bewerten das Risiko einer ähnlichen Wiederholung so gering, wie die folgenden Maßnahmen unterschätzt werden. Der spezifische Codepfad, der diesen Vorfall verursacht hat, wurde bereits rückgängig gemacht, und wir implementieren strukturelle Sicherheitsvorkehrungen, damit diese allgemeine Klasse von Problemen nicht wieder auftreten kann, unabhängig davon, wo sie sonst in der Codebasis auftreten könnten.
| **Korrektive / Präventivmaßnahmen** |
| --- |
Fügen Sie allen internen Datenklassen, die in unserer Datenbank gespeichert werden, explizite, stabile Identifikatoren hinzu, damit zukünftige interne Code-Reorganisationen die Fähigkeit des Systems, zuvor gespeicherte Datensätze zurückzulesen, nicht beeinträchtigen können. |
Einführung von Rollback- und Rückwärtskompatibilitätstests in unserer Vorproduktionsumgebung, die speziell darauf ausgelegt ist, diese Problemklasse zu erfassen, bevor sie die Produktion erreicht. |
Automatisch aus der offiziellen Störungsmeldung übersetzt.