Störungsverlauf von Harness

1. 27. Oktober 2026 um 19:52 UTCinvestigating

   Wir untersuchen derzeit dieses Problem.

2. 27. Oktober 2026 um 19:58 UTCinvestigating

   CI-Pipelines auf VM-Infrastruktur scheitern beim Schritt Initialisieren, weil die Aufgabe an einen Delegierten außerhalb des vorgesehenen Pools geht

3. 27. Oktober 2026 um 21:15 UTCidentified

   Das Problem wurde identifiziert und ein Fix wird implementiert.

4. 27. Oktober 2026 um 22:16 UTCmonitoring

   Ein Fix wurde implementiert und wir überwachen die Ergebnisse.

5. 27. Oktober 2026 um 22:24 UTCresolved

   Dieser Vorfall wurde behoben.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 19. Oktober 2026 um 07:46 UTCinvestigating

   Wir untersuchen derzeit dieses Problem.

2. 19. Oktober 2026 um 08:02 UTCidentified

   Das Problem wurde identifiziert und ein Fix wird implementiert.

3. 19. Oktober 2026 um 08:04 UTCmonitoring

   Ein Fix wurde implementiert und wir überwachen die Ergebnisse.

4. 19. Oktober 2026 um 08:21 UTCresolved

   Dieser Vorfall wurde behoben.

5. 23. Oktober 2026 um 18:21 UTCpostmortem

   ## **Zusammenfassung** Am 19. Oktober 2026, zwischen ca. 12:10 Uhr und 12:55 Uhr PDT, erlebten Kunden auf Prod4 Fehler und intermittierende Nichtverfügbarkeit von Harness Pipelines Services. Schwere Pipeline-Ausführungen führten zu einem starken Anstieg der CPU- und Speichernutzung im Pipeline-Service, und für kurze Zeit waren alle Service-Instanzen nicht verfügbar. Harness Engineering skalierte den Service sowohl vertikal als auch horizontal, wodurch der Service wiederhergestellt wurde. Ein Fix für das zugrunde liegende Verhalten wird ausgerollt. ## **Wurzelursache** Am 19. Oktober führte eine hohe Anzahl von gleichzeitigen Ausführungsgraphen mit sehr großen Ausführungsgraphen zu einem starken Anstieg der Clusterressourcen. Der Dienst speichert und ruft diesen Vollausführungsgraphen für Visualisierungszwecke und den weiteren Fortschritt der Pipelines in die nächsten Zustände ab. Unsere Auto-Scalaer auf Prod4 brauchten länger als üblich für die Skalierung von Ressourcen aufgrund eines starken Anstiegs von CPU und Speicher. Als Teil des Fixes verarbeitet das Ausführungsdiagramm-Update nun inkrementell Graphenänderungen anstelle des vollständigen Graphen. Sie wird phasenweise ausgerollt und wird frühestens vollständig ausgerollt. ## **Auswirkungen** * Betroffene Nutzer: Kunden auf Prod4. * Symptom: Nichtverfügbarkeit der Pipeline-Funktionalität in der Harness-Plattform. * Daten: Kein Datenverlust. * Vorgeschlagener Workaround: Keine Anforderung von Kunden. Harness Engineering hat das Problem gelöst. * Dauer des Aufpralls: Ca. 20 Minuten vollständige Nichtverfügbarkeit und verminderte Leistung für 25 Minuten. Harness setzte die Überwachung nach der Wiederherstellung fort und bestätigte die Plattformstabilität bei den Kunden. ## **Abhilfe** ** Sofort** Harness Engineering skalierte den Pipeline-Service sowohl vertikal (mehr Ressourcen pro Instanz) als auch horizontal (mehr Instanzen) und entfernte Instanzen in einem ungesunden Zustand. Die Anzahl der Instanzen wurde stabilisiert und der normale Dienst wurde wiederhergestellt. Das System bleibt skaliert, bis der Fix vollständig ausgerollt ist. **Permanent Fix und Action Items** Um zu verhindern, dass sich solche Probleme wiederholen, ist Harness 1. Den Autoheil-/Skalierungsprozess so einstellen, dass der Aufprall mimimal zu Null ist. 2. Optimierung des Ausführungsgraphenflusses, damit große Graphen schneller verarbeitet werden können.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 15. Oktober 2026 um 10:10 UTCinvestigating

   Wir untersuchen derzeit dieses Problem.

2. 15. Oktober 2026 um 10:10 UTCidentified

   Das Problem wurde identifiziert und ein Fix wird implementiert.

3. 15. Oktober 2026 um 10:27 UTCresolved

   Dieser Vorfall wurde behoben.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 15. Oktober 2026 um 08:04 UTCinvestigating

   Wir untersuchen derzeit dieses Problem.

2. 15. Oktober 2026 um 08:05 UTCidentified

   Das Problem wurde identifiziert und ein Fix wird implementiert.

3. 15. Oktober 2026 um 08:09 UTCmonitoring

   Ein Fix wurde implementiert und wir überwachen die Ergebnisse.

4. 15. Oktober 2026 um 08:15 UTCresolved

   Dieser Vorfall wurde behoben.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 13. Oktober 2026 um 01:06 UTCinvestigating

   Wir untersuchen derzeit dieses Problem.

2. 13. Oktober 2026 um 01:07 UTCidentified

   Das Problem wurde identifiziert und ein Fix wird implementiert.

3. 13. Oktober 2026 um 01:56 UTCmonitoring

   Ein Fix wurde implementiert und wir überwachen die Ergebnisse.

4. 13. Oktober 2026 um 04:29 UTCresolved

   Dieser Vorfall wurde behoben.

5. 23. Oktober 2026 um 03:16 UTCpostmortem

   . .

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 12. Oktober 2026 um 15:25 UTCinvestigating

   Wir erleben derzeit HTTP 429 (ratenbegrenzende) Fehler, wenn Harness Cloud den Zugriff auf Maven Central erstellt, was sich auf die Buildausführung auswirken kann. Unser Team arbeitet aktiv mit Sonatype zusammen, um das Problem so schnell wie möglich zu lösen. Wir werden weitere Updates bereitstellen, wenn wir Fortschritte machen.

2. 12. Oktober 2026 um 19:31 UTCresolved

   Dieser Vorfall wurde behoben.

3. 23. Oktober 2026 um 03:06 UTCpostmortem

   tldr: \(Es gab eine kurze Preisbegrenzung durch maven central\) Weitere Details folgen

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 8. Oktober 2026 um 10:23 UTCmonitoring

   Ein Fix wurde implementiert und wir überwachen die Ergebnisse.

2. 8. Oktober 2026 um 10:53 UTCresolved

   Dieser Vorfall wurde behoben.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 6. Oktober 2026 um 21:46 UTCinvestigating

   Wir untersuchen derzeit dieses Problem.

2. 6. Oktober 2026 um 21:47 UTCinvestigating

   Wir werden dieses Problem weiter untersuchen.

3. 6. Oktober 2026 um 22:03 UTCidentified

   Das Problem wurde identifiziert und ein Fix wird implementiert.

4. 6. Oktober 2026 um 22:30 UTCmonitoring

   Ein Fix wurde implementiert und wir überwachen die Ergebnisse.

5. 6. Oktober 2026 um 22:30 UTCmonitoring

   Ein Fix wurde implementiert und wir überwachen die Ergebnisse. Wir haben eine Bestätigung dafür, dass das Problem behoben wurde.

6. 6. Oktober 2026 um 22:44 UTCresolved

   Dieser Vorfall wurde behoben.

7. 23. Oktober 2026 um 02:12 UTCpostmortem

   # 1. Zusammenfassung Am 6. Oktober 2026 konnten Pipelines, die eine IaCM-Stufe enthielten, für etwa zwei Stunden nicht mit Prod1 starten. Betroffene Benutzer sahen einen Fehler, als die Pipeline versuchte, ihren Ausführungsplan zu erstellen. Pipelines, die keine IaCM-Stufe verwendeten, liefen weiterhin normal. Die zugrunde liegende Ursache war ein interner Protokollierungsfehler im Dienst, der die Ausführung der IaCM-Stufe übernimmt: Unter einer bestimmten, seltenen Timing-Bedingung könnte das diensteigene Protokollierungssystem auf unbestimmte Zeit auf sich warten, was wiederum den breiteren Prozess, der für die Erstellung von Pipeline-Ausführungsplänen verantwortlich ist, zum Stillstand bringt. Das Problem wurde durch einen ungewöhnlich großen Ausbruch der Protokollaktivität aus der Pipeline eines Kunden ausgelöst. Wir haben die unmittelbaren Auswirkungen behoben, indem wir den Dienst auf seine vorherige stabile Version zurückgesetzt haben, und ein permanenter Code-Fix wird derzeit getestet. #2 Auswirkungen * Alle Pipelines mit einer IaCM-Stufe auf Prod1 konnten etwa zwei Stunden lang nicht starten. * Mehrere Kunden des Prod1-Clusters waren betroffen. * Pipelines, die keine IaCM-Stufe verwendeten, waren nicht betroffen und liefen normal weiter. * Es gingen keine Daten infolge dieses Vorfalls verloren. * Als Nebeneffekt des Rollbacks, der zur Behebung dieses Vorfalls verwendet wurde, wurde ein unabhängiger Fix für einen Kunden (der verlängert, wie lange ein bestimmtes Authentifizierungstoken während lang laufender Pipelines gültig bleibt) vorübergehend rückgängig gemacht. Dieser Fix wurde am selben Abend erneut angewendet. #3. Wurzelursache Der für die IaCM-Pipeline-Phasen zuständige Dienst protokolliert seine Aktivität über eine interne Warteschlange: Protokollnachrichten werden in die Warteschlange gelegt, und ein einzelner Hintergrundmitarbeiter liest kontinuierlich daraus und schreibt die Nachrichten aus. Unabhängig davon verfügt dieser Dienst über einen Filter, der den Schweregrad bestimmter Protokollnachrichten in dieselbe Warteschlange zurückschreiben kann. Unter einer bestimmten, engen Timing-Bedingung führte dies zu einem Stillstand, wenn die Warteschlange genau in dem Moment, in dem eine neu geschriebene Nachricht zurückgesendet wurde, völlig voll war, würde der eine Arbeiter, der dafür verantwortlich war, Platz in der Warteschlange freizugeben, selbst stecken bleiben und darauf warten, dass der Raum frei wird, eine Bedingung, die er nie lösen konnte, da es das einzige war, was diesen Raum befreit haben konnte. Sobald dies geschah, blieb auch jeder andere Teil des Dienstes, der etwas protokollieren musste, warten, was in den Pipeline-Plan-Erstellungsprozess eintrat und für jede Pipeline mit einer IaCM-Stufe fehlschlug. # 4. Entschließungsantrag * Rollte den Dienst zurück zu seiner letzten stabilen Version, die den unmittelbaren Vorfall löste. # 5. Präventivmaßnahmen 1. **Optimieren Sie den zugrunde liegenden Defekt**: Optimieren und stimmen Sie den Protokollierungsfilter so ab, dass das Umschreiben des Schweregrads einer Nachricht in dem Thread erfolgt, der die Protokollzeile erzeugt hat, anstatt durch die Warteschlange des gleichen Hintergrundarbeiters erneut gesendet zu werden, wodurch der Deadlock-Zustand vollständig beseitigt wird. 2. **Verbessern Sie die Überwachung des Zustands der Protokollierungswarteschlange **: Fügen Sie Metriken hinzu und alarmieren Sie diese interne Warteschlange, damit diese Klasse von Sättigungsseiten automatisch von unserem Bereitschaftsteam angezeigt werden, anstatt sich auf Kundenberichte zu verlassen. 3. **Grenzwerte bewerten und hohe Belastungstests mit sehr großen Pipelines durchführen**:

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 16. Oktober 2026 um 10:41 UTCresolved

   Am 7. Oktober 2026, von 08:00 Uhr UTC bis 11:00 Uhr UTC (1:30 Uhr bis 16:30 Uhr IST), sahen einige Pipeline-Ausführungen auf dem Prod 7-Cluster intermittierende Fehler in den Schrittbewertungen von Policy (OPA).

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 6. Oktober 2026 um 12:54 UTCmonitoring

   Ein Fix wurde implementiert und wir überwachen die Ergebnisse.

2. 6. Oktober 2026 um 15:35 UTCresolved

   Dieser Vorfall wurde behoben.

3. 10. Oktober 2026 um 01:57 UTCpostmortem

   ### Zusammenfassung Kunden auf Prod 2 erlebten beim Start intermittierende Ausfälle einiger Verify-Schritte. Betroffene Schritte scheiterten kurz nach dem Start mit einer Meldung, die angibt, dass Continuous Verification (CV) keinen internen Harness-Service erreichen konnte. Das Problem rührte von einem kürzlichen Service-Update her, das Verbindungspooling einführte, um die Leistung und Zuverlässigkeit mit einer Keep-alive-Einstellung zu verbessern, die mit dem Timeout des Empfangsdienstes nicht kompatibel ist. Es wurden keine Kundendaten verloren oder beschädigt. ### Customer Impact Kunden, die CV Verify-Schritte auf Prod-2 verwenden, haben während des Ereignisfensters intermittierende Schrittfehler festgestellt. Die Ausfallrate war gering - die Mehrheit der Ausführung wurde im gesamten Fenster erfolgreich abgeschlossen. Pipelines, die keine CV-Verify-Schritte verwendeten, waren nicht betroffen. ### Wurzelursache Ein kürzliches CV-Service-Update führte das Verbindungspooling zu einer internen Plattformkomponente mit einer Keep-alive-Dauer ein, die länger ist als die Leerlaufzeit dieser Komponente. Verbindungen, die lange genug im Leerlauf waren, wurden vom Server stillschweigend geschlossen; der CV-Dienst erkannte dies nicht und hatte keine Wiederhollogik für solche Fehler, was dazu führte, dass sie direkt auftauchten, wenn Schrittfehler überprüft wurden. Das Problem war intermittierend, weil es nur Verbindungen betraf, die lange genug im Leerlauf waren, um abzulaufen. ### Mitigation Die Dauer des Haltens der Verbindung wurde reduziert, um innerhalb des Leerlauf-Timeouts des Empfangsdienstes zu fallen. Fehler fielen sofort auf nahe Null, und es wurden keine weiteren Schrittfehler dieser Art in einer Produktionsumgebung beobachtet. ### Nächste Schritte Um eine Wiederholung zu verhindern, wird Harness: * **Fix Connection Handling:** Tuned die Standard-Kee-alive und aktivierte automatische Wiederholung auf Verbindungsfehler, so dass veraltete Verbindungsfehler transparent behandelt werden. * **Resilienz beim Schrittstart hinzufügen:** Wiederholen mit Backoff für den internen Serviceaufruf beim Schrittstart Verifizieren, so dass isolierte transiente Fehler nicht als unmittelbare Schrittfehler auftauchen. * **Verbessere die Alarmierung:** Verbesserte Überwachung auf interne Verbindungsfehlerraten.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 6. Oktober 2026 um 11:58 UTCinvestigating

   Wir untersuchen derzeit dieses Problem.

2. 6. Oktober 2026 um 11:59 UTCinvestigating

   Wir werden dieses Problem weiter untersuchen.

3. 6. Oktober 2026 um 12:24 UTCidentified

   Das Problem wurde identifiziert und ein Fix wird implementiert.

4. 6. Oktober 2026 um 16:21 UTCresolved

   Dieser Vorfall wurde behoben.

5. 9. Oktober 2026 um 18:48 UTCpostmortem

   ## Zusammenfassung Am **Dienstag, den 6. Oktober 2026 ** sind IaCM-Pipelines, die das **OpenTofu-Plugin ** in **Prod1 ** verwenden, intermittierend für ein Produktionskonto fehlgeschlagenBetroffene führen injizierte Geheimnisse erfolgreich aus, später werden die Schritte zeitversetzt oder die Authentifizierung fehlgeschlagen. Die gleiche Pipeline gelang oft beim Wiederholen, ohne Konfigurationsänderung. Typische fehlgeschlagene Hinrichtungen liefen etwa 90 Minuten. Andere Harness-Module waren nicht umfassend betroffen. Wir haben keinen Bericht über den Verlust von Kundendaten. Pipelines, die innerhalb der Token-Lebensdauer fertig waren, waren von diesem Defekt nicht betroffen. ## Wurzelursache Die IaCM-Stufen prägten Authentifizierungstoken, die nach einer Stunde abgelaufen waren. Policy-Checks später in einem langen Lauf lehnten dann das Token ab, so dass der Schritt zeitversetzt oder die Authentifizierung fehlschlug. Diese einstündige Lebensdauer wurde festgelegt. Läufe von etwa 90 Minuten überschritten die 1-Stunden-Marke, weshalb die Ausfälle bei längeren Pipelines auftauchten und oft bei einem kürzeren Wiederholungsversuch gelöscht wurden. Ein separater Satz von Planfehlern im selben Konto stammt aus der Anmeldeinformationen-Einrichtung im Kundenarbeitsbereich und liegt außerhalb dieses Vorfalls. ## Auswirkungen * **Produktbereich:** IaCM-Pipelines mit den IaCM-Plugins, die mit OPA sdk sprechen. * ** Kundenerfahrung:** intermittierende Timeouts und Authentifizierungsfehler nach geheimer Injektion bei Läufen von mehr als einer Stunde. * **Umwelt:** Prod1, ein Produktionskonto * **Daten:** Kein Datenverlust gemeldet. ## Sanierung * **Sofort:** Öffnete eine Statusseite für das betroffene Prod1-Konto und versendete einen vorläufigen IaCM-Managerwechsel für eine Klasse der beobachteten Fehler, während der Plugin-Fix erstellt wurde. * **Dauerhaft:** Versendet ein OpenTofu-Plugin-Hotfix, so dass der Token-Ablauf konfigurierbar ist. In der Produktion wurde die Lebensdauer auf etwa 6 Stunden erhöht, so dass eine lange Pipeline das Token nicht überlebt. Der Hotfix wurde in QA validiert und in Prod1 eingesetzt. Wir entschuldigen uns für die verursachte Störung. Bitte wenden Sie sich an Ihren Harness Support-Kontakt, wenn Sie weitere Fragen haben.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 5. Oktober 2026 um 22:01 UTCinvestigating

   Wir untersuchen derzeit dieses Problem.

2. 5. Oktober 2026 um 23:50 UTCidentified

   Das Problem wurde identifiziert und ein Fix wird implementiert.

3. 6. Oktober 2026 um 00:26 UTCmonitoring

   Ein Fix wurde implementiert und wir überwachen die Ergebnisse.

4. 6. Oktober 2026 um 00:26 UTCmonitoring

   Wir werden weiterhin auf weitere Probleme achten.

5. 6. Oktober 2026 um 00:39 UTCresolved

   Überprüfen Sie die behobenen und gelösten SSO-Probleme.

6. 9. Oktober 2026 um 16:17 UTCpostmortem

   ## Okta Application SP-Initiated SSO Login Failures # Zusammenfassung Zwischen dem 5. Oktober 2026, 18:18 UTC und dem 6. Oktober 2026, 00:26 UTC konnten sich einige Harness-Kunden nicht über SAML Single Sign-On (SSO) beim Harness Hosted MCP-Server anmelden. Die Hauptbenutzerauthentifizierung von Harness Portal blieb voll funktionsfähig. Betroffene Benutzer sahen Anmeldefehler oder wurden auf eine ungültige SSO-Seite umgeleitet, anstatt die Anmeldung abzuschließen. Das Problem wurde durch fehlerhafte Änderungen in einem Versionsupgrade des Harness-Identitätsdienstes HarnessID verursacht. Wir haben es mit einer Reihe von Hotfixes behoben und das SSO-Login wurde für alle betroffenen Kunden vollständig wiederhergestellt. # Auswirkungen Benutzer, die sich über SAML SSO bei Harness MCP anmelden, konnten die Authentifizierung nicht abschließen. Bestehende MCP-Sitzungen, die auf SSO angewiesen waren, konnten nicht aktualisiert werden, so dass sich einige Benutzer erneut anmelden mussten und nicht konnten. Nicht-SSO-Logins bei Hosted MCP funktionierten während der meisten Vorfälle. Keine Kundendaten wurden verloren oder ausgesetzt. Kunden, die ihre eigene generische SAML 2.0-Anwendungskonfiguration in Okta verwenden, waren nicht betroffen. # Wurzelursache Am 29. September 2026 wurde eine aktualisierte Version der Harness-Anwendung im Okta Integration Network veröffentlicht. Das Update hat Unterstützung für die Registrierung mehrerer Antwort-URLs hinzugefügt, sodass Kunden, die Harness in mehreren Regionen oder Umgebungen ausführen, mehr als eine Callback-URL konfigurieren können. Harness enthält einen AssertionConsumerServiceURL-Wert in der SAML-Authentifizierungsanforderung, die es an Okta sendet. Vor diesem Update hat Okta diesen Wert nicht für Anwendungsinstanzen ohne zusätzliche ACS-URLs validiert und stattdessen die SAML-Behauptung an die Standard-ACS-URL der Anwendung zurückgegeben. Nach dem Update wurde diese Validierung in allen bestehenden Anwendungsinstanzen aktiv, auch in solchen, in denen der Kunde noch nie eine zusätzliche ACS-URL konfiguriert hatte. Da der angeforderte Wert in der registrierten Liste der Instanz nicht vorhanden war, gab Okta einen HTTP 400-Fehler zurück. Die aktualisierte Anwendung durchlief die Standard-OIN-Publishing-Überprüfung von Okta, die eine Rückwärtskompatibilitätsprüfung mit vorhandenen Installationen der veröffentlichten Integration beinhaltet. Diese Änderung des Validierungsverhaltens für Instanzen ohne zusätzliche ACS-URLs wurde während dieser Überprüfung nicht aufgetaucht, so dass sie zum Zeitpunkt der Veröffentlichung Kunden erreichte. # Sanierung ** Sofortige Antwort** Zwei Workarounds wurden auf der Statusseite veröffentlicht: Melden Sie sich von der Harness-Kachel in Okta an \(IdP-initiated login\), die nicht betroffen war, oder registrieren Sie die Okta SSO-URL der Anwendung im Feld Zusätzliche ACS-URLs der Harness Okta-Anwendung. Harness engagierte jeden gemeldeten betroffenen Kunden direkt und validierte seine Anmeldung. **Resolution** Das Zurückrollen der Anwendung auf die vorherige Version wurde bewusst vermieden, da dies die gleiche Störung nur auf das nächste Release verschieben würde. Jeder betroffene Kunde wurde stattdessen durch die ACS-URL-Registrierung freigegeben, und wir arbeiten mit Okta daran, die ACS-URL-Validierung wieder an Bedingungen zu knüpfen, damit sich Instanzen ohne zusätzliche ACS-URLs genauso verhalten wie zuvor und keine Kundenaktion erforderlich ist. # Aktionspunkte Um zu verhindern, dass solche Probleme erneut auftreten, wird Harness die folgenden Maßnahmen ergreifen: 1. Arbeiten mit Okta, um die bedingte ACS-URL-Validierung wiederherzustellen, so dass sich Instanzen ohne zusätzliche ACS-URLs genau wie zuvor verhalten und keine Kundenaktion erforderlich ist. 2. Veröffentlichung eines dedizierten Konfigurationshandbuchs für die Harness OIN-Anwendung in der Harness-Dokumentation, einschließlich der URL-Anforderungen für die Antwort (ACS). 3. Fügen Sie einen unabhängigen Vorabverifizierungsschritt für bestehende Kundenkonfigurationen hinzu, um zukünftige Aktualisierungen der veröffentlichten Okta-Anwendung neben der eigenen Überprüfung von Okta durchzuführen. 4. Migration der Benutzerauthentifizierung zu Harness ID, die die Abhängigkeit von diesem Validierungsverhalten vollständig beseitigt.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 29. September 2026 um 20:31 UTCinvestigating

   Wir untersuchen derzeit dieses Problem.

2. 29. September 2026 um 20:31 UTCidentified

   Das Problem wurde identifiziert und ein Fix wird implementiert.

3. 29. September 2026 um 20:57 UTCidentified

   Wir haben ein Problem identifiziert, das nur für die von SP initiierte Anmeldung über die veröffentlichte Harness Okta-Anwendung gilt. Nach einer kürzlichen Aktualisierung dieser Anwendung haben diese Anmeldeversuche einen HTTP 400-Fehler zurückgegeben, wenn die konfigurierte SSO-URL in zusätzlichen ACS-URLs fehlte. Allgemeine SAML 2.0-Konfigurationen in Okta sind nicht betroffen. Sofortige Lösungen: Verwenden Sie IDP-initiiertes Login. Starten Sie das Login über das Harness-Anwendungskachel in Okta. oder Fügen Sie Ihre Harness SSO-URL zu zusätzlichen ACS-URLs in der veröffentlichten Harness Okta-Anwendung hinzu.

