Prod2 był niedostępny okresowo
Pending
Dotknięte komponenty
Platform
- investigating
Obecnie badamy tę kwestię.
- resolved
Ten incydent został rozwiązany.
Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.
88 Harness incidents · marzec 2026 — official updates, affected components, duration and resolution details.
Obecnie badamy tę kwestię.
Ten incydent został rozwiązany.
Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.
Egzekucja rurociągu utknęła w Prod1. Badamy tę sprawę.
Wprowadzono rozwiązanie i monitorujemy wyniki.
Ten incydent został rozwiązany.
Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.
Obecnie badamy tę kwestię.
Problem został zidentyfikowany i jest w trakcie wdrażania.
Wprowadzono rozwiązanie i monitorujemy wyniki.
Ten incydent został rozwiązany.
Podsumowanie W okresie od 27 sierpnia do 28 sierpnia 2026 r. klienci doświadczyli problemu, w którym niektóre rurociągi, rozmieszczenie i związane z nimi zasoby pojawiły się, jak nie znaleziono w UV i API Harness, mimo że podstawowe dane pozostały nienaruszone. Uzasadnienie Kwestia ta miała miejsce podczas planowanej aktualizacji infrastruktury wewnętrznej, która miała wpływ na komunikację między wewnętrznymi usługami platformy. W rezultacie wnioski, które zależały od rachunku, organizacji i restrukturyzacji i uporządkowanej likwidacji zakresu projektu, nie były w stanie z powodzeniem wypełnić, co doprowadziło do nieprawidłowego braku odpowiedzi zwracanych klientom dla istniejących podmiotów. Uzasadnienie Maszynownia zidentyfikowała problem, cofnęła zmianę i przywróciła normalną obsługę. Podczas incydentu nie utracono ani nie usunięto danych klientów. Uzasadnienie # # Root Cause # Kwestia ta została spowodowana błędem konfiguracji wprowadzonym podczas planowanej aktualizacji routingu wewnętrznego w Produkcji. Wewnętrzna usługa platformowa odpowiedzialna za rozwiązywanie problemów związanych z rachunkiem, organizacją i projektem nie była w stanie zweryfikować wniosków z innych usług Harness po zastosowaniu zmiany. Ponieważ ten etap walidacji jest wymagany, zanim wiele podmiotów przeczyta i działania związane z inwestycjami mogą być kontynuowane, nieudane wnioski pojawiły się klientom, ponieważ nie znaleziono błędów w odniesieniu do zasobów, które normalnie istniały. Kwestia ta ograniczała się do środowiska produkcyjnego, którego dotyczy problem, i została rozwiązana poprzez odwrócenie zmiany i przywrócenie poprzedniej ścieżki komunikacji usługowej. Uzasadnienie # # Impact * Niektórzy klienci widzieli istniejące rurociągi, rozmieszczenie, i powiązane podmioty pojawiają się jak nie znaleziono w UI i API. * Niektóre operacje związane z wykonywaniem zleceń, w tym progresja wykonywania zleceń, uruchamiane webhook- startuje, planowana ocena aktywacji oraz lista podmiotów zostały czasowo zakłócone. * Problem miał wpływ na dostępność i widoczność istniejących podmiotów, ale nie usunął danych ani nie zmienił konfiguracji klienta. * Brak nieautoryzowanego dostępu i brak utraty danych klienta. # # Regeneracja * * * Natychmiastowe: * * Odwrócił aktualizację konfiguracji infrastruktury i przywrócił wcześniej działającą ścieżkę komunikacji usług. * * * Walidacja odzysku: * * Zweryfikowano, że po wycofaniu API funkcjonowały normalnie. * * * Stała: * * Poprawiono obsługę konfiguracji związaną z aktualizacją, tak aby podobne problemy nie kolidowały z uwierzytelnianiem usług w przyszłości. # # Pozycje akcji Aby zapobiec powtórzeniu się takich problemów, Harness 1. Poprawa walidacji konfiguracji poprzez wzmocnienie testów przed wdrożeniem w celu weryfikacji komunikacji wewnętrznej usługi przed zmianą ruchu produkcyjnego. 2. Wzmocnienie monitorowania i ostrzegania o wewnętrznych błędów uwierzytelniania, tak aby problemy można było wykryć wcześniej. 3. Poprawa obsługi błędów, tak aby awarie zależności są mniej prawdopodobne, aby pokazać klientom jako zasoby nie znaleziono błędów.
Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.
Obecnie badamy problem zgłoszony w rurociągach IACM w klastrach Prod-1, Prod-2, Prod- 4 i EU1.
Nadal badamy tę kwestię.
Odwróciliśmy zmianę, która spowodowała tę kwestię we wszystkich klastrach.
Ten incydent został rozwiązany.
Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.
Obecnie badamy tę kwestię.
Obecnie badamy raporty, że interfejs użytkownika Feature Management & Experimentation (FME) nie jest wczytywany. Klienci próbujący uzyskać dostęp do konsoli FME mogą napotkać błędy lub niereagujące strony. Uważa się, że ocena parametrów i ruch SDK nie zostały naruszone. Wkrótce nastąpi kolejna aktualizacja.
Wprowadzono rozwiązanie i monitorujemy wyniki.
Ten incydent został rozwiązany.
Podsumowanie * Począwszy od * * 23: 42 UTC * * 23 sierpnia 2026 roku, kilku klientów FME zgłosiło awarię podczas ładowania interfejsu FME. * FME UI Artefakty serwowane z CDN wygasły z powodu polityki retencji, powodując FME UI nie załadować. * Każdy wniosek o flagę zmienia się poprzez API, zmiana dostawy, a rurociąg danych nadal działa bez przerwy. # # Root Cause # * UI FME serwowane jest z CDN. Artefakty UI zostały eksmitowane z powodu polityki retencji, powodując, że UI nie załaduje się dla wszystkich użytkowników. # # Impact * UI FME nie był w stanie załadować dla wszystkich użytkowników we wszystkich środowiskach produkcyjnych. - Co nie miało wpływu? * Funkcjonalność SDK i ocena flagi runtime * Admin API calls * Dane konfiguracji flagi klienta * Brak utraty danych # # Regeneracja * UI FME został przywrócony w CDN poprzez rozmieszczenie * Odzyskiwanie potwierdzone we wszystkich środowiskach produkcyjnych przed zamknięciem incydentu. # # Pozycje akcji * Poprawa polityki retencji aktywów tak, że obecnie aktywna wersja nigdy nie podlega eksmisji.
Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.
Obecnie badamy tę kwestię.
Powolność może spowodować którykolwiek z poniższych objawów: - Rurociągi nie zaczynają - Opóźnienia w wykonaniu - Rurociągi są anulowane z powodu timeout
Nasz dostawca chmur stoi w obliczu aktywnego incydentu, a my go śledzimy.
Nadal badamy tę kwestię.
Nasz dostawca chmur potwierdził trwający incydent wpływający na wiele regionów. W rezultacie rurociągi uprzęży nie doznały niepowodzeń, chociaż niektórzy użytkownicy mogą nadal odczuwać powolność. Dokładnie monitorujemy sytuację i dostarczymy aktualizacje w miarę dostępności większej ilości informacji.
Obserwujemy ulepszone latencje na całym pokładzie po fix wdrożony przez naszego operatora chmur. Nadal uważnie monitorujemy sytuację i przedstawimy dalsze aktualizacje, o ile są one uzasadnione. Zwróciliśmy uwagę na kilka zaciętych egzekucji dla informatorów, które badamy
Ten incydent został rozwiązany.
# Streszczenie W dniu 20 sierpnia 2026 r., począwszy od ok. 15: 00 UTC, platforma Harness odnotowała powszechną degradację wydajności we wszystkich środowiskach produkcyjnych. Egzekucje rur, które zwykle kończą się w około dwie minuty, trwały od siedmiu do dziesięciu minut. Wszystkie te elementy miały wpływ na ciągłą dostawę, ciągłą integrację, orkiestrację rurociągów oraz zarządzanie funkcjami i eksperymenty. Platforma Google Cloud Platform doświadczyła incydentu związanego z wieloma produktami w regionie us- west1, który miał wpływ na Bigtable, Compute Engine, Google Kubernetes Engine oraz persistent- disk I / O. Infrastruktura produkcyjna Harness działa na trwałych dyskach w tym regionie. Degradacja zwiększyła opóźnienie działania bazy danych z około 2 ms do ponad 10 ms w 95. percentylu, co z kolei spowodowało opóźnienie przetwarzania wiadomości w kolejce i rozprzestrzeniło się na każdą usługę, która zależy od terminowego dostępu do bazy danych. Uzasadnienie # Impact To była degradacja, a nie przestoje. Rurociągi nadal wykonywały i z powodzeniem kończyły pracę; były powolne, a nie zawodzące. Brak danych nie został utracony, a w wyniku tego incydentu nie odrzucono pracy klienta. * * * Root cause * * Infrastruktura produkcyjna uprzęży w dotkniętych środowiskach działa na trwałych dyskach Google Cloud Platform w regionie us- west1. Po degradacji warstwy magazynowej efekt rozprzestrzenił się przez platformę w przewidywalnym łańcuchu: * * Persistent- disk I / O degradation in us-west1. * * Google Cloud Platform doświadczyło incydentu związanego z wieloma produktami, który miał wpływ na Bigtable, Compute Engine, Google Kubernetes Engine oraz persistent- disk performance. To była awaria infrastruktury w środowisku dostawcy, poza kontrolą Harnessa. * * * Działania zapobiegawcze * * Chociaż Harness nie może zapobiec awarii infrastruktury dostawcy chmur. Poniższe działania mają na celu wykrycie jednego szybciej i lepsze jego umiejscowienie. 124; * * Działanie * * 124; - PROJEKT 124; Kontynuacja rutynowych wstępnych testów ukierunkowanych awarii bazy danych w regionie krzyżowym, jak to miało miejsce podczas tego incydentu, w celu utrzymania gotowości do awarii, a nie zakładając, że 124; 124; ocena niepowodzenia wieloregionów na pełnym stosie w odniesieniu do przyszłych scenariuszy, w których opóźnienie w transregionie byłoby niedopuszczalne 124
Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.
Obecnie badamy tę kwestię.
Problem został zidentyfikowany i jest w trakcie wdrażania.
Wprowadzono rozwiązanie i monitorujemy wyniki.
Ten incydent został rozwiązany.
Podsumowanie 20 sierpnia 2026, między 10: 24 a 14: 55 UTC, podzbiór FME pisze nieudany. Wpisy wykonane z interfejsu FME i teksty wykonane z żetonów dostępu Harness\ (PAT i SAT\) nie zostały naruszone. Ocena bandery w czasie biegu nadal działała normalnie. Kwestia ta została złagodzona przez powrót do niedawnej zmiany uwierzytelniania w ramach wspólnej usługi zarządzania, a pisma, których dotyczyła, powróciły do normy o 14: 55 UTC. Status: [https: / / status.harness.io / invents / rhthgm7d5dkz] (https: / / status.harness.io / invents / rhthgm7d5dkz) # # Root Cause Zmiana sposobu, w jaki usługa wspólnego zarządzania uwierzytelniała połączenia przychodzące, doprowadziła do odrzucenia niektórych dokumentów FME. Piszą one używane referencje usługowe, których służby zarządzające nie mogły już zweryfikować po zmianie. FME przedstawia klientowi usterkę zarządzania jako HTTP 499, taki sam status używany, gdy polityka zarządzania celowo zaprzecza zmianie. Ponieważ 499 jest poprawną, oczekiwaną reakcją na tej zaprzeczającej ścieżce, niepowodzenia nie wyglądały jak przestoje w naszych alarmach, a incydent został zidentyfikowany na podstawie raportów klientów, a nie wewnętrznej detekcji. # # Impact * Podzbiór FME pisze nie powiodło się podczas okna, przede wszystkim te wykonane za pomocą dotychczasowych kluczy Split API lub zmiany harmonogramu żądania. * Wpisy wykonane z UI FME nie zostały naruszone. * Wpisy za pomocą żetonów dostępu Harness\ (PAT i SAT\) nie miały wpływu. * Ocena flagi Runtime nadal normalnie. * Brak utraty danych. Nieudane pisma nie miały zastosowania. Uzasadnienie # # Remediation Odwrócił zmianę uwierzytelniania rządowego. Afected writs powraca do normy natychmiast. # # # Action Elements Aby zapobiec powtórzeniu się takich kwestii, * Harness zwróci odrębny błąd\ (nie 499\), gdy zapis zawiedzie, ponieważ zarządzanie nie może być ocenione, więc nie jest mylony z celowym zaprzeczeniem polityki. * Dodawanie ostrzeżeń dotyczących samego wezwania do oceny zarządzania, zamiast polegania na kodzie statusu klienta. * Rozszerzenie wsparcia uwierzytelniania dla ocen polityki. * Rozszerz automatyczne pokrycie dodatkowych scenariuszy zapisu.
Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.
Obecnie badamy tę kwestię.
Nadal badamy tę kwestię.
Problem został zidentyfikowany i jest w trakcie wdrażania.
Wprowadzono rozwiązanie i monitorujemy wyniki.
Nadal monitorujemy wszelkie dalsze problemy.
Ten incydent został rozwiązany.
/ Podsumowanie W dniu 19 sierpnia 2026 r., między 12: 35 a 17: 29 UTC, służby bezpieczeństwa aplikacji Harness doświadczyły znacznego zakłócenia zarówno konsoli użytkownika, jak i gazociągu danych w regionie SaaS Production i US1. Uzasadnienie * * Root Cause * * Wewnętrzna usługa konfiguracji, która dostarcza ustawienia runtime prawie każdemu innemu składnikowi, została przeciążona i weszła w powtarzający się cykl restartu. Ponieważ tak wiele usług od niego zależy, efekty były szerokie: strony konsoli, takie jak polityka ochrony, widoki pozycji, dzienniki aktywności, inwentaryzacja API i polityka niestandardowa nie udało się załadować lub wyłączyć, a dalsze przetwarzanie zablokowane podczas oczekiwania na konfigurację nie mógł uzyskać. * * * Uderzenie klienta * * 124; * * Wymiar * * 124; * * Szczegóły * * 124; {C: $999966} {f: PROJECT 124; Console\ (UI\) impact PROJECT 124; Wiele stron nie udało się wczytać lub wyłączyć, w tym polityki ochrony, strony event postawy i widok postawy wewnątrz desek rozdzielczych i stron wglądu, ksery dzienników aktywności, ekrany inwentaryzacji API, polityka niestandardowa, i sensytywny-widoki danych i widżety. VIId; 124; Oddziaływanie na spożycie 124; Przetwarzanie telemetrii bezpieczeństwa uległo poważnemu pogorszeniu i w niektórych przypadkach całkowicie się zatrzymało. Opóźnienie wśród konsumentów wzrosło na różnych etapach normalizacji, grupowania, wykrywania anomalii, wytwarzania i powiązanych etapów przetwarzania. VIId; 124; Utrata danych 124; Podzbiór telemetrii spożywany podczas zakłóceń został trwale zrzucony. VIId; Uzasadnienie * * Litigation * * Kilka pośrednich złagodzeń dodatkowych procesora i pamięci, zrelaksowane progi kontroli zdrowia, ponowne uruchomienie bazy danych, a większa pula połączeń poprawił problem. Wyłączenie nowej funkcji w obu dotkniętych regionach przywrócona przepustowość gwałtownie i trwale. Incydent został rozwiązany o 17: 29 UTC. Uzasadnienie * * * Działania zapobiegawcze * * Następujące działania są podejmowane i śledzone wewnętrznie do zakończenia. Funkcja, która wywołała ten incydent pozostaje wyłączona i nie zostanie ponownie włączona do czasu zakończenia i zatwierdzenia poniższych prac. 124; * * Działanie * * 124; - 124; 124; PROCES124; Optymizuj kod poprzez parametry tuningowe, takie jak eksmisja i retencja pamięci podręcznej, oceniaj paginację opartą na kursorii w celu odzyskania masowych reguł, ponieważ licznik zasad rośnie 124; DODATKOWE 124; Dodanie specjalnie zbudowanego indeksu bazy danych dla wzorca dostępu do usług 124; Regenerate gape recovery semantics so consumers replay safe after position- marker loss instead of skipping backlog DODATKOWE 124; Mandat do wprowadzania etapowego nadwyżek konfiguracji, które zmieniają wzorce żądania niższego szczebla: klaster niskiego wolumenu, następnie środkowy wolumen, następnie wysoki wolumen 124; DODATKOWE 124; Dodawanie przeciwciśnienia i ochrony przeciwnej do usługi konfiguracyjnej: zerwanie obwodu, ograniczone kolejki i izolacja timeout 124; PROJEKT 124; Zwiększenie obserwowalności poprzez instrumentację bardziej szczegółowych pomiarów 124
Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.
We are currently investigating a Harness component that is experiencing issues. We are working to identify the cause and restore normal operations as soon as possible.
We are continuing to investigate this issue.
The issue has been identified and a fix is being implemented.
This incident has been resolved.
## Summary Customers on Prod1, Prod2, and Prod3 \(US\) clusters experienced failures when loading SEI 2.0 dashboards on August 6, 2026, from 7:22 AM PDT to 9:03 AM PDT. Customers calling the SEI 2.0 API also experienced similar failures. No customer data was lost, and ingestion of all integration data continued to work uninterrupted. SEI customers using 1.0 were not impacted. ## Root Cause The incident was caused by resource exhaustion on the nodes serving queries. This resource degradation developed in a pattern that did not cross our existing alerting thresholds early enough to provide sufficient warning or allow mitigation before customer impact occurred. ## Impact Customers on Prod1, Prod2, and Prod3 \(US\) clusters were unable to load SEI 2.0 dashboards during the incident window. **Duration:** August 6, 2026, 7:22 AM PDT – 9:03 AM PDT \(~1 hour 41 minutes\) ### What was not impacted? * Data ingestion and processing * SEI 1.0 customers * Integrations and metadata flows No customer data was lost. ## Remediation Upon identifying the root cause, our team took immediate corrective action by adding capacity to restore the affected systems. Services were fully recovered, and all dashboards resumed normal operation at 9:03 AM PDT. ## Action Items To prevent from such issues happening again, Harness is/has Proactively added capacity updates have been applied to prevent this issue from recurring #### Enhanced Monitoring and Alerting Additional monitoring and alerting have been put in place to detect anomalies early, focused on a leading indicator, which in this case was thread pool exhaustion, before they can impact dashboard availability and data rendering. #### System Patch in Progress We are working with our vendor to apply a patch to remediate this and similar issues completely.
Monitorujemy zablokowane rurociągi w prod2. Nowe egzekucje mijają, ponieważ stale monitorujemy usługi.
Monitorujemy zablokowane rurociągi w prod2. Dla klientów, którzy nadal widzą zablokowane rurociągi, prosimy o przerwanie i ponowne uruchomienie.
Ten incydent został rozwiązany.
/ Podsumowanie W dniu 6 sierpnia 2026\ (rano PDT\) niektórzy klienci prowadzący rurociągi w środowisku produkcyjnym Prod2 zaobserwowali egzekucje rurociągów, które przestały czynić postępy - etapy, które nie postępowały i nie produkowały żadnych dalszych aktualizacji produkcji lub statusu. Kwestia ta została zgłoszona przez zainteresowanych klientów. Inżynierowie Harnessa zidentyfikowali przyczynę, złagodzili uderzenie, a egzekucje rurociągów wróciły do normalnego funkcjonowania. Kwestia ta została spowodowana przez autoreferencyjną ekspresję rurociągu. Hak internetowy Git uruchomił rurociąg, który odnosił się do zawartości ładunku użytecznego haka, a sam ładunek zawiera dalsze kopie tego samego wyrażenia. Każda runda rozdzielczości wytworzyła więc więcej wyrażeń do rozwiązania, co podwaja ilość pracy za każdym razem. Wyczerpało to zasoby instancji usługowej przetwarzającej tę egzekucję, a inne egzekucje przypisane tej samej instancji nie były w stanie osiągnąć postępu w tym stanie. * * Impact * * W oknie zdarzenia\ (około 6: 11 do 11: 23 AM PDT w dniu 6 sierpnia 2026\): * Niektóre egzekucje gazociągów klientów na Prod2 zablokowały wykonanie pośrednie i nie poczyniły dalszych postępów. * Afected egzekucje nie produkować nowy krok wyjście lub status aktualizacje, i musiał być przerwany i ponownie uruchomić po łagodzeniu. * Zachowanie ograniczało się do egzekucji przetwarzanych przez poszkodowaną instancję usługową - rurociągi obsługiwane przez inne instancje nadal wykonywały się normalnie. Nie było utraty danych. Definicje pipeline, historia wykonania i stan przechowywania nie zostały naruszone. Większość rurociągów na Prod2 nadal z powodzeniem wykonywała cały incydent; głównym skutkiem było to, że niektóre egzekucje w locie nie mogły być zakończone i musiały zostać ponownie uruchomione po złagodzeniu problemu. * * * Root Cause * * Rury uprzęży obsługują wyrażenia, które są rozwiązywane w czasie pracy - na przykład, wyrażenie, które umieszcza zawartość haka sieciowego Git, który uruchomił rurociąg. W tym przypadku wiadomość Git commit zawierała dosłowny tekst samego wyrażenia ładunku, dwukrotnie, a rurociąg odnosił się do tego samego wyrażenia ładunku. Ponieważ wiadomość commit jest częścią ładunku użytecznego haka webhook, rozdzielczość wyrażenia włożyła cały ładunek - w tym dwie dosłowne kopie wyrażenia w wiadomości commit. Te nowo wstawione kopie były następnie traktowane jako wyrażenia do rozwiązania, a każde podanie wstawiło dwie kolejne pełne kopie ładunku. Rozmiar przetwarzanej wartości oraz praca potrzebna do jej przetworzenia podwoiły się więc na każdym przejściu i rosły wykładniczo, a nie zbieżnie. Uprząż ma na celu zatrzymanie dokładnie tego: rozdzielczość ekspresji jest ograniczona przez maksymalną głębokość gniazda, po której rozdzielczość zatrzymuje się, a rurociąg zawiedzie z wyraźnym błędem. Wada tego zabezpieczenia oznaczała, że limit nie został zastosowany w tym konkretnym przypadku samoreferencyjnym, więc rozdzielczość była nadal niekontrolowana. Rozdzielczość ekspresji przebiega w linii na wątkach, które rozpoczynają etapy rurociągu. Ponieważ każde podanie zużywało stopniowo więcej pamięci i CPU bez zakończenia, instancja usługowa wykonująca pracę przestała czynić postępy, a każde wykonanie przypisane do tego przypadku zatrzymało - co zgłosili klienci. * * * Litigation * * Uprząż ukończył następujące natychmiastowe etapy łagodzące: * Zidentyfikowano rurociąg i wzór ekspresji odpowiedzialny za rozdzielczość ucieczki. * Zatrzymał dotknięty instancji usługi tak, że nie będzie kontynuować pracę. Pozostałe zdrowe przypadki przechwyciły i przerobione egzekucje w kolejce normalnie. * Potwierdzono, że egzekucje rurociągów wróciły do normy i zamknęły incydent. Działania te przywróciły normalne zachowanie realizacji rurociągu i rozwiązały skutki dla klienta. * * * Action Elements * * W celu zmniejszenia ryzyka nawrotu i poprawy wykrywania następujące działania znajdują się na różnych etapach wdrażania: * Popraw defekt w głębokości wyrażenia i zabezpieczenia wykrywania luk tak, że autoreferencyjne wyrażenia są złowione i zawiedź szybko z wyraźnym błędem zamiast spożywania zasobów bez wiązania. * Zapobiec usuwaniu wyrażeń obciążenia z zawartości ładunku wyzwalającego, całkowicie usuwając ścieżkę samoreferencyjną. * Zaostrzyć maksymalną głębokość gniazda ekspresji i ocenić wyraźne wykrywanie pętli oprócz istniejącego limitu głębokości. * Wzmocnienie zautomatyzowanych testów w środowiskach przedprodukcyjnych, które odtwarzają autoreferencyjne wzory ekspresji i weryfikują, że zabezpieczenie wykrywa i zatrzymuje je. * Dodaj monitoring dla tego wzorca w wykonaniu rurociągu tak, że jest wykrywane proaktywnie.
Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.
We are currently investigating this issue.
We are continuing to investigate this issue.
We have identified the issue and started to implement the fix , prod2 is restored.
We are continuously rolling out fixes to all Clusters, Prod EU1 has been resolved.
We are continuously rolling out fixes to all Clusters, Prod3 has been resolved.
This incident has been resolved.
# Executive Summary On August 4, 2026, between approximately 3:36 PM and 9:00 PM IST, customers using Infrastructure as Code Management \(IaCM\) on Prod0 and Prod1 were unable to access the Variable Sets settings page. The page rendered blank with no error message, and customers with Variable Sets attached to their workspaces could not view or manage them for the duration of the incident. Prod2, Prod3, and EU1 were not affected. Separately, during the same window, a scheduled maintenance action caused the IaCM settings tab to temporarily disappear across all environments. This was identified and reversed within the incident bridge call before significant customer impact occurred. We deployed a hotfix that restored full access to the Variable Sets page on Prod0 and Prod1 the same evening, and we are implementing permanent safeguards described below to prevent this class of issue from recurring. # Impact * Customers with the Variable Sets feature enabled on Prod0 and Prod1 were unable to view or manage Variable Sets for approximately 5–6 hours. * No data was lost or corrupted, this was a UI routing failure only; underlying Variable Sets data and configuration were not affected. * Prod2, Prod3, and EU1 were not affected by this issue. * A secondary issue, a scheduled feature flag operation caused the IaCM settings tab to temporarily disappear across all environments during the incident bridge call. This was identified and reversed within minutes. External customer exposure for this secondary issue is still being confirmed. # Root Cause A platform routing change released on July 18, 2026 updated how IaCM settings pages are resolved in the user interface. As part of that change, any settings page that had not been explicitly re-registered in the new routing structure became unreachable. The Variable Sets page had not been re-registered under the new routing structure, making it inaccessible in the environments where the routing change had been deployed — Prod0 and Prod1. Because the failure occurred at the routing layer rather than within the page itself, the page rendered blank with no visible error rather than showing a clear failure message. # Remediation ## Immediate We deployed a hotfix that re-registered the Variable Sets page in the updated routing structure, restoring access for all affected customers on Prod0 and Prod1. ## Permanent We are adding automated end-to-end tests that navigate to settings pages with relevant feature flags enabled, configured as a required gate in our release pipeline. We are also documenting and enforcing the routing constraint through static analysis so that settings pages are never inadvertently left out of the routing structure during future platform changes. # Action Items To prevent such issues from happening again, 1. Enhance automated tests, that navigate to settings pages with relevant feature flags enabled, configured as a blocking gate in the release pipeline, so this class of regression is caught before it reaches production. 2. Establish an explicit checklist step for future platform-wide architectural changes that verifies all existing settings pages remain accessible in the updated routing structure before the change is promoted to production.
Obecnie badamy tę kwestię.
Wprowadzono rozwiązanie i monitorujemy wyniki.
Ten incydent został rozwiązany.
Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.
Obecnie badamy tę kwestię.
Problem został zidentyfikowany i jest w trakcie wdrażania.
Wprowadzono rozwiązanie i monitorujemy wyniki.
Ten incydent został rozwiązany.
/ Podsumowanie W dniach od 25 lipca do 4 sierpnia 2026 r. tablice rozdzielcze do wykonania rurociągu oraz strony przeglądowe w klastrach Harness Prod 2 i Prod 3 zawierały dane, które znajdowały się pomiędzy czasem rzeczywistym. Samo rurociągi nadal budowały, wdrażały i wykonywały normalnie przez cały okres; kwestia ta ograniczała się do tego, jak szybko do bazy danych, która służy do raportowania i przeglądania kart rozdzielczych, zostały skopiowane rekordy wykonania. Uzasadnienie * * Nie utracono danych klientów. * * Każdy wpływający rekord pozostał przechowywany w sposób trwały i był odtwarzany ponownie do bazy danych analitycznych po usunięciu podstawowego ograniczenia. W dniu 1 sierpnia 2026 r. * * * Root cause * * Harness utrzymuje komponent change-data- capture, który stale powiela rekordy wykonania rurociągu z głównego operacyjnego datastore do oddzielnego time-series datastore zoptymalizowane dla desek rozdzielczych i zapytań sprawozdawczych. Deski rozdzielcze odczytywane są wyłącznie z danych analitycznych. Kiedy replikacja jest w tyle, deski rozdzielcze tworzą dokładny, ale starszy pogląd na świat, podczas gdy sama egzekucja jest nienaruszona. Było to spowodowane gwałtownym, trwałym wzrostem wolumenu zapisu bazy danych z innego modułu platformy Harness, dzielącego tę samą ścieżkę replikacji, przekraczającą pułap przepustowości starszej, jednoosobowej wersji tego komponentu, która nadal działa w Prod 2 i Prod 3. Zaległość powstała i wzrosła. Uzasadnienie Uzasadnienie * * * Działania zapobiegawcze * * Upór zakończył lub zobowiązał się do podjęcia następujących działań w celu zapobieżenia takim problemom. 124; * * Działanie * * 124; - DODATKOWE 124; Dostroić ostrzeżenie o opóźnieniu replikacji, tak aby każde opóźnienie przekraczające określony próg było zgłaszane do 124; DODATKOWE 124; Dodanie panelu opóźnienia replikacji do standardowej platformy monitorującej, tak aby zdrowie rurociągu było widoczne na wywołaniu domyślnie 124; PROTOKÓŁ 124; Zredukować wzmacnianie zapisu z modułów współlokatorskich poprzez ograniczenie częstotliwości modułów lub filtrowanie jednostki na strumieniu replikacji
Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.
Obecnie badamy tę kwestię.
Problem został zidentyfikowany i jest w trakcie wdrażania.
Wprowadzono rozwiązanie i monitorujemy wyniki.
Ten incydent został rozwiązany.
# **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.
Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.
Podsumowanie Nieustannie stajemy w obliczu problemów związanych z połączeniem sieci z naszą Build VM, która nie jest w stanie połączyć się z zewnętrznymi zasobami. Obecnie badamy tę sprawę.
Wprowadzono rozwiązanie i monitorujemy wyniki.
Nadal monitorujemy wszelkie dalsze problemy.
Ten incydent został rozwiązany.
## Summary Starting on August 4, 2026, CI runners in the us-west1 and us-central1 regions intermittently experienced connection timeouts of approximately 134 seconds when reaching external services such as GitHub and Bitbucket over outbound network gateways. ## Impact * CI runners in the affected regions intermittently experienced connection timeouts of approximately 134 seconds when reaching external services \(e.g., GitHub, Bitbucket\) over our outbound network gateways. * The issue was intermittent rather than constant — connections succeeded under normal load, and failures clustered during periods of high outbound traffic volume. * No data was lost or corrupted. This was a network-connectivity and capacity issue, not a data-integrity issue. * us-west1 and us-central1 were the affected regions; other regions were not impacted by this issue. ## Root Cause Our load balancer distributes outbound traffic across multiple NAT gateways using a hashing method based on connection details \(source/destination address and port\). For any single connection, these details stay constant for that connection's lifetime. We had a sustainted traffic surge for a few seconds which congested the gateways ## Action Items To prevent such issues from happening again Harness will, Increase outbound connection capacity on our NAT gateways by provisioning additional external network interfaces, giving each gateway a substantially larger pool of connections it can serve concurrently..
Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.
Obecnie badamy tę kwestię.
Wprowadzono rozwiązanie i monitorujemy wyniki.
Ten incydent został rozwiązany.
Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.
Obecnie badamy tę kwestię.
Nadal badamy tę kwestię.
Problem został zidentyfikowany i jest w trakcie wdrażania.
Kontynuujemy prace nad rozwiązaniem tego problemu.
Wprowadzono rozwiązanie i monitorujemy wyniki.
Nadal monitorujemy wszelkie dalsze problemy.
Ten incydent został rozwiązany.
# 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._
Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.
Badamy problem wpływający na tablice rozdzielcze AIDI. Podczas dostępu do desek rozdzielczych użytkownicy mogą doświadczać zwiększonego czasu obciążenia lub przerywanych awarii. Nasz zespół aktywnie pracuje nad zidentyfikowaniem przyczyny i przywróceniem normalnej wydajności. Dostarczymy aktualizacje w miarę dostępności większej ilości informacji.
Problem został zidentyfikowany i jest w trakcie wdrażania.
Wprowadzono rozwiązanie i monitorujemy wyniki.
Ten incydent został rozwiązany.
Podsumowanie W dniu 22 lipca 2026 r. klienci klastrów Prod1, Prod2 i Prod3 doświadczyli przerywanych awarii obciążenia widżetem i zwiększonego czasu ładowania przy dostępie do tablic rozdzielczych AIDI 2.0. Nie wszystkie widżety zostały dotknięte jednocześnie problem przejawia się jako sporadyczne niepowodzenia, a nie pełne zaprzestanie. Nie utracono danych klientów. SEI 1.0 klientów nie miały wpływu. # # Root Cause # Z czasem, rutynowy proces konserwacji bazy danych nie działał na niektórych tabelach w naszej bazie danych analitycznych, powodując, że tabele te gromadzą dużą ilość wewnętrznych metadanych używanych do śledzenia usuniętych rekordów. Kiedy baza danych zaplanowała zapytania dotyczące tych tabel, załadowała wszystkie zgromadzone metadane do pamięci, powodując wielokrotne zwiększenie wykorzystania pamięci na dotkniętych węzłach. Te powtarzające się kolce uruchomiły automatyczny mechanizm bezpieczeństwa, który ponownie uruchamia węzeł, gdy wykrywa nadmierne ciśnienie pamięci, a dotknięte węzły zaczęły ponownie uruchamiać się w pętli w wyniku. Spowodowało to przerywane, zdegradowane działanie zapytania na tablicach rozdzielczych AIDI 2.0 na czas trwania incydentu. # # Impact Klienci z klastrów Prod1, Prod2 i Prod3 mogli doświadczyć niesprawności obciążenia widżetowego lub zwiększonego czasu obciążenia na tablicach rozdzielczych AIDI 2.0. * * Czas trwania: * * 22 lipca 2026, 07: 58 PDT - 16: 16 PDT\ (~ 8 godzin 18 minut\), z przerwami widget awarii; system został ponownie uruchomiony i pod aktywną kontrolą od 08: 25 PDT dalej. - Co nie miało wpływu? * Spożycie i przetwarzanie danych * SEI 1.0 klienci * Integracje i przepływy metadanych Nie utracono danych klientów. # # Regeneracja Po zidentyfikowaniu problemu, dotknięte węzły bazy danych zostały ponownie uruchomione o godzinie 08: 25 PDT, który przywrócił początkową stabilność. Kontynuowaliśmy ścisłą obserwację systemu, a gdy obserwowano przerywaną degradację, zastosowaliśmy kilka dodatkowych poprawek: * Skorygowane ustawienia konfiguracji bazy danych, aby ograniczyć ilość pamięci używanej do przetwarzania zgromadzonych metadanych i dostrojone ustawienia planowania query- w celu zmniejszenia ciśnienia pamięci. * Ran sprzątanie miejsc pracy w celu zmniejszenia zaległości nagromadzonych metadanych na dotkniętych tabelach. * Zwiększona pojemność na dotkniętych węzłach baz danych, aby zapewnić dodatkowe zagłówki. Zmiany te stopniowo stabilizowały system, a incydent został całkowicie rozwiązany o 16: 16 PDT. # # Pozycje akcji Aby zapobiec nawrotom, wdrażamy następujące działania: 1. Zmodernizowaliśmy backend, który zawiera podstawowe ulepszenia, które obsługują kolce pamięci spowodowane nadmiernym usuwaniem plików. 2. Wykonaliśmy automatyczne zadania zagęszczania nowo wprowadzonych tabel, aby zapobiec usuwaniu gromadzenia plików do przodu.
Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.
Obecnie badamy tę kwestię.
Problem został zidentyfikowany i jest w trakcie wdrażania.
Wprowadzono rozwiązanie i monitorujemy wyniki.
Ten incydent został rozwiązany.
# Streszczenie W dniu 17 lipca 2026 r., po rutynowym wdrożeniu kodu, klienci w starszych wersjach delegatów\ (858xx i poniżej\) zaczęli doświadczać opóźnionych budowania CI na budynkach Harness Cloud- hosted przy użyciu naszej globalnej zdolności build- queueing. Dotknięte budowle doświadczyły nieoczekiwanej przerwy do około 8 minut na etapie "oczekiwania na infrastrukturę" przed kontynuowaniem, a nie postępując w oczekiwanym poddrugim czasie. Ogólna powolność budowy była przerywana. # Impact * Wszystkie budynki CI były potencjalnie narażone na opóźnienia; wpływ był najwyraźniejszy dla budowania na infrastrukturze Harness Cloud- hosted za pomocą globalnej funkcji build- queueing. * Affected builds doświadczył niewyjaśnionej przerwy do około 8 minut przed kontynuowaniem, a następnie wolniejszego "zimnego startu", ponieważ wcześniej zarezerwowane slot obliczeniowy nie było dostępne - to przedstawione użytkownikom jako powolne builds raczej niż budować niepowodzenia. * Konta uruchomione na nowszych wersjach delegatów\ (858xx i powyżej\) nie miały wpływu. * Bezpośrednio w wyniku tego problemu nie udało się zbudować żadnego budynku, a dane nie zostały utracone. # Root Cause Przyczyną była wewnętrzna zmiana kodu, która nieumyślnie złamała sposób, w jaki określony rekord build- queeing został odczytany z naszej bazy danych raz builds, który został już w kolejce zgodnie z poprzednią wersją kodu napotkał nowo wdrożoną wersję. Rozwiązaliśmy ten natychmiastowy wpływ poprzez oczyszczenie uszkodzonych rekordów i odwrócenie podstawowej zmiany kodu i wdrażamy kilka zabezpieczeń, aby zapobiec powtarzaniu się tej klasy problemów. Uzasadnienie # Next Steps Oceniamy ryzyko podobnych nawrotów tak niskich, jak następujące działania są understaken. Określona ścieżka kodowa, która spowodowała ten incydent, została już odwrócona, a my wdrażamy zabezpieczenia strukturalne, tak aby ta ogólna klasa emisji nie mogła się powtórzyć, niezależnie od tego, gdzie w kodebazie może się ona pojawić. * * Działanie korygujące / zapobiegawcze * * 124; - DODATKOWE 124; Dodawanie wyraźnych, stabilnych identyfikatorów do wszystkich wewnętrznych klas danych, które są przechowywane w naszej bazie danych, tak aby przyszłe wewnętrzne reorganizacje kodów nie mogły przerwać zdolności systemu do odczytu wcześniej przechowywanych rekordów. VIId; 124; Wprowadzenie badania kompatybilności zwrotnej i wstecznej w naszym środowisku przedprodukcyjnym, specjalnie zaprojektowane, aby złapać tę klasę problemu, zanim dotrze do produkcji. VIId
Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.
Obecnie badamy tę kwestię.
Problem został zidentyfikowany i jest w trakcie wdrażania.
Wprowadzono rozwiązanie i monitorujemy wyniki.
Nadal monitorujemy wszelkie dalsze problemy.
Ten incydent został rozwiązany.
# Streszczenie Między 19 czerwca a 17 lipca 2026 roku budynek w Git Clone krok - i każdy etap rurociągu za pomocą wtyczki drone-git klon - nie powiodło się na ARM64 Kubernetes budować infrastrukturę z błędem exec / usr / local / bin / clone: błąd formatu exec. AMD64\ (Intel / AMD\) builds, Windows builds, a ścieżka binarna bez zawartości VM nie została naruszona. Przyczyną był błąd w naszym wewnętrznym procesie publikowania obrazów, który spowodował, że obrazy dronegit oznaczone ARM64- Git rzeczywiście zawierają AMD64 binarne. Zidentyfikowaliśmy i złagodziliśmy ten problem tego samego dnia, kiedy został on zgłoszony przez powrót obrazu drone-git do ostatniej znanej-dobrej wersji. Nie było wymagane działanie klienta ani zmiana konfiguracji. # Root Cause W dniu 19 czerwca 2026 roku rekultywacja bezpieczeństwa zrestrukturyzowała sposób budowy obrazu drone-git. Builds AMD64 zostały prawidłowo zaktualizowane, ale rurociąg ARM64 nie budował bezpośrednio plików ARM64 - zaadaptował plik AMD64 build poprzez zastąpienie tekstu i skompilował go na infrastrukturze ARM64. Zmiana z 19 czerwca zmieniła plik AMD64 tak, że substytucja po cichu nie-op 'd zamiast niepowodzenia, więc rurociąg opublikował obraz oznaczony ARM64, którego Git Clone i Git LFS binarne były nadal kompilowane dla AMD64. # Impact * Affected: Built- in Git Clone step, a każdy etap rurociągu za pomocą wtyczki drone- git klon, działa na ARM64 Kubernetes budować infrastrukturę, na wszystkich kontach, między 6 lipca i 17 lipca 2026. * Symptom: Builds failed at the Git Clone step with exec / usr / local / bin / clone: exec format error. * Nie dotyczy: AMD64\ (Intel / AMD\) Kubernetes i VM builds, Windows builds, VM containerless ścieżka realizacji i nasz hartowany wariant obrazu. # Litigation Odwróciliśmy wersję obrazu drone-git, używaną we wszystkich usługach, których dotyczy, do ostatniej znanej wersji. To w pełni rozwiązało awarię wykonania ARM64; nie było wymagane żadne zmiany konfiguracji klienta. # Next Steps Aby zapobiec powtórzeniu się takich kwestii. * Rebuild the ARM64 image publishing gape to build our dedicated ARM64 build files directly, rather than adaptation the AMD64 build files. * Wzmocnienie automatycznej walidacji post- publikowania do każdego wydania obrazu: zweryfikować architekturę binarną pasuje do znacznika obrazu, i uruchomić funkcjonalny test dymu zanim obraz zostanie uznany za usuwalny. * Rozszerz automatyczne pokrycie testowe do ARM64 Kubernetes budować scenariusze. * Usunięcie z obiegu po zatwierdzeniu poprawionego wydania.
Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.