Prod2 var periodisk ikke tilgængelig
Pending
Berørte komponenter
Platform
- investigating
Vi undersøger i øjeblikket dette spørgsmål.
- resolved
Denne hændelse er blevet løst.
Automatisk oversat fra den officielle hændelsesopdatering.
88 Harness incidents · marts 2026 — official updates, affected components, duration and resolution details.
Vi undersøger i øjeblikket dette spørgsmål.
Denne hændelse er blevet løst.
Automatisk oversat fra den officielle hændelsesopdatering.
Pipeline henrettelse sidder fast i Prod1. Vi undersøger sagen.
Et fix er blevet gennemført, og vi overvåger resultaterne.
Denne hændelse er blevet løst.
Automatisk oversat fra den officielle hændelsesopdatering.
Vi undersøger i øjeblikket dette spørgsmål.
Spørgsmålet er blevet identificeret, og et fix er ved at blive gennemført.
Et fix er blevet gennemført, og vi overvåger resultaterne.
Denne hændelse er blevet løst.
# # Summary Mellem august 27 og august 28, 2026, kunder oplevede et problem, hvor nogle rørledninger, installationer, og relaterede ressourcer syntes ikke at findes i Harness UI og API, selv om de underliggende data forblev intakt. Name Spørgsmålet opstod under en planlagt intern infrastrukturopdatering, der påvirkede kommunikationen mellem interne platformstjenester. Som et resultat, anmodninger, der afhang af konto, organisation og projekt rækkevidde løsning var ude af stand til at fuldføre med succes, hvilket førte til forkert ikke fundet svar bliver returneret til kunder for eksisterende enheder. Name Engineering identificeret problemet, rullede tilbage ændringen, og genoprettet normal service. Ingen kundedata blev tabt eller slettet under hændelsen. Name # Root Cause Emnet var forårsaget af en konfigurationsfejl indført under en planlagt intern service routing opdatering i produktion. En intern platformstjeneste med ansvar for løsning af konto, organisation og projektsammenhæng var ude af stand til at validere anmodninger fra andre Harness-tjenester efter ændringen blev anvendt. Fordi dette valideringstrin er påkrævet, før mange virksomheder læser, og dermed forbundne handlinger kan fortsætte, dukkede de mislykkede anmodninger op for kunderne som ikke fundet fejl for ressourcer, der fortsatte med at eksistere normalt. Spørgsmålet var begrænset til det berørte produktionsmiljø og blev løst ved at vende om og genoprette den tidligere servicekommunikationsvej. Name # Impact * Nogle kunder så eksisterende rørledninger, installationer, og relaterede enheder synes ikke at findes i UI og API. * Nogle relateret operationer, herunder udførelse progression, webhook- udløst starter, skemalagt udløser evaluering, og enhed notering, blev midlertidigt afbrudt. * Spørgsmålet påvirkede tilgængeligheden og synligheden af eksisterende enheder, men det ikke fjerne data eller ændre kundekonfigurationer. * Ingen uautoriseret adgang opstod, og ingen kunde tab af data blev observeret. # Respiration * * * Øjeblikkelig: * * Omvendt infrastrukturkonfigurationsopdateringen og genoprettet den tidligere fungerende kommunikationsvej. * * * Validering af inddrivelse: * * Bekræftet, at berørte enhed opslag, rørledninger operationer, og afhængige API 'er fungerede normalt efter rollback. * * * Fast: * * Korrigeret konfigurationshåndtering i forbindelse med opdateringen, så lignende problemer ikke forstyrrer service-to- service autentificering i fremtidige udrulninger. # Action Punkter For at forhindre sådanne spørgsmål i at ske igen, Harness vil 1. Forbedre konfigurationsvalidering ved at forbedre præ-implementering test for at kontrollere intern service kommunikation, før du skifter produktionstrafik. 2. Forbedre overvågning og advarsel for interne autentificering fejl, så problemer kan detekteres tidligere. 3. Forbedre fejl håndtering så afhængighed fejl er mindre tilbøjelige til at forekomme for kunderne som ressource ikke fundet fejl.
Automatisk oversat fra den officielle hændelsesopdatering.
Vi er i øjeblikket ved at undersøge et problem rapporteret i IACM-rørledninger i Prod-1, Prod-2, Prod-4 og EU1 sele klynger.
Vi fortsætter med at undersøge dette spørgsmål.
Vi har vendt den ændring, der forårsagede dette problem i alle klynger.
Denne hændelse er blevet løst.
Automatisk oversat fra den officielle hændelsesopdatering.
Vi undersøger i øjeblikket dette spørgsmål.
Vi er i øjeblikket ved at undersøge rapporter, som Feature Management & Experimentation (FME) brugergrænseflade ikke kan indlæse. Kunder, der forsøger at få adgang til FME-konsollen, kan støde på fejl eller uresponderende sider. Feature flag evaluering og SDK trafik menes ikke at blive påvirket. En yderligere opdatering vil følge om kort tid.
Et fix er blevet gennemført, og vi overvåger resultaterne.
Denne hændelse er blevet løst.
# # Summary * Startende på * * 23: 42 UTC * * den 23. august 2026, flere FME kunder rapporterede fejl indlæsning af FME UI. * FME UI Artefacts serveret fra CDN udløbet på grund af en tilbageholdelse politik, der forårsager FME UI til ikke at indlæse. * Enhver flag anmodning ændringer gennem API, ændre levering, og data pipeline fortsatte med at arbejde uden afbrydelse. # Root Cause * FME UI er serveret fra en CDN. UI artefakter blev smidt ud på grund af en tilbageholdelse politik, der får UI til at undlade at indlæse for alle brugere. # Impact * FME UI kunne ikke indlæse for alle brugere i alle produktionsmiljøer. Hvad var ikke påvirket? * SDK funktionalitet og runtime flag evaluering * Admin API opkald * Kundeflag konfigurationsdata * Ingen tab af data opstod # Respiration * FME UI blev restaureret i CDN gennem en deployering * Inddrivelse bekræftet på tværs af alle produktionsmiljøer, før du lukker hændelsen. # Action Punkter * Forbedre politikken for opbevaring af aktiver, så den nuværende aktive version aldrig er udsat.
Automatisk oversat fra den officielle hændelsesopdatering.
Vi undersøger i øjeblikket dette spørgsmål.
Den langsomme kan forårsage en af følgende symptomer: - Pipelines ikke starter - Forsinkelser i udførelsen - Pipelines bliver annulleret på grund af timeout
Vores cloud-udbyder står over for en aktiv hændelse, og vi følger op.
Vi fortsætter med at undersøge dette spørgsmål.
Vores cloud udbyder har bekræftet en igangværende hændelse påvirker flere regioner. Harness rørledninger har ikke oplevet fejl som følge heraf, selv om nogle brugere kan fortsætte med at opleve langsommelighed. Vi overvåger situationen nøje og vil give opdateringer, efterhånden som flere oplysninger bliver tilgængelige.
Vi observerer forbedrede latesser over hele linjen efter fix implementeret af vores cloud-udbyder. Vi følger fortsat situationen nøje og vil i givet fald ajourføre den yderligere. Vi bemærkede nogle faste henrettelser for CI for nogle kunder, som vi undersøger
Denne hændelse er blevet løst.
# Summary Den 20. august 2026, der begynder ca. 15: 00 UTC, oplevede Harness-platformen en udbredt forringelse af ydeevnen i alle produktionsmiljøer. Pipeline henrettelser, der normalt fuldføre i omkring to minutter tog syv til ti minutter. Kontinuerlig levering, kontinuerlig integration, rørledningskonstruktion og Feature Management & Experimentation blev alle påvirket. Google Cloud Platform oplevede en multi- produkt hændelse i vores-west1 region påvirker Bigtable, Compute Engine, Google Kubernetes Engine, og persistent- disk I / O. Harness produktionsinfrastruktur kører på persistente diske i denne region. Nedbrydningen hævede databasedrift latency fra ca. 2 ms til over 10 ms ved 95. percentil, hvilket igen forårsagede message- kø behandling forsinkelse og formeres til enhver tjeneste, der afhænger af rettidig databaseadgang. Name # Impact Det var en nedbrydning, ikke en afbrydelse. Pipelines fortsatte med at udføre og fuldføre med succes i hele; de var langsomme snarere end fiasko. Ingen data blev tabt, og ingen kundearbejde blev droppet som følge af denne hændelse. # * * Rodårsag * * Harness produktionsinfrastruktur i de berørte miljøer kører på Google Cloud Platform persistente diske i us-west1-regionen. Når dette lagringslag nedbrydes, formeres effekten gennem platformen i en forudsigelig kæde: * * Persistent- disk I / O nedbrydning i us- west1. * * Google Cloud Platform oplevede en multi-produkt hændelse, der påvirker Bigtable, Compute Engine, Google Kubernetes Engine, og persistent- disk ydeevne. Dette var en infrastruktur fiasko i udbyderens miljø, uden for Harness kontrol. * * * Forebyggende handlinger * * Selv om Harness ikke kan forhindre en cloud-udbyder infrastruktur fiasko. Følgende aktioner har til formål at opdage en hurtigere og være bedre placeret til at handle på det. 124; * * Aktion * * ECB 's Styrelsesråd ; Fortsæt rutinemæssig præ- test af målrettede tværregionale database fejl, som udført under denne hændelse, for at holde failover parathed verificeret snarere end antaget; • 124; • • • • • • • • • • • • • • • • • •
Automatisk oversat fra den officielle hændelsesopdatering.
Vi undersøger i øjeblikket dette spørgsmål.
Spørgsmålet er blevet identificeret, og et fix er ved at blive gennemført.
Et fix er blevet gennemført, og vi overvåger resultaterne.
Denne hændelse er blevet løst.
# # # Oversigt Den 20. august 2026, mellem 10: 24 og 14: 55 UTC, en delmængde af FME skriver mislykkedes. Skrifter lavet af FME UI og skriver lavet med Harness adgang tokens\ (PATs og SAT\) blev ikke påvirket. Evalueringen af løbetidsflag fortsatte med at fungere normalt. Spørgsmålet blev mildnet ved at vende en nylig godkendelse ændring i en delt governance service, og berørte skriver returneres til normal ved 14: 55 UTC. EU-erhvervsgrenens økonomiske situation # # Root Cause En ændring i, hvordan en fælles governance service bekræftede indgående opkald, resulterede i, at nogle FME-skrifter blev afvist. Disse skriver brugte service-to-service legitimationsoplysninger, som governance service ikke længere kunne kontrollere efter ændringen. [...]. Fordi 499 er et gyldigt, forventet svar i denne benægtelse sti, de fiaskoer ikke ligne en afbrydelse på vores advarsler, og hændelsen blev identificeret fra kunderapporter snarere end intern detektion. # # Impact * En delmængde af FME skriver mislykkedes under vinduet, primært dem lavet ved hjælp af arv API nøgler eller ændre anmodning planlægning. * Skrifter lavet af FME UI blev ikke påvirket. * Skrifter ved hjælp Harness adgang tokens\ (PATs og SAT\) var ikke påvirket. * Runtime flag evaluering fortsatte normalt. * Ingen tab af data opstod. Mislykkedes at skrive gjaldt ikke. Name # # Respiration Returnerede ændringen af regeringsgodkendelse. Påvirkede skriver returneres til normal straks. # # Aktionsposter For at forhindre sådanne problemer i at ske igen, * Hårdhed vil returnere en særskilt fejl\ (ikke 499\), når en skrive mislykkes, fordi styring ikke kunne evalueres, så det er ikke forvekslet med en bevidst politik benægtelse. * Tilføj advarsel om styring evaluering kalder sig, snarere end at stole på klient- vender status kode. * Udvid autentificering støtte til politiske evalueringer. * Udvid automatiseret dækning for yderligere skrive scenarier.
Automatisk oversat fra den officielle hændelsesopdatering.
Vi undersøger i øjeblikket dette spørgsmål.
Vi fortsætter med at undersøge dette spørgsmål.
Spørgsmålet er blevet identificeret, og et fix er ved at blive gennemført.
Et fix er blevet gennemført, og vi overvåger resultaterne.
Vi fortsætter med at overvåge for yderligere spørgsmål.
Denne hændelse er blevet løst.
* * Oversigt * * Den 19. august 2026 mellem 12: 35 og 17: 29 UTC, Harness Application Security Service oplevede en betydelig afbrydelse, der påvirker både customer-front konsol og data indtagelse rørledning i SaaS produktion og US1 regioner. Name * * Rodårsag * * Den interne konfiguration service, der leverer runtime indstillinger til næsten alle andre komponenter blev overbelastet og indtastet en gentagen genstart cyklus. Fordi så mange tjenester afhænger af det, virkningerne var brede: konsol sider såsom beskyttelse politikker, positivvisninger, aktivitet logs, API opgørelse, og brugerdefinerede politik undladt at indlæse eller timet ud, og downstream behandling gået i stå, mens venter på konfiguration, det ikke kunne opnå. # * * Kundepåvirkning * * ; * * Dimension * * ECB 's Styrelsesråd ; Console\ (UI\) effekt af 124; Flere sider undlod at indlæse eller timet ud, herunder beskyttelsespolitik, positionering begivenhed sider og positivvisninger inde dashboards og indsigt sider, aktivitet logforespørgsler, API lagerskærme, brugerdefineret politik, og sensitive- datavisninger og widgets.; Indtagelse virkning på 124; Sikkerhed telemetri behandling nedbrydes alvorligt og i nogle stier, stoppet helt. Forbrugernes forsinkelse voksede på tværs af normalisering, gruppering, anomali opdagelse, generation, og relaterede forarbejdningsfaser.; 12, tab af data 12, en delmængde telemetri indtaget under afbrydelsen blev permanent tabt.; Name * * Mitigation * * Flere mellemliggende lempelser yderligere CPU og hukommelse, afslappet sundhed-check tærskler, en database genstart, og en større forbindelse pulje forbedret problemet. EU 's indsats på dette område er blevet styrket. Hændelsen blev løst kl. 17.29 UTC. Name * * * Forebyggende handlinger * * Følgende handlinger er begået og sporet internt for at fuldføre. Den funktion, der udløste denne hændelse forbliver deaktiveret og vil ikke blive re- aktiveret, før arbejdet nedenfor er komplet og valideret. 124; * * Aktion * * ECB 's Styrelsesråd unit description in lists ; Optimere koden ved tuning parametre såsom cache udløsning og retention, evaluere cursor- baseret pagination for bulk regel hentning som regel tæller vokse 124; Note 124; Tilføj et målrettet-bygget databaseindeks for service-scoping adgangsmønster; Rekonstruere rørledning recovery semantics, så forbrugerne replay sikkert efter position- markør tab i stedet for at springe backlog Note 124; Mandat iscenesat udrulning til konfiguration tilsidesætter, der ændrer downstream anmodninger mønstre: lav volumen klynge, derefter midt volumen, derefter høj volumen Name Note 124; Forbedre observerbarhed ved at Instrumentere mere detaljerede målinger
Automatisk oversat fra den officielle hændelsesopdatering.
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.
Vi overvåger rørledningerne i prod2. De nye henrettelser foregår, mens vi løbende overvåger tjenesterne.
Vi overvåger rørledningerne i prod2. For de kunder, der stadig ser fast rørledninger, beder vi dig om at afbryde og genstarte.
Denne hændelse er blevet løst.
# * * Oversigt * * Den 6. august 2026\ (morgen PDT\), nogle kunder kører rørledninger i Prod2 produktionsmiljø observerede rørledningshenrettelser, der stoppede med at gøre fremskridt - etaper, der ikke forhånd og produceret yderligere output eller status opdateringer. Spørgsmålet blev rapporteret af berørte kunder. Harness ingeniører identificeret årsagen, afbødet virkningen, og rørledningen henrettelser tilbage til normal drift. Spørgsmålet var forårsaget af et selvreferenceudtryk. En Git webhook udløste en rørledning, der refererede til indholdet af webhook nyttelasten, og selve nyttelasten indeholdt yderligere kopier af samme udtryk. Hver resolution gav derfor flere udtryk at løse, hvilket fordobler arbejdsmængden hver gang. Dette udtømte ressourcerne fra den service instans behandling, at udførelse, og andre henrettelser til samme instans var ude af stand til at gøre fremskridt, mens det var i denne stat. # * * Impact * * Under hændelsesvinduet\ (ca. 6: 11 AM til 11: 23 AM PDT den 6 august 2026\): * Nogle kunders pipelines henrettelser på Prod2 gået i stå midt henrettelse og gjort ingen yderligere fremskridt. * Berørte henrettelser produceret ingen nye trin output eller status opdateringer, og måtte afbrydes og igen-køre efter afbødning. * Behavior var begrænset til henrettelser behandles af den berørte service instans - rørledninger håndteres af andre tilfælde fortsatte med at udføre normalt. Der var * * ingen tab af data * *. Pipeline definitioner, udførelse historie, og lagret tilstand var upåvirket. De fleste rørledninger på Prod2 fortsatte med at udføre med succes under hele hændelsen; den primære virkning var, at nogle in- flight henrettelser ikke kunne fuldføre og skulle køres igen, når problemet blev afhjulpet. # * * Root Case * * Harness rørledninger understøtter udtryk, der er løst ved runtime - for eksempel, et udtryk, der indsætter indholdet af Git webhook nyttelast, der udløste rørledningen. I dette tilfælde indeholdt en Git-meddelelse selve nyttelastudtrykkets bogstavelige tekst to gange, og rørledningen refererede til samme nyttelastudtryk. Fordi commitbrevet er en del af webhook nyttelasten, at løse udtrykket indsat hele nyttelasten - herunder de to bogstavelige kopier af udtrykket i commitbrevet. Disse nyligt indsatte kopier blev derefter behandlet som udtryk, der skal løses, og hvert pas indsat to mere fulde kopier af nyttelasten. Størrelsen af den værdi, der behandles, og det arbejde, der kræves for at behandle det, derfor fordoblet på hvert pass og voksede eksponentielt snarere end konvergerende. Harness har en sikring, der har til formål at stoppe netop dette: udtryksopløsningen afgrænses af en maksimal rededybde, hvorefter opløsningen stopper, og rørledningen svigter med en udtrykkelig fejl. En mangel ved denne sikring betød, at grænsen ikke blev anvendt i dette specifikke tilfælde med henvisning til sig selv, så løsningen fortsatte ukontrolleret. Udtryk opløsning kører inline på de tråde, der starter rørledningen trin. Som hvert pas forbruges gradvist mere hukommelse og CPU uden nogensinde at fuldføre, service instance udfører, at arbejde holdt op med at gøre fremskridt, og hver udførelse tildelt denne instans gået i stå - hvilket er, hvad kunderne rapporterede. # * * Mitigation * * Hårdhed fuldført følgende umiddelbart afbødende trin: * Identificerede rørledningen og det udtryksmønster, der er ansvarlig for den bortløbne opløsning. * Stoppede den berørte service instans, så det ville tage videre arbejde. De resterende sunde tilfælde afhentet og behandlet i kø henrettelser normalt. * Bekræftet, at rørledningen henrettelser vendte tilbage til normal og lukkede hændelsen. Disse handlinger genoprettet normal rørledning udførelse adfærd og løst customer-ansigt virkning. # * * * Aktionsposter * * For at mindske risikoen for gentagelse og forbedre afsløringen er følgende foranstaltninger i forskellige faser af gennemførelsen: * Retter defekten i udtryksdybden og smutdetektionsbeskyttelse, så selvreferenceudtryk fanges og mislykkes hurtigt med en klar fejl i stedet for at forbruge ressourcer uden bundet. * Undgå nyttelast udtryk fra at blive løst ud af udløser nyttelast indhold, fjerne selv-referencesti helt. * Stramme den maksimale udtryk rededybde og evaluere eksplicit loop detektion ud over den eksisterende dybde grænse. * Forbedre automatiserede test i præproduktionsmiljøer, der reproducerer selvreferenceudtryk mønstre og kontrollere, at sikringen registrerer og stopper dem. * Tilføj overvågning for dette mønster i rørledninger henrettelser, så det er opdaget proaktivt.
Automatisk oversat fra den officielle hændelsesopdatering.
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.
Vi undersøger i øjeblikket dette spørgsmål.
Et fix er blevet gennemført, og vi overvåger resultaterne.
Denne hændelse er blevet løst.
Automatisk oversat fra den officielle hændelsesopdatering.
Vi undersøger i øjeblikket dette spørgsmål.
Spørgsmålet er blevet identificeret, og et fix er ved at blive gennemført.
Et fix er blevet gennemført, og vi overvåger resultaterne.
Denne hændelse er blevet løst.
# * * Oversigt * * Mellem den 25. juli og den 4. august 2026 blev der i Harness Prod 2 og Prod 3-klyngerne vist data, der lå mellem tiden bag. Pipelines selv fortsatte med at bygge, implementere og udføre normalt i hele; spørgsmålet var begrænset til, hvor hurtigt udførelse optegnelser blev kopieret i databasen, der tjener rapportering og dashboard visninger. Name * * Ingen kundedata gik tabt. * * Hver berørt rekord forblev varigt gemt og blev genspillet i analytics datastore, når den underliggende begrænsning blev fjernet. Harness migrerede de berørte klynger til en horisontalt skalerbar, queue-backed version af replikationskomponenten den 1 august 2026 og afsluttede målrettede data backfills for alle berørte konti. # * * Rodårsag * * Harness vedligeholder en dataindsamlingskomponent, der kontinuerligt kopierer køreledningsoptegnelser fra den primære operationelle datastore til en separat tidsseriedatastore optimeret til dashboards og rapporteringsforespørgsler. Dashboards læser udelukkende fra analytikernes datastore. Når replikation sakker bagud, gør dashboards et præcist, men ældre syn på verden, mens selve udførelsen er upåvirket. Dette var forårsaget af skarp, vedvarende stigning i database skrive volumen fra en anden Harness platform modul deling den samme replikation sti oversteg gennemløbsloftet for den ældre, single-instance version af denne komponent stadig kører i Prod 2 og Prod 3. En efterslæb dannet og voksede. Name Name * * * Forebyggende handlinger * * Harness har gennemført eller forpligtet sig til følgende foranstaltninger for at forhindre sådanne spørgsmål. 124; * * Aktion * * ECB 's Styrelsesråd Note 124; Fint tune replikation forsinkelse advarsel, således at enhver forsinkelse ud over en defineret tærskel er anmeldt Note 124; Tilføj en replikation lag panel til standard platform overvågning bord, så rørledningen sundhed er synlig for on- call som standard Note 124; Reducer skriveforstærkning fra co-lejer moduler gennem per- modul hastighedsbegrænsning eller enhed filtrering på replikationsstrømmen
Automatisk oversat fra den officielle hændelsesopdatering.
Vi undersøger i øjeblikket dette spørgsmål.
Spørgsmålet er blevet identificeret, og et fix er ved at blive gennemført.
Et fix er blevet gennemført, og vi overvåger resultaterne.
Denne hændelse er blevet løst.
# **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.
Automatisk oversat fra den officielle hændelsesopdatering.
Resumé - Vi står periodisk over for problemer med netværksforbindelse med vores Build VM er ude af stand til at oprette forbindelse til eksterne ressourcer. Vi undersøger i øjeblikket spørgsmålet.
Et fix er blevet gennemført, og vi overvåger resultaterne.
Vi fortsætter med at overvåge for yderligere spørgsmål.
Denne hændelse er blevet løst.
## 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..
Automatisk oversat fra den officielle hændelsesopdatering.
Vi undersøger i øjeblikket dette spørgsmål.
Et fix er blevet gennemført, og vi overvåger resultaterne.
Denne hændelse er blevet løst.
Automatisk oversat fra den officielle hændelsesopdatering.
Vi undersøger i øjeblikket dette spørgsmål.
Vi fortsætter med at undersøge dette spørgsmål.
Spørgsmålet er blevet identificeret, og et fix er ved at blive gennemført.
Vi fortsætter med at arbejde på en løsning på dette problem.
Et fix er blevet gennemført, og vi overvåger resultaterne.
Vi fortsætter med at overvåge for yderligere spørgsmål.
Denne hændelse er blevet løst.
# 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._
Automatisk oversat fra den officielle hændelsesopdatering.
Vi undersøger et problem, der påvirker AIDI-dashboards. Brugerne kan opleve øgede belastningstider eller periodiske fejl, når de får adgang til instrumentbrætter. Vores team arbejder aktivt på at identificere årsagen og genoprette normal ydeevne. Vi vil levere opdateringer, efterhånden som flere oplysninger bliver tilgængelige.
Spørgsmålet er blevet identificeret, og et fix er ved at blive gennemført.
Et fix er blevet gennemført, og vi overvåger resultaterne.
Denne hændelse er blevet løst.
# # Summary Kunder på Prod1, Prod2, og Prod3 klynger oplevede intermitterende widget belastning svigt og øget belastning gange, når adgang til AIDI 2.0 dashboards den 22 juli 2026. Ikke alle widgets blev påvirket samtidigt problemet manifesteret som sporadiske svigt snarere end en fuld udfald. Ingen kundedata blev tabt. SEI 1.0 kunder blev ikke påvirket. # Root Cause Over tid, en rutinemæssig database vedligeholdelse proces undladt at køre på visse tabeller i vores analytics database, hvilket får disse tabeller til at akkumulere en stor mængde interne metadata, der anvendes til at spore slettede optegnelser. Når databasen planlagt forespørgsler mod disse tabeller, det indlæst alle disse akkumulerede metadata i hukommelsen, forårsager hukommelse brug på de berørte noder til at spike gentagne gange. Disse gentagne pigge udløste en automatisk sikkerhedsmekanisme, der genstarter en knude, når det registrerer overdreven hukommelsestryk, og de berørte knuder begyndte at genstarte i en løkke som et resultat. Dette forårsagede intermitterende, nedbrudt forespørgsel ydeevne på AIDI 2.0 dashboards for varigheden af hændelsen. # Impact Kunder på Prod1, Prod2 og Prod3 klynger kan have oplevet intermitterende widget belastningssvigt eller øgede belastningstider på AIDI 2.0 dashboards. * * Varighed: * * 22 juli 2026, 07: 58 PDT - 16: 16 PDT\ (~ 8 timer 18 minutter\), med periodiske widget fejl; systemet blev genstartet og under aktiv overvågning fra 08: 25 PDT videre. Hvad var ikke påvirket? * Data indtagelse og behandling * SEI 1.0 kunder * Integrationer og metadata strømme Ingen kundedata blev tabt. # Respiration Ved at identificere problemet, de berørte databaseknuder blev genstartet på 08: 25 PDT, som genoprettet indledende stabilitet. Vi fortsatte med at overvåge systemet nøje, og når intermitterende nedbrydning blev stadig observeret bagefter, vi anvendte flere yderligere rettelser: * Justerede databasekonfigurationsindstillinger for at begrænse mængden af hukommelse, der bruges til behandling af akkumulerede metadata, og justeret query- planlægning indstillinger for at reducere hukommelsestrykket. * Rensning job til at reducere den manglende akkumulerede metadata på de berørte tabeller. * Øget kapacitet på de berørte database knudepunkter til at give ekstra headroom. Disse ændringer stabiliserede systemet, og hændelsen blev løst 16: 16 PDT. # Action Punkter For at undgå gentagelser gennemfører vi følgende: 1. Vi har opgraderet backend, som omfatter underliggende forbedringer, der håndterer hukommelse spikes forårsaget af overdreven slette filer. 2. Vi har rullet ud automatiseret komprimering job for nyligt indført tabeller for at forhindre slette fil akkumulering fremad.
Automatisk oversat fra den officielle hændelsesopdatering.
Vi undersøger i øjeblikket dette spørgsmål.
Spørgsmålet er blevet identificeret, og et fix er ved at blive gennemført.
Et fix er blevet gennemført, og vi overvåger resultaterne.
Denne hændelse er blevet løst.
# Summary Den 17 juli 2026, efter en rutine kode implementering, kunder på ældre delegerede versioner\ (858xx og under\) begyndte at opleve forsinkede CI bygger på Harness Cloud- hosted bygger ved hjælp af vores globale bygning-queueing kapacitet. Berørte bygninger oplevede en uventet pause på op til ca. 8 minutter på "venter på infrastruktur" scenen, før de fortsatte, snarere end at fortsætte inden for den forventede sub- anden gang. Samlet bygget langsommelighed var intermitterende. # Impact * Alle CI bygger var potentielt udsat for forsinkelse; virkningen var mest udtalt for bygger på Harness Cloud- hostede infrastruktur ved hjælp af den globale build- queuing funktion. * Berørte bygninger oplevede en uforklarlig pause på op til ca. 8 minutter, før de fortsatte, efterfulgt af en langsommere "kold start", da en forudreserveret computerslot ikke var tilgængelig - dette præsenteret for brugerne som langsom bygger snarere end bygge fejl. * Konti, der kører på nyere delegerede versioner\ (858xx og over\) blev ikke påvirket. * Ingen bygger mislykkedes direkte som et direkte resultat af dette problem, og ingen data blev tabt. "Root Cause Roden årsag var en intern kode ændring, der uforvarende brød, hvordan en specifik bygning-queuing record blev læst tilbage fra vores database, når bygger, der allerede var blevet i kø under den tidligere version af koden stødte på den nyligt indsatte version. Vi løste den umiddelbare virkning ved at rydde op i de berørte poster og vende tilbage til den underliggende kode ændring, og vi er ved at gennemføre flere sikkerhedsforanstaltninger for at forhindre denne klasse af spørgsmål fra tilbagevendende. Name "Next Steps Vi vurderer risikoen for en lignende gentagelse så lavt som følgende handlinger understaken. Den specifikke kodesti, der forårsagede denne hændelse, er allerede blevet vendt tilbage, og vi gennemfører strukturelle sikkerhedsforanstaltninger, så denne generelle klasse af spørgsmål ikke kan gentage sig, uanset hvor i codebase det ellers kan forekomme. ; * * Korrigerende / forebyggende aktion * * ECB 's Styrelsesråd Note 124; Tilføj eksplicitte, stabile identifikatorer til alle interne dataklasser, der bliver gemt i vores database, så fremtidige interne kode reorganisationer ikke kan bryde systemets evne til at læse tilbage tidligere gemte optegnelser.; ; Introducer rollback og backward- kompatibilitet test i vores præ-produktion miljø, specielt designet til at fange denne klasse af problem, før det når produktionen.
Automatisk oversat fra den officielle hændelsesopdatering.
Vi undersøger i øjeblikket dette spørgsmål.
Spørgsmålet er blevet identificeret, og et fix er ved at blive gennemført.
Et fix er blevet gennemført, og vi overvåger resultaterne.
Vi fortsætter med at overvåge for yderligere spørgsmål.
Denne hændelse er blevet løst.
# Summary Mellem juni 19 og juli 17, 2026, build- in Git Clone trin - og enhver pipeline trin ved hjælp af drone- git klon plugin - mislykkedes på ARM64 Kubernetes bygge infrastruktur med fejlen exec / usr / local / bin / klon: exec format fejl. AMD64\ (Intel / AMD\) bygger, Windows bygger, og VM containerless binær sti blev ikke påvirket. Den grundlæggende årsag var en defekt i vores interne billedpublicering proces, der forårsagede ARM64- mærkede drone- git billeder faktisk indeholder AMD64 binære filer. Vi identificerede og mindskede problemet samme dag, det blev rapporteret ved at vende drone- git billede til den sidste knoglen- god version. Ingen kunde handling eller konfiguration ændring var påkrævet. "Root Cause Den 19. juni 2026 omstrukturerede en sikkerhedsrensning hvordan drone- git billede er bygget. AMD64 bygger blev opdateret korrekt, men ARM64 bygge pipeline ikke bygge ARM64 filer direkte - det tilpassede AMD64 bygge fil via tekst substitution og kompileret det på ARM64 infrastruktur. Den 19 juni ændring ændrede AMD64 fil, så substitution lydløst no- op 'd i stedet for at mislykkes, så rørledningen offentliggjort et billede mærket ARM64 hvis Git Clone og Git LFS binære filer blev stadig kompileret til AMD64. # Impact * Berørt: Byggeriet-i Git Clone trin, og enhver rørledning trin ved hjælp af drone- git klon plugin, kører på ARM64 Kubernetes bygge infrastruktur, på tværs af alle konti, mellem juli 6 og juli 17, 2026. * Symptomer: Bygninger mislykkedes på Git Clone trin med exec / usr / local / bin / clon: exec format fejl. * Ikke påvirket: AMD64\ (Intel / AMD\) Kubernetes og VM bygger, Windows bygger, VM containerless udførelse sti, og vores hærdede billede variant. # Mitigation Vi vendte drone- git billede version, der anvendes på tværs af alle berørte tjenester til den sidste known-god udgivelse. Dette helt løst ARM64 udførelse fejl; ingen kundekonfiguration ændringer var nødvendige. "Next Steps For at forhindre, at sådanne spørgsmål opstår igen. * Genopbygge ARM64 image publishing rørledning til at bygge vores dedikerede ARM64 bygge filer direkte, snarere end at tilpasse AMD64 bygge filer. * Forbedre automatiseret post- publicér validering til hver billedudgivelse: verificer binær arkitektur matcher billedmærket, og køre en funktionel røg test, før et billede anses for at kunne frigøres. * Udvid automatiseret test dækning til at omfatte ARM64 Kubernetes bygge scenarier. * Fjern de berørte mellemliggende billedversioner fra cirkulation, når den korrigerede frigivelse er valideret.
Automatisk oversat fra den officielle hændelsesopdatering.