4. 2. Oktober 2026 um 00:33 UTCresolved

   Dieser Vorfall wurde behoben.

5. 7. Oktober 2026 um 18:30 UTCpostmortem

   # 1. Zusammenfassung Ab dem 29. September 2026 konnten Kunden, die sich über die veröffentlichte Harness-Anwendung im Okta Integration Network (OIN) bei Harness anmelden, das von SP initiierte SSO-Login nicht abschließen. Betroffene Benutzer erhielten einen HTTP 400-Fehler von Okta, anstatt angemeldet zu werden. Das Problem wurde durch eine Änderung eingeführt, wie Okta die angeforderte Antwort-URL (ACS) für bestehende Installationen der veröffentlichten Harness-Anwendung validiert hat. Workarounds wurden innerhalb einer Stunde nach dem ersten Bericht veröffentlicht und jeder betroffene Kunde wurde freigegeben. #2 Auswirkungen * Die Auswirkungen waren auf Kunden beschränkt, die die veröffentlichte Harness-Anwendung aus dem Okta Integration Network für SP-initiiertes Login verwenden (Anmeldung von Harness starten). Diese Versuche gaben einen HTTP 400-Fehler von Okta zurück. * Der von IdP initiierte Login, der von der Harness-Kachel in Okta aus gestartet wurde, funktionierte durchgehend weiter. * Kunden, die ihre eigene generische SAML 2.0-Anwendungskonfiguration in Okta verwenden, waren nicht betroffen. * Keine Kundendaten wurden verloren oder ausgesetzt. #3. Wurzelursache Am 29. September 2026 wurde eine aktualisierte Version der Harness-Anwendung im Okta Integration Network veröffentlicht. Das Update hat Unterstützung für die Registrierung mehrerer Antwort-URLs hinzugefügt, sodass Kunden, die Harness in mehreren Regionen oder Umgebungen ausführen, mehr als eine Callback-URL konfigurieren können. Harness enthält einen AssertionConsumerServiceURL-Wert in der SAML-Authentifizierungsanforderung, die es an Okta sendet. Vor diesem Update hat Okta diesen Wert nicht für Anwendungsinstanzen validiert, für die keine zusätzlichen ACS-URLs konfiguriert waren, und einfach die SAML-Anweisung an die Standard-ACS-URL der Anwendung zurückgegeben. Nach dem Update wurde diese Validierung für alle vorhandenen Instanzen der Anwendung aktiv, einschließlich derjenigen, in denen der Kunde noch nie eine zusätzliche ACS-URL konfiguriert hatte. Da der angeforderte Wert in der registrierten Liste der Instanz nicht vorhanden war, lehnte Okta die Authentifizierungsanforderung mit einem HTTP 400-Fehler ab. Die aktualisierte Anwendung durchlief die Standard-OIN-Publishing-Überprüfung von Okta, die eine Überprüfung der Abwärtskompatibilität mit vorhandenen Installationen einer veröffentlichten Integration beinhaltet. Diese Änderung des Validierungsverhaltens für Instanzen ohne zusätzliche ACS-URLs wurde während dieser Überprüfung nicht aufgetaucht, so dass sie Kunden bei der Veröffentlichung erreichte. # 4. Sanierung ** Sofortige Antwort** Zwei Workarounds wurden auf der Statusseite veröffentlicht: Melden Sie sich von der Harness-Kachel in Okta an \(IdP-initiiertes Login\), die nicht betroffen war; oder registrieren Sie die Okta SSO-URL der Anwendung im Feld Zusätzliche ACS-URLs der Harness Okta-Anwendung. Der Support hat jeden betroffenen Kunden direkt eingebunden und die Anmeldung mit ihm validiert. **Resolution** Das Zurückrollen der Anwendung auf die vorherige Version wurde bewusst vermieden, da dies die gleiche Störung nur auf das nächste Release verschieben würde. Jeder betroffene Kunde wurde stattdessen durch die ACS-URL-Registrierung freigegeben, und wir arbeiten mit Okta daran, die ACS-URL-Validierung wieder an Bedingungen zu knüpfen, damit sich Instanzen ohne zusätzliche ACS-URLs genauso verhalten wie zuvor und keine Kundenaktion erforderlich ist. # 5. Aktionspunkte Um zu verhindern, dass sich solche Probleme wiederholen, arbeiten wir daran | **Aktionspunkt** | | --- | | Arbeiten mit Okta, um die bedingte ACS-URL-Validierung wiederherzustellen, sodass sich Instanzen ohne zusätzliche ACS-URLs genauso verhalten wie zuvor und keine Kundenaktion erforderlich ist. | | Veröffentlichen Sie ein dediziertes Konfigurationshandbuch für die Harness OIN-Anwendung in der Harness-Dokumentation, einschließlich der URL-Anforderungen von answer \(ACS\). | | Fügen Sie einen unabhängigen Vorabverifizierungsschritt mit bestehenden Kundenkonfigurationen für zukünftige Updates der veröffentlichten Okta-Anwendung hinzu, neben Oktas eigener Überprüfung. | Migration der Benutzerauthentifizierung zu Harness ID, die die Abhängigkeit von diesem Validierungsverhalten vollständig beseitigt. |

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 29. September 2026 um 18:45 UTCinvestigating

   Wir untersuchen derzeit dieses Problem.

2. 29. September 2026 um 21:55 UTCmonitoring

   Ein Fix wurde implementiert und wir überwachen die Ergebnisse.

3. 29. September 2026 um 22:01 UTCresolved

   Dieser Vorfall wurde behoben.

