Prod2 nu a fost disponibil intermitent
Pending
Componente afectate
Platform
- investigating
În prezent investigăm această problemă.
- resolved
Acest incident a fost rezolvat.
Traducere automată din actualizarea oficială a incidentului.
88 incidente Harness înregistrate începând din martie 2026, cu actualizări oficiale, componente afectate, durată și informații despre rezolvare.
În prezent investigăm această problemă.
Acest incident a fost rezolvat.
Traducere automată din actualizarea oficială a incidentului.
Execuţia conductei este blocată în Prod1. Investigăm problema.
A fost implementată o soluţie şi monitorizăm rezultatele.
Acest incident a fost rezolvat.
Traducere automată din actualizarea oficială a incidentului.
În prezent investigăm această problemă.
Problema a fost identificată și se pune în aplicare o soluție.
A fost implementată o soluţie şi monitorizăm rezultatele.
Acest incident a fost rezolvat.
## Rezumat În perioada 27 august - 28 august 2026, clienții au avut o problemă în care unele conducte, aplicații și resurse conexe nu au fost găsite în Harness UI și API, chiar dacă datele subiacente au rămas intacte. Problema a avut loc în timpul unei actualizări planificate a infrastructurii interne care a afectat comunicarea între serviciile de platformă internă. Prin urmare, cererile care depind de conturi, organizarea și soluționarea domeniului de aplicare al proiectului nu au fost în măsură să se finalizeze cu succes, ceea ce a dus la nerealizarea unor răspunsuri care nu au fost găsite incorecte și returnate clienților entităților existente. Ingineria a identificat problema, a returnat schimbarea şi a restaurat serviciul normal. Nu au fost pierdute sau șterse datele clienților în timpul incidentului. ## Root Cause Problema a fost cauzată de o eroare de configurare introdusă în timpul unei actualizări planificate a rutei serviciilor interne în producție. Un serviciu de platformă internă responsabil pentru rezolvarea contului, organizarea și contextul proiectului nu a putut valida cererile altor servicii Harness după aplicarea modificării. Deoarece această etapă de validare este necesară înainte ca multe entități să citească și să poată continua acțiunile legate de conducte, cererile eșuate au apărut pentru clienți, deoarece nu s-au găsit erori pentru resursele care au continuat să existe în mod normal. Problema s-a limitat la mediul de producție afectat și a fost rezolvată prin inversarea schimbării și restabilirea traseului de comunicare al serviciului anterior. ## Impact * Unii clienți au văzut conductele existente, implementarea, și entitățile conexe apar ca nefiind găsite în UI și API. * Unele operaţiuni legate de conducte, inclusiv progresia execuţiei, start-uri declanşate prin webhook, evaluarea declanşării programate şi listarea entităţilor, au fost întrerupte temporar. * Problema a afectat disponibilitatea și vizibilitatea entităților existente, dar nu a eliminat datele sau nu a modificat configurația clienților. * Nu a avut loc nici un acces neautorizat şi nu s- au observat pierderi de date ale clienţilor. ## Remediation * **Imediat:** Reversificarea configurației infrastructurii actualizează și restaurează calea de comunicare a serviciului de lucru anterior. * **Recunoaștere validare:** Verificat că căutarea entităților afectate, operațiunile de conducte și API dependente au funcționat în mod normal după răsturnare. * **Permanent:** Corectat manipularea configurației asociate cu actualizarea astfel încât problemele similare să nu interfereze cu autentificarea serviciului la serviciu în viitoarele versiuni. ## Action items Pentru a preveni astfel de probleme să se întâmple din nou, Harness va 1. Îmbunătăţirea validării configuraţiei prin îmbunătăţirea testelor de pre-alocare pentru verificarea comunicării interne a serviciilor înainte de schimbarea traficului de producţie. 2. Sporirea monitorizării și alertarea pentru defecțiunile de autentificare internă, astfel încât problemele să poată fi detectate mai devreme. 3. Îmbunătățirea gestionării erorilor, astfel încât eșecurile dependenței sunt mai puțin susceptibile de a apărea clienților, deoarece resursele nu au găsit erori.
Traducere automată din actualizarea oficială a incidentului.
Investigăm în prezent o problemă raportată în conductele IACM din Prod-1, Prod-2, Prod-4 și UE1.
Continuăm să investigăm această problemă.
Am inversat schimbarea care a cauzat această problemă în toate grupurile.
Acest incident a fost rezolvat.
Traducere automată din actualizarea oficială a incidentului.
În prezent investigăm această problemă.
În prezent, investigăm rapoarte conform cărora interfaţa de utilizator "Feature Management & Experimentation" (FMC) nu se încarcă. Clienții care încearcă să acceseze consola IFM pot întâmpina erori sau pagini care nu răspund. Se consideră că evaluarea caracteristicilor steagului și traficul SDK nu sunt afectate. O nouă actualizare va urma în curând.
A fost implementată o soluţie şi monitorizăm rezultatele.
Acest incident a fost rezolvat.
## Rezumat * Începând de la **23:42 UTC** pe 23 august 2026, mai mulți clienți din Eurosistem au raportat eșecuri la încărcarea UI a băncii. *Artefactele de la CSN au expirat datorită unei politici de retenţie, ceea ce a dus la incapacitatea de a se încărca. * Orice cerere de pavilion se schimbă prin API, schimbarea de livrare, iar conducta de date a continuat să lucreze fără întrerupere. ## Root Cause * IU este servit de la un CDN. Artefactele UI au fost evacuate din cauza unei politici de retenţie, ceea ce a făcut ca UI să nu se încarce pentru toţi utilizatorii. ## Impact * IU a fost în imposibilitatea de a încărca pentru toți utilizatorii din toate mediile de producție. Ce nu a fost afectat? * Funcţionalitate SDK şi evaluare a pavilionului * Admin apeluri API * Date de configurare a steagului clientului * Nu au apărut pierderi de date ## Remediation * Fondatorul UI a fost restaurat în CDN printr-o implementare * Recuperare confirmată în toate mediile de producție înainte de închiderea incidentului. ## Action items * Îmbunătățește politica de reținere a activelor astfel încât versiunea activă în prezent nu este niciodată supusă evacuării.
Traducere automată din actualizarea oficială a incidentului.
În prezent investigăm această problemă.
Încetinirea poate determina oricare dintre simptomele de mai jos: - Conductele nu pornesc - Întârzieri în execuţie - Conductele fiind anulate din cauza timeouts
Furnizorul nostru de nori se confruntă cu un incident activ și noi urmărim.
Continuăm să investigăm această problemă.
Furnizorul nostru de cloud a confirmat un incident continuu care afectează mai multe regiuni. Conductele de stocare nu au suferit eșecuri ca urmare, deși unii utilizatori pot continua să experimenteze lentoare. Monitorizăm îndeaproape situația și vom oferi actualizări pe măsură ce devin disponibile mai multe informații.
Observăm latențe îmbunătățite la bord în urma fixării implementate de furnizorul nostru de cloud. Continuăm să monitorizăm îndeaproape situația și vom furniza actualizări suplimentare, după cum se justifică. Am observat unele execuții blocate pentru CI pentru câțiva clienți, pe care le investighează
Acest incident a fost rezolvat.
Sumarul La 20 august 2026, începând cu aproximativ ora 15:00 UTC, platforma Harness a cunoscut o degradare a performanței pe scară largă în toate mediile de producție. Execuţiile de conducte care în mod normal se termină în aproximativ două minute au durat şapte până la zece minute. Livrarea continuă, integrarea continuă, orchestrarea conductei și gestionarea caracteristicilor și experimentarea au fost toate afectate. Platforma Google Cloud a experimentat un incident multi-produs în regiunea ne-vest1 care afectează Bigtable, Compute Engine, Google Kubernetes Engine, și infrastructura de producție de tip I/O. Harness rulează pe discuri persistente în această regiune. Degradarea a ridicat latența de operare a bazei de date de la aproximativ 2 ms până la peste 10 ms la cea de-a 95-a percentilă, care, la rândul său, a cauzat decalajul de procesare a mesajelor și s-a propagat la fiecare serviciu care depinde de accesul la baza de date în timp util. # Impact A fost o degradare, nu o pană. Conductele au continuat să execute și să completeze cu succes pe tot parcursul; acestea au fost mai degrabă lente decât eșec. Nu s-au pierdut date și nu s-a renunțat la nicio lucrare a clienților ca urmare a acestui incident. Cauza Root Infrastructura de producție Harness în mediile afectate ruleaza pe Google Cloud Platform discuri persistente în regiunea ne-vest1. Atunci când acest strat de stocare s-a degradat, efectul s-a propagat prin platformă într-un lanț previzibil: **Degradarea Persistent-disc I/O în noi-vest1. ** Platforma Google Cloud a experimentat un incident multi-produs care afectează Bigtable, Compute Engine, Google Kubernetes Engine, și performanță persistentă-disc. Acesta a fost un eșec de infrastructură în mediul furnizorului, în afara controlului Harness. # **Acţiuni preventive** Deși Harness nu poate preveni un eșec al infrastructurii unui furnizor de cloud. Acțiunile de mai jos vizează detectarea unuia mai rapid și o mai bună poziționare a acestuia. Traducerea şi adaptarea: - Da.
Traducere automată din actualizarea oficială a incidentului.
În prezent investigăm această problemă.
Problema a fost identificată și se pune în aplicare o soluție.
A fost implementată o soluţie şi monitorizăm rezultatele.
Acest incident a fost rezolvat.
### Rezumat La 20 august 2026, între 10:24 și 14:55 UTC, un subset de scrieri ale IFM a eșuat. Scrisorile făcute din IU abonat și scrise cu jetoane de acces Harness nu au fost afectate. Evaluarea pe termen lung a drapelului a continuat să funcționeze normal. Problema a fost atenuată prin revenirea la o schimbare recentă de autentificare într-un serviciu de guvernanță partajată, iar textele afectate au revenit la normal până la 14:55 UTC. Status: [https://status.harness.io/incidens/rhthgm7d5dkz](https://status.harness.io/incidens/rhthgm7d5dkz) ### Root Cause O modificare a modului în care un serviciu de guvernanță partajată autentificat de apeluri de intrare a avut ca rezultat respingerea unor cereri de transfer de fonduri proprii de nivel 1 de bază. Aceste scrieri au folosit acreditări de serviciu la serviciu pe care serviciul de guvernanță nu le mai putea verifica după schimbare. În cazul în care o politică de guvernanță neagă în mod intenționat o schimbare, se constată o incapacitate de guvernanță a clientului ca HTTP 499, același statut utilizat. Deoarece 499 este un răspuns valid și așteptat în această cale de negare, eșecurile nu arătau ca o întrerupere a alertelor noastre, iar incidentul a fost identificat mai degrabă din rapoartele clienților decât din cele interne. Impact * Un subset de API scrie nu a reușit în timpul ferestrei, în primul rând cele realizate folosind moștenirea API taste sau schimbarea de programare cerere cerere. * Scrisorile făcute din IU-ul de la Fond nu au fost afectate. * Scrie folosind jetoane de acces Harness \ (PAT și SAT\) nu au fost afectate. *Runtime pavilion evaluare a continuat în mod normal. * Nu au avut loc pierderi de date. Scrierile eșuate nu s-au aplicat. ### Remediation Reversificarea schimbării de autentificare a serviciului de guvernanță. Scrisorile afectate au revenit imediat la normal. ### Action items Pentru a preveni astfel de probleme să se întâmple din nou, * Harness va returna o eroare distinctă \ [nu 499\) atunci când un scris nu reușește deoarece guvernanța nu a putut fi evaluată, așa că nu este confundată cu o negare intenționată a politicii. * Adăugați alertarea cu privire la evaluarea de guvernanță în sine apel, mai degrabă decât bazându-se pe codul de stare cu care se confruntă clientul. * Extinderea sprijinului de autentificare pentru evaluările de politică. * Extinde acoperirea automată pentru scenarii suplimentare de scriere.
Traducere automată din actualizarea oficială a incidentului.
În prezent investigăm această problemă.
Continuăm să investigăm această problemă.
Problema a fost identificată și se pune în aplicare o soluție.
A fost implementată o soluţie şi monitorizăm rezultatele.
Continuăm să monitorizăm orice alte probleme.
Acest incident a fost rezolvat.
** Summary ** La 19 august 2026 între 12:35 și 17:29 UTC, serviciul de securitate Harness Application Security a suferit o perturbare semnificativă atât a consolei orientate către clienți, cât și a conductei de ingerare a datelor din regiunile SaaS Production și SUA1. **Root Cause** Serviciul de configurare internă care furnizează setările runtime pentru aproape orice altă componentă a devenit supraîncărcat și a intrat într-un ciclu de repornire repetată. Deoarece atât de multe servicii depind de aceasta, efectele au fost largi: pagini de consolă, cum ar fi politicile de protecție, vizualizările posturale, jurnalele de activitate, inventarul API și politica personalizată nu au reușit să încarce sau să se sincronizeze, iar procesarea în aval a fost blocată în timp ce aștepta configurarea pe care nu o putea obține. Traducerea şi adaptarea: Traducerea şi adaptarea: - Da. Impact Console \ Decalajul consumatorilor a crescut prin normalizarea, gruparea, detectarea anomaliei, generarea și etapele de prelucrare aferente. **Contenție** Câteva atenuări intermediare suplimentare CPU și memorie, limite relaxate de verificare a sănătății, o bază de date de repornire, și un bazin de conectare mai mare ameliorat problema. Dezactivarea noii caracteristici atât în regiunile afectate restaurat prin pus brusc și durabil. Incidentul a fost rezolvat la 17:29 UTC. # **Acţiuni preventive** Următoarele acțiuni sunt angajate și urmărite intern până la finalizare. Caracteristica care a declanșat acest incident rămâne dezactivată și nu va fi reactivată până când lucrarea de mai jos este completă și validată. Traducerea şi adaptarea: - Da. Adăugați un indice de bază de date construit pentru modelul de acces de căutare a serviciilor
Traducere automată din actualizarea oficială a incidentului.
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.
Monitorizăm conductele blocate din prod2. Noile execuţii trec în timp ce noi monitorizăm continuu serviciile.
Monitorizăm conductele blocate din prod2. Pentru clienţii care încă mai văd conducte blocate, vă cerem să anulaţi şi să re-declanşaţi.
Acest incident a fost rezolvat.
"Summary" La 6 august 2026 \ [dimineața PDT\], unii clienți care rulează conducte în mediul de producție Prod2 au observat execuții ale conductelor care au încetat să mai facă progrese Problema a fost raportată de clienții afectați. Inginerii Harness au identificat cauza, au atenuat impactul şi execuţiile conductelor au revenit la funcţionarea normală. Problema a fost cauzată de o expresie auto-preferențială a conductei. Un webhook Git a declanşat o conductă care a făcut referire la conţinutul sarcinii utile webhook, iar sarcina utilă în sine conţinea copii suplimentare ale aceleiaşi expresii. Prin urmare, fiecare rundă de rezoluție a expresiei a produs mai multe expresii pentru a rezolva, dublezând cantitatea de muncă de fiecare dată. Acest lucru a epuizat resursele instanţei de serviciu care a procesat această execuţie, precum şi alte execuţii atribuite în aceeaşi instanţă nu au putut progresa în timp ce se afla în acest stat. ## **Impact** În timpul ferestrei incidentului \ (aproximativ 6:11 AM - 11:23 AM PDT pe 6 august 2026\): * Execuțiile de conducte ale unor clienți de pe Prod2 au stagnat la mijlocul execuției și nu au mai făcut progrese. * Execuțiile afectate nu au produs noi actualizări de stare și au trebuit să fie anulate și re-run după atenuare. * Comportamentul a fost limitat la executii fiind prelucrate de instanta de serviciu afectate Nu a fost nicio pierdere de date**. Definiţiile conductelor, istoria execuţiei şi starea stocată nu au fost afectate. Majoritatea conductelor de pe Prod2 au continuat să execute cu succes pe parcursul incidentului; principalul impact a fost că unele execuţii în timpul zborului nu au putut fi finalizate şi necesare pentru a fi reluate după atenuarea problemei. ## **Root Cause** Conductele de harness susţin expresiile care sunt rezolvate în timpul de funcţionare În acest caz, un mesaj de comitere Git conținea textul literal al expresiei de încărcare utilă în sine, de două ori, iar conducta făcea referire la aceeași expresie de încărcare utilă. Deoarece mesajul de comitere face parte din sarcina utilă webhook, rezolvarea expresiei a introdus întreaga sarcină utilă Aceste copii nou introduse au fost apoi tratate ca expresii care trebuie rezolvate, iar fiecare trecere a introdus încă două copii complete ale sarcinii utile. Mărimea valorii fiind procesată, iar munca necesară pentru a o procesa, prin urmare, s-a dublat la fiecare trecere și a crescut exponențial mai degrabă decât convergent. Harness are scopul de a opri exact acest lucru: rezoluția expresiei este delimitată de o adâncime maximă a cuibului, dincolo de care rezoluția se oprește și conducta nu reușește cu o eroare explicită. Un defect în această salvgardare a însemnat că limita nu a fost aplicată în acest caz specific de auto-preferinţă, astfel încât rezoluţia a continuat necontrolată. Rezolutia expresiei ruleaza in linie pe firele care pornesc treptele conductei. Pe măsură ce fiecare trecere a consumat progresiv mai mult memorie și procesor fără a finaliza vreodată, instanta de servicii care efectuează că munca a încetat să mai facă progrese, și fiecare execuție atribuită acestui caz blocat ## **Contencios Harness a completat următoarele etape imediate de atenuare: * Identificat conducta și modelul de expresie responsabil pentru rezoluția fugar. * Oprit instanţa de serviciu afectate, astfel încât aceasta ar lua pe nici o lucrare mai departe. Celelalte cazuri sănătoase au fost preluate și prelucrate în mod normal la coadă. * Confirmat că execuţiile conductelor au revenit la normal şi au închis incidentul. Aceste acţiuni au restaurat comportamentul normal de execuţie a conductei şi au rezolvat impactul clientului. ## **Action items** Pentru a reduce riscul de recurență și a îmbunătăți detectarea, următoarele acțiuni sunt puse în aplicare în diferite etape: * Fixaţi defectul în adâncimea expresiei şi detecţia buclei de protecţie astfel încât expresiile autonome să fie prinse şi să eşueze rapid cu o eroare clară în loc să consume resurse fără obligaţii. * Prevenirea expresiilor de sarcină utilă să fie rezolvate din conținutul de declanșare sarcină utilă, eliminarea în întregime calea de auto-referențială. * Strângeţi adâncimea maximă de cuib de expresie şi evaluaţi detectarea explicită a buclei în plus faţă de limita de adâncime existentă. * Îmbunătățește testele automate în mediile pre-producție care reproduc modele de expresie auto-preferențiale și verifică dacă protecția le detectează și le oprește. * Adăugaţi monitorizarea pentru acest model în execuţiile conductelor astfel încât să fie detectat proactiv.
Traducere automată din actualizarea oficială a incidentului.
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.
În prezent investigăm această problemă.
A fost implementată o soluţie şi monitorizăm rezultatele.
Acest incident a fost rezolvat.
Traducere automată din actualizarea oficială a incidentului.
În prezent investigăm această problemă.
Problema a fost identificată și se pune în aplicare o soluție.
A fost implementată o soluţie şi monitorizăm rezultatele.
Acest incident a fost rezolvat.
# ** Summary ** Între 25 iulie și 4 august 2026, panourile de bord de execuție a conductelor și paginile de prezentare din clusterele Harness Prod 2 și Prod 3 au afișat date între timp real. Conductele în sine au continuat să construiască, să desfășoare și să execute în mod normal pe tot parcursul; problema s-a limitat la cât de repede au fost copiate înregistrările de execuție în baza de date care servește la raportarea și vizualizarea tabloului de bord. **Nu s-au pierdut date despre clienţi.** Fiecare înregistrare afectată a rămas stocată în mod durabil și a fost reutilizată în depozitul de date de analiză odată ce limitarea de bază a fost eliminată. La 1 august 2026, Harness a migrat clusterele afectate într-o versiune orizontală scalabilă și susținută de coadă a componentei replicare și a completat backfill-uri de date vizate pentru toate conturile afectate. Cauza Root Harness menține o componentă de captare a datelor care reproduce continuu înregistrările de execuție a conductei din depozitul de date operaționale primare într-un magazin de date separat pentru seriile temporale optimizat pentru tablouri de bord și întrebări de raportare. Tablouri de bord citite exclusiv de la magazinul de date de analiză. Când replicarea rămâne în urmă, tabloul de bord redă o viziune exactă, dar mai veche, asupra lumii, în timp ce execuţia însăşi nu este afectată. Acest lucru a fost cauzat de creșterea ascuțită, susținută a volumului de scriere a bazei de date dintr-un alt modul platforma Harness care partajează aceeași cale de replicare a depășit plafonul de trecere al versiunii mai vechi, mono-integrare a acelei componente încă rulează în Prod 2 și Prod 3. Un backlog format și a crescut. # **Acţiuni preventive** Harness a finalizat sau s-a angajat în următoarele acțiuni de prevenire a acestor probleme. Traducerea şi adaptarea: - Da.
Traducere automată din actualizarea oficială a incidentului.
În prezent investigăm această problemă.
Problema a fost identificată și se pune în aplicare o soluție.
A fost implementată o soluţie şi monitorizăm rezultatele.
Acest incident a fost rezolvat.
# **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.
Traducere automată din actualizarea oficială a incidentului.
Rezumat - Ne confruntăm intermitent cu probleme legate de conectivitatea rețelei cu incapacitatea VM de a se conecta la resurse externe. În prezent investigăm problema.
A fost implementată o soluţie şi monitorizăm rezultatele.
Continuăm să monitorizăm orice alte probleme.
Acest incident a fost rezolvat.
## Rezumat Începând cu 4 august 2026, IC runners în regiunile ne-vest1 și ne-central1 a experimentat intermitent timeouts conexiune de aproximativ 134 de secunde atunci când ajunge la servicii externe, cum ar fi GitHub și Bitbucket peste gateway-uri de rețea outbound. ## Impact * IC runners în regiunile afectate experimentat intermitent timeouts conexiune de aproximativ 134 secunde atunci când ajunge la servicii externe \(de exemplu, GitHub, Bitbucket\) peste gateway-urile noastre de rețea de ieșire. * Problema a fost intermitentă, mai degrabă decât constante conexiunile au reuşit sub sarcină normală, şi eşecuri grupate în perioadele de volum mare de trafic outbound. * Nu au fost pierdute sau corupte date. Aceasta a fost o problemă de interconectare a rețelei și de capacitate, nu o problemă de integrare a datelor. * noi-vest1 și noi-central1 au fost regiunile afectate; alte regiuni nu au fost afectate de această problemă. ## Root Cause Echilibrul nostru de sarcină distribuie traficul de ieșire prin mai multe porți NAT folosind o metodă de hashing bazată pe detalii de conexiune \ (sursa / adresa de destinație și port\). Pentru orice conexiune, aceste detalii rămân constante pentru acea conexiune. Am avut un val de trafic susţinut pentru câteva secunde care a congestionat porţile ## Action items Pentru a preveni astfel de probleme să se întâmple din nou Harness va, Creşterea capacităţii de conexiune în afara porţilor noastre NAT prin furnizarea de interfeţe de reţea externă suplimentare, oferind fiecărei porţi o reţea de conexiuni substanţial mai mare pe care o poate servi concomitent..
Traducere automată din actualizarea oficială a incidentului.
În prezent investigăm această problemă.
A fost implementată o soluţie şi monitorizăm rezultatele.
Acest incident a fost rezolvat.
Traducere automată din actualizarea oficială a incidentului.
În prezent investigăm această problemă.
Continuăm să investigăm această problemă.
Problema a fost identificată și se pune în aplicare o soluție.
Continuăm să lucrăm la o soluție pentru această problemă.
A fost implementată o soluţie şi monitorizăm rezultatele.
Continuăm să monitorizăm orice alte probleme.
Acest incident a fost rezolvat.
# 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._
Traducere automată din actualizarea oficială a incidentului.
Investigăm o problemă care afectează tabloul de bord AIDI. Utilizatorii pot experimenta perioade de încărcare crescute sau defecțiuni intermitente atunci când accesează tabloul de bord. Echipa noastră este activ de lucru pentru a identifica cauza rădăcină și de a restabili performanța normală. Vom furniza actualizări pe măsură ce mai multe informații devin disponibile.
Problema a fost identificată și se pune în aplicare o soluție.
A fost implementată o soluţie şi monitorizăm rezultatele.
Acest incident a fost rezolvat.
## Rezumat Clienții de pe Prod1, Prod2, și Prod3 clustere au experimentat defecțiuni intermitente de încărcare widget și a crescut timpul de încărcare atunci când accesa AIDI 2.0 borduri de bord pe 22 iulie 2026. Nu toate widget-urile au fost afectate simultan problema manifestată ca eșecuri sporadice mai degrabă decât o pană completă. Nu s-au pierdut date despre clienţi. Clienţii SEI 1.0 nu au fost afectaţi. ## Root Cause De-a lungul timpului, un proces de întreținere de bază de date de rutină nu a reușit să ruleze pe anumite tabele din baza noastră de date de analiză, determinând aceste tabele să acumuleze un volum mare de metadate interne utilizate pentru a urmări înregistrările șterse. Atunci când baza de date a planificat întrebări împotriva acestor tabele, a încărcat toate aceste metadate acumulate în memorie, cauzând utilizarea memoriei pe nodurile afectate pentru a Spike în mod repetat. Aceste piroane repetate au declanșat un mecanism automat de siguranță care reporneşte un nod atunci când detectează presiunea excesivă a memoriei, iar nodurile afectate au început să repornească într-o buclă ca rezultat. Acest lucru a cauzat o performanță intermitentă și degradată pe tabloul de bord AIDI 2.0 pe durata incidentului. ## Impact Clienții de pe Prod1, Prod2, și Prod3 clustere pot fi experimentat defecțiuni intermitente de încărcare widget sau ori de încărcare crescută pe AIDI 2.0 borduri de bord. **Duraţie:** 22 iulie 2026, 07:58 PDT Ce nu a fost afectat? * Ingestia și prelucrarea datelor * SEI 1.0 clienti * Fluxuri de integrare și metadate Nu s-au pierdut date despre clienţi. ## Remediation La identificarea problemei, nodurile de baze de date afectate au fost reluate la 08:25 PDT, care a restabilit stabilitatea inițială. Am continuat să monitorizăm îndeaproape sistemul, iar atunci când degradarea intermitentă a fost încă observată după aceea, am aplicat mai multe remedieri suplimentare: * Setări ajustate de configurare a bazei de date pentru a limita cantitatea de memorie utilizată pentru prelucrarea metadatelor acumulate, și setările reglate de interogare pentru a reduce presiunea de memorie. * A fugit de locuri de muncă de curățare pentru a reduce backlog de metadate acumulate pe tabelele afectate. * Creșterea capacității pe nodurile de baze de date afectate pentru a oferi headroom suplimentar. Aceste modificări au stabilizat progresiv sistemul, iar incidentul a fost complet rezolvat la 16:16 PDT. ## Action items Pentru a preveni recurența, punem în aplicare următoarele: 1. Am actualizat backend-ul care include îmbunătățiri care stau la baza care manipulează piroane de memorie cauzate de ștergerea excesivă a fișierelor. 2. Am lansat locuri de muncă compactare automată pentru tabele nou introduse pentru a preveni eliminarea acumulării de fișiere merge mai departe.
Traducere automată din actualizarea oficială a incidentului.
În prezent investigăm această problemă.
Problema a fost identificată și se pune în aplicare o soluție.
A fost implementată o soluţie şi monitorizăm rezultatele.
Acest incident a fost rezolvat.
Sumarul La 17 iulie 2026, ca urmare a implementării unui cod de rutină, clienții pe versiuni delegate mai vechi \ (858xx și mai jos\) au început să experimenteze CI întârziată construiește Harness Cloud-hosted construiește folosind capacitatea noastră globală de a construi. Clădirile afectate s-au confruntat cu o pauză neașteptată de până la aproximativ 8 minute în etapa de "asteptare pentru infrastructură" înainte de a continua, în loc să continue în timpul sub-al doilea așteptat. În general, lentoarea a fost intermitentă. # Impact * Toate clădirile CI au fost potenţial supuse întârzierii; impactul a fost cel mai pronunţat pentru construcţiile pe infrastructura găzduită de Harness Cloud folosind funcţia globală de construcţie. * Clădiri afectate experimentat o pauză inexplicabilă de până la aproximativ 8 minute înainte de a continua, urmată de un "start rece" mai lent, deoarece un slot de calcul pre-conservat nu a fost disponibil * Conturile care rulează pe versiuni delegate mai noi \ (858xx și mai sus\) nu au fost afectate. * Nici o construcţie nu a eşuat în mod direct ca urmare a acestei probleme şi nu s - au pierdut date. Cauza rădăcină Cauza rădăcină a fost o schimbare de cod intern care a rupt accidental modul în care a fost citită o anumită înregistrare de build-coueing din baza noastră de date o dată construiește care a fost deja coadă în conformitate cu versiunea anterioară a codului întâlnit versiunea nou implementată. Am rezolvat impactul imediat prin curățarea înregistrărilor afectate și revenirea la modificarea codului de bază și punem în aplicare mai multe garanții pentru a preveni repetarea acestei clase de emisiuni. Următorii paşi Evaluăm riscul unei recurenţe similare la fel de scăzute ca şi următoarele acţiuni întreprinse. Traseul specific de cod care a cauzat acest incident a fost deja returnat și punem în aplicare garanții structurale astfel încât această clasă generală de probleme să nu poată să reapară, indiferent de locul în care s-ar putea produce altfel. Traducerea şi adaptarea: - Da. Adăugați identificatori expliciti și stabili la toate clasele de date interne care sunt stocate în baza noastră de date, astfel încât reorganizările viitoare ale codului intern să nu poată rupe capacitatea sistemului de a citi înregistrările stocate anterior.
Traducere automată din actualizarea oficială a incidentului.
În prezent investigăm această problemă.
Problema a fost identificată și se pune în aplicare o soluție.
A fost implementată o soluţie şi monitorizăm rezultatele.
Continuăm să monitorizăm orice alte probleme.
Acest incident a fost rezolvat.
Sumarul Intre 19 iunie si 17 iulie 2026, intrarea in Git Clone pas AMD64 \ (Intel/AMD\) construiește, Windows construiește, și calea binară fără containere VM nu au fost afectate. Cauza rădăcină a fost un defect în procesul nostru de publicare a imaginii interne care a cauzat imagini ARM64-tagged drone-git să conțină de fapt binare AMD64. Am identificat şi atenuat problema în aceeaşi zi în care a fost raportată prin revenirea imaginii drone-git la ultima versiune cunoscută-bună. Nu a fost necesară nicio acțiune a clientului sau modificare a configurației. Cauza rădăcină La 19 iunie 2026, o remediere de securitate a restructurat modul în care este construită imaginea drone-git. Clădirile AMD64 au fost actualizate corect, dar conducta de construcţie ARM64 nu a construit fişiere ARM64 direct Schimbarea din 19 iunie a modificat fişierul AMD64 astfel încât înlocuirea tăcută nu-op'd în loc de a eşua, astfel încât conducta a publicat o imagine etichetat ARM64 ale cărui binare Git Clone şi Git LFS au fost încă compilate pentru AMD64. # Impact * Afected: The built-in Git Clone step, and any stream step using the drone-git clone plugin, running on ARM64 Kubernetes built infrastructure, all accounts, between July 6 to July 17, 2026. * Symptom: Builds failed at the Git Clone step with exec /usr/local/bin/clone: exec format eroare. * Neafectat: AMD64 \ (Intel/AMD\) Kubernetes și VM construiește, Windows construiește, VM cale de execuție fără containere, și varianta noastră de imagine întărită. # Diminuarea Am returnat versiunea de imagine a drone-git folosită în toate serviciile afectate până la ultima versiune cunoscută. Acest lucru a rezolvat complet eșecurile de execuție ARM64; nu au fost necesare modificări ale configurației clienților. Următorii paşi Pentru a preveni astfel de probleme să se întâmple din nou. * Reconstruiește conducta de publicare a imaginii ARM64 pentru a construi fișierele noastre ARM64 dedicate construi direct, în loc să adapteze fișierele de construcție AMD64. * Îmbunătățește validarea automată post-publică la fiecare versiune de imagine: verifica arhitectura binară se potrivește cu eticheta de imagine, și rula un test de fum funcțional înainte de o imagine este considerat relesable. * Extinde acoperirea automată de testare pentru a include ARM64 Kubernetes construi scenarii. * Eliminați versiunile de imagini intermediare afectate din circulație odată ce eliberarea corectată este validată.
Traducere automată din actualizarea oficială a incidentului.