4. 2. Oktober 2026 um 22:40 UTCpostmortem

   ### Zusammenfassung Zwischen ca. **11:37 Uhr und 3:01 Uhr PDT \(18:37–22:01 UTC\) am 29. September 2026** erlebten Kunden, die Harness CI selbst gehostete Linux-Cloud-Runner in **prod1/prod2 \(us-west1\)** verwendeten, intermittierende Netzwerkausfälle während der Pipelineausführung - hauptsächlich Git / Netzwerk-Timeouts beim Abrufen von Quellcode. **Wurzelursache** Dies war in erster Linie auf die Sättigung unseres NAT zurückzuführen, die durch eine temporäre Rechenkapazität von Cloud-Anbietern weiter verschärft wurde, wodurch eine neue VM-Bereitstellung verhindert wurde. ### Auswirkungen * Kunden, die selbst gehostete Linux-CI-Builds in us-west1 ausführen, sahen **intermittierende Build-/Pipeline-Ausfälle **, keinen vollständigen Ausfall. * Zu den beobachteten Fehlern beim Kunden gehörten Git-Fetch-Timeouts, z. B. „Failed to connect to github.com port 443: Connection timed out. **Abhilfe ** * ** Sofort: ARM Build-VM-Last aus dem gesättigten us-west1-Pfad in Richtung Central1 neu ausbalanciert (teilweise durch Central1-Kapazität begrenzt); die betroffenen Cloud NAT-Gateways neu gestartet, was die Pipeline-Vernetzung stabilisiert hat. **Aktionspunkte ** 1. Sichern Sie zusätzliche NAT-Gateway / IP-Kapazität \(In Arbeit\) 2. Verbesserung der NAT-Sättigungserkennung und Alarmierung vor den Auswirkungen auf den Kunden. 3. Regionsübergreifende Kapazitätskontingenzen bewerten, damit der Rechenmangel einer einzelnen Region die Failover-Abschwächung nicht blockiert.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 29. September 2026 um 14:41 UTCinvestigating

   Wir untersuchen derzeit dieses Problem.

2. 29. September 2026 um 15:54 UTCmonitoring

   Ein Fix wurde implementiert und wir überwachen die Ergebnisse.

3. 29. September 2026 um 15:57 UTCmonitoring

   Wir werden weiterhin auf weitere Probleme achten.

4. 29. September 2026 um 18:49 UTCresolved

   Dieser Vorfall wurde behoben.

5. 2. Oktober 2026 um 05:37 UTCpostmortem

   **Zusammenfassung** Kunden von Prod-2 erlebten erhöhte Fehlerraten in Continuous Verification-Pipelines. Verifizierungsaufträge konnten keine Fehler ausführen oder gemeldet werden, da CV-Datenerfassungsmitarbeiter nicht mit dem Plattformdienst kommunizieren konnten, der ihre Arbeit koordiniert. Dies wurde durch einen unerwarteten Traffic-Spike zu einem unserer Backend-Systeme verursacht. Der Service wurde durch Skalierung der betroffenen Plattformkomponente wiederhergestellt. Es gab keinen Datenverlust oder Korruption. **Kundeneinfluss** Kunden, die Continuous Verification auf Prod-2 verwenden, haben festgestellt, dass Verifizierungs-Pipeline-Jobs während des Ereignisfensters fehlschlagen oder ausfallen. Ein erheblicher Teil der Verifizierungsauftragsinstanzen, die in diesem Zeitraum ausgeführt wurden, endete mit einem Betriebsausfall. Pipelines, die keinen CV verwenden, arbeiteten weiterhin normal. **Wurzelursache** Ein großer automatisierter Bereitstellungslauf schuf eine erhebliche Anzahl von persistenten CV-Monitoring-Mitarbeitern in einem kurzen Fenster, was eine gemeinsame Plattformkomponente überforderte. Der plötzliche Anstieg der gleichzeitigen ausgehenden Anrufe erschöpfte die verfügbaren Netzwerkverbindungen in jeder Dienstinstanz. **Abschwächung** Die maximale Skalierungsgrenze für den CV-Service wurde angehoben, so dass er die Kapazität erweitern konnte, um die Nachfrage zu decken. Die Ausfälle hörten kurz nach dem Scale-out auf. **Nächste Schritte** Um eine Wiederholung zu verhindern, wird Harness: * **Erhöhen Sie die Kapazitätsreserve und fügen Sie Bereitstellungsleitplanken hinzu: ** Heben Sie das CV-Service-Skalierungslimit an, um den Headroom unter Berstlasten zu halten, und führen Sie eine Tarifbegrenzung für die Bereitstellung von Massendiensten für überwachte Dienste ein. * **Verbesserung der Resilienz:** Fügen Sie exponentielles Backoff und Jitter für Worker Retries hinzu und verwenden Sie einen wiederverwendbaren Verbindungspool, um den Overhead zu reduzieren und zu verhindern, dass sich vorübergehende Ausfälle unter hoher Gleichzeitigkeit zusammenfügen. * **Verbessern Sie die Überwachung und Alarmierung:** Verbessern Sie die Alarmierung auf abnormale Pro-Account-Arbeiterwachstumsraten, so dass ähnliche Bedingungen früher erkannt und gehandelt werden.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 29. September 2026 um 13:12 UTCresolved

   Am 28. September 2026 beobachteten wir ein Problem beim Kopieren von Dateien aus dem Harness Filestore während des Exportschritts, bei dem die Dateien als null / leere Dateien kopiert wurden. Infolgedessen wurden alle Pipelines, die Filestore-APIs verwenden, während des Ereignisfensters blockiert. Das Problem wurde durch einen Feature Flag-Rollout verursacht, der nach Entdeckung des Problems rückgängig gemacht wurde. Alle Operationen sind wieder normal.

2. 1. Oktober 2026 um 17:28 UTCpostmortem

   ### Zusammenfassung Am 28. September 2026 erlebten einige Kunden von Prod-2 Fehler in CD-Pipeline-Schritten, bei denen File Store-Inhalte mit Pipeline-Ausdrücken gelesen wurden (z. B. ``\). Betroffene Ausdrücke gaben null anstelle des erwarteten Dateiinhalts zurück, wodurch abhängige Schritte fehlschlagen oder sich falsch verhalten. Das Problem wurde auf ein Plattform-Update zurückgeführt, das die Autorisierungsprüfungen für File Store-APIs verschärfte. Das Update wurde zurückgesetzt und File Store-Ausdrücke funktionieren seitdem normal. ### Customer Impact * Nur Pipeline-Schritte auf Prod-2, die File Store-Inhalte über Ausdrücke lesen, waren betroffen. Pipelines, die keine File Store-Ausdrücke verwenden, waren nicht betroffen. * Betroffene Ausdrücke auf null aufgelöst, wodurch Schritte, die von Konfigurations- oder Einstellungsdateien abhängen, fehlschlagen oder eine falsche Ausgabe erzeugen. * Es wurden keine File Store-Inhalte geändert. Es wurden keine Dateien, Geheimnisse, Anmeldeinformationen oder Artefakte aufgedeckt und keine Daten verloren. ### Wurzelursache Im Rahmen einer laufenden Sicherheitsinitiative führte Harness strengere Autorisierungsprüfungen für mehrere Plattform-APIs ein, einschließlich der API, die File Store-Inhalte bedient. Wenn eine Pipeline einen File Store-Ausdruck auswertet, ruft ein interner Harness-Dienst einen anderen an, um die Datei abzurufen. Die neuen Autorisierungsprüfungen sind fehlgeschlagen, was dazu führte, dass die Anfragen abgelehnt wurden und die Ausdrücke null zurückgaben. ### Mitigation Sobald das Plattform-Update als Ursache identifiziert wurde, wurde es in der gesamten Produktionsumgebung zurückgesetzt. File Store Ausdrücke haben sich seit dem Rollback korrekt aufgelöst. Es ist keine Kundenaktion erforderlich. ### Präventive Maßnahmen und nächste Schritte * **Audit betroffene APIs:** Überprüfen Sie alle APIs, bei denen die strengeren Autorisierungsprüfungen durchgeführt wurden, um sicherzustellen, dass interne Service-to-Service-Aufrufe korrekt berücksichtigt werden. * **Verbessere die Testabdeckung:** Verbessern Sie automatisierte Testsuiten, um die Auswertung von Dateispeicherausdrücken über Pipeline-Ausführungspfade hinweg einzubeziehen

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 23. September 2026 um 20:17 UTCinvestigating

   Wir untersuchen derzeit Verbindungsprobleme, die Kunden betreffen, deren Umgebungen durch Palo Alto Networks Firewalls geschützt sind. Diese Firewalls blockieren Verbindungen zu Harness-APIs, was zu Folgendem führen kann: - Fehlgeschlagene Pipeline-Ausführungen - Unfähigkeit, Anwendungen bereitzustellen - Intermittierende Timeouts beim Zugriff auf die Funktionen der Harness-Plattform - Integrationsfehler mit Tools von Drittanbietern - Konnektivität mit Harness-Plattform delegieren Dieses Problem wird nicht durch einen Harness-Service-Ausfall verursacht, sondern durch Firewall-Regeln auf Ihrer Netzwerkseite. Wir empfehlen Kunden, eine Ausnahme für unsere DNS-Endpunkte zu machen.

2. 24. September 2026 um 08:43 UTCmonitoring

   Minderung verfügbar: Nutzung des durch die Netzwerksicherheitsrichtlinie blockierten Datenverkehrs Wir haben ein Problem festgestellt, bei dem einige Kunden möglicherweise nicht auf Harness zugreifen können, da Harness-Datenverkehr von Palo Alto als "AI-Plattform" eingestuft und anschließend durch die Firewall / INET-Richtlinie des Kunden blockiert wird. Wenn Sie dieses Problem haben: Bitte kontaktieren Sie das Network/Firewall/CyberSecurity-Team Ihres Unternehmens und fordern Sie an, dass der erforderliche Harness-Datenverkehr über Ihre Palo Alto-Firewall-Richtlinie erlaubt wird. Als Minderung können Kunden die URL-Kategorie „AI-Platform für die erforderlichen Harness-Endpunkte zulassen oder die betroffenen Harness-Domains/FQDNs gemäß ihren Sicherheitsrichtlinien zur genehmigten/erlaubten Liste ihrer Organisation hinzufügen. Nachdem die Firewall-Richtlinie aktualisiert wurde, sollte der Zugriff auf Harness wiederhergestellt werden. Wichtig: Die Firewall-Richtlinie wird vom Netzwerk-/Sicherheitsteam des Kunden verwaltet. Wenn der Harness-Endpunkt von Palo Alto falsch kategorisiert wurde, können Kunden auch eine Überprüfung der URL-Kategorie von Palo Alto Networks anfordern.

3. 25. September 2026 um 17:10 UTCresolved

   Nach Rücksprache mit Palo Alto Networks können wir bestätigen, dass am 23. September 2026, app.harness. io wurde vom Palo Alto Networks Team als AI Platform Service kategorisiert. Palo Alto Networks schickte im August eine Mitteilung an die Kunden über die Neuklassifizierung. Diese Änderung kann den AI Platform Service unter eine andere Richtlinie als app.harness stellen. Vorherige regelsatz-kategorisierung, computer und internet-info. Die angewandte Politik ist abhängig von den Kundeneinstellungen. Harness-Kunden sollten diese Kategorisierung und die Warnungen mit ihrem internen Netzwerkteam und Palo Alto Networks besprechen.

4. 13. Oktober 2026 um 04:50 UTCpostmortem

   .

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 22. September 2026 um 16:40 UTCinvestigating

   Wir untersuchen derzeit dieses Problem.

2. 22. September 2026 um 17:14 UTCidentified

   Das Problem wurde identifiziert und ein Fix wird implementiert.

3. 22. September 2026 um 18:01 UTCmonitoring

   Ein Fix wurde implementiert und wir überwachen die Ergebnisse.

4. 22. September 2026 um 18:38 UTCresolved

   Dieser Vorfall wurde behoben.

5. 2. Oktober 2026 um 22:05 UTCpostmortem

   # Zusammenfassung Am 22. September 2026 wurden drei unserer Outbound-Netzwerk-Gateways in einer Region ungesund und begannen, einen kleinen Prozentsatz neuer Outbound-Verbindungsversuche abzulehnen. Das Problem wurde am selben Tag vollständig ohne weitere Wiederholungen oder Folgeauswirkungen gelöst. Die zugrunde liegende Ursache war ein gesättigter interner Verkehrsüberwachungspuffer auf diesen Gateways, der dazu führte, dass ihre Gesundheitschecks zu langsam reagierten und als ungesund eingestuft wurden. # Auswirkungen * Nur drei Gateway-Instanzen in einer Region waren betroffen; andere Regionen und andere Gateways in derselben Region waren nicht betroffen. * Es gab keinen Kaskadierungsfehler, das Problem wurde mit einer einzigen Runde von Gateway-Neustarts vollständig behoben, und danach traten keine Folgeprobleme auf. # Wurzelursache Unsere Outbound-Netzwerk-Gateways betreiben eine interne Komponente, die den Netzwerkverkehr auf operative Sichtbarkeit überwacht. Unter anhaltendem hohem Verkehr wurde der interne Puffer dieser Komponente gesättigt, was zu einem Staudruck führte, der stark genug war, um die eigenen Gesundheitscheck-Reaktionen des Gateways über die Zeit hinaus zu verlangsamen, die unser Load Balancer erlaubt. Sobald dieser Timeout überschritten wurde, markierte der Load Balancer die betroffenen Gateways ungesund und begann, einen Teil der für sie bestimmten neuen Verbindungen abzulehnen. Die tatsächliche Paketweiterleitung funktionierte während des gesamten Vorfalls normal weiter. Dies war speziell ein Gesundheitscheck- und Überwachungspufferproblem, nicht ein Versagen der Kernweiterleitungsfähigkeit der Gateways. # Resolution Die drei betroffenen Gateway-Instanzen wurden manuell neu gestartet, wodurch der gesättigte Überwachungspuffer gelöscht und das normale Gesundheitskontrollverhalten sofort wiederhergestellt wurde. Verbindungsabsagen wurden gestoppt, sobald der Neustart abgeschlossen war, und es war kein weiterer Eingriff erforderlich. # Präventivmaßnahmen | **Action** | --- | | Ersetzen Sie den aktuellen Traffic-Monitoring-Ansatz für alle Gateways durch eine effizientere, kostengünstigere Implementierung, die auf diese Weise nicht sättigt werden kann und die vor allen vom Kunden sichtbaren Auswirkungen warnt. Implementieren Sie den automatischen, periodischen Austausch von lang laufenden Gateway-Instanzen nach einem festen Zeitplan, so dass keine Instanz die Art der altersbedingten Verschlechterung akkumulieren kann, die bei diesem Vorfall beobachtet wird. | | Migration von Gateway-Instanzen zu einer netzwerkoptimierten Infrastruktur mit wesentlich mehr dedizierter Netzwerkkapazität, die sich besser für nachhaltigen Hochdurchsatz-Verkehr eignet. | | Verbessern Sie die Auslastung des bestehenden Überwachungspuffers, während der längerfristige Ersatz eingeführt wird. | Verbessern Sie die Alarmierung speziell auf die Latenz des Gateway-Gesundheitschecks, um frühe Anzeichen einer Verschlechterung zu erkennen, bevor sie vom Kunden sichtbar wird. |

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 22. September 2026 um 14:00 UTCidentified

   Das Problem wurde identifiziert und ein Fix wird implementiert.

2. 22. September 2026 um 14:08 UTCmonitoring

   Ein Fix wurde implementiert und wir überwachen die Ergebnisse.

3. 22. September 2026 um 14:20 UTCresolved

   Dieser Vorfall wurde behoben.

4. 2. Oktober 2026 um 22:10 UTCpostmortem

   Wie die vorherige Ursache.

Automatisch aus der offiziellen Störungsmeldung übersetzt.

1. 21. September 2026 um 16:39 UTCinvestigating

   Wir untersuchen derzeit dieses Problem.

2. 21. September 2026 um 17:12 UTCidentified

   Das Problem wurde identifiziert und ein Fix wird implementiert.

3. 21. September 2026 um 18:27 UTCmonitoring

   Ein Fix wurde implementiert und wir überwachen die Ergebnisse.

4. 21. September 2026 um 18:33 UTCresolved

   Dieser Vorfall wurde behoben.

5. 29. September 2026 um 22:39 UTCpostmortem

   ## Zusammenfassung Am 21. September 2026 erlebten die Kunden in Prod 2 etwa drei Stunden lang degradierte und dann weitgehend nicht verfügbare Deployment-Dashboards. Das Problem wurde durch eine Reihe von Analyseabfragen hinter diesen Dashboards verursacht, die weit mehr Daten lesen, als sie benötigen, was die Kapazität der Datenbank erschöpft, die sie bedient. Ein rollender Neustart des betroffenen Dienstes stellte die Dashboards vollständig wieder her, und die Plattform war seitdem stabil. ## Customer Impact Dashboard-Seiten werden langsam geladen oder zeitlich zwischen 14:48 und 18:11 UTC verschoben. Die Pipelineausführungs- und Bereitstellungsaufzeichnung lief auf separater Infrastruktur und wurde weiterhin normal betrieben. Es gab keinen Datenverlust oder Korruption. ## Wurzelursache Den Dashboard-Abfragen fehlte ein Zeitbereichsfilter in der Spalte, mit dem die größte Tabelle in wöchentliche Segmente aufgeteilt wurde, so dass jede Abfrage alle historischen Daten statt nur den angeforderten Zeitraum gelesen hat. Die Korrektheit wurde nie beeinträchtigt - die Dashboards lieferten die richtigen Ergebnisse; nur die Datenmenge, die gelesen wurde, um sie zu produzieren, war übermäßig. Als das Datenvolumen wuchs, überstiegen die Kosten für diese Lesevorgänge das, was die Datenbank bedienen konnte, und Wiederholungen der fehlgeschlagenen Abfragen fügten weitere Last hinzu, so dass die Bedingung nicht gelöscht wurde, bis der Dienst neu gestartet wurde. Mitigation * Führte einen rollenden Neustart des betroffenen Dienstes durch, der den Wiederholungszyklus stoppte und es der Datenbank ermöglichte, ihre hervorragende Arbeit abzuschließen * Bestätigte Latenz und Datenbankverbindungsnutzung wieder auf normales Niveau ## Nächste Schritte Um eine Wiederholung zu verhindern, wird Harness: * Fügen Sie den fehlenden Zeitbereichsfilter zu den betroffenen Dashboard-Abfragen hinzu, so dass jeder nur den angeforderten Zeitraum liest * Ersetzen Sie sofortige Retries durch begrenzte, Backing-Off-Retries * Verbesserung der Erkennung durch Hinzufügen von Warnungen zur Nutzung der Datenbankverbindung und zu den Ausführungskosten pro Abfrage

Automatisch aus der offiziellen Störungsmeldung übersetzt.