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.
82 Split incidents · april 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.
# * * Oversigt * * Den 31. juli 2026, artefakt uploads udført gennem rørledning i EU1 klyngen begyndte at mislykkes med en autentificering fejl. Uploads startet manuelt\ (uden for en rørledning\) blev ikke påvirket, og evnen til at hente eksisterende artefakter\ (downloads\) var også upåvirket - dette blev isoleret til den specifikke rørledning upload sti i en klynge. * * * Impact * * * Artefakt uploads udført gennem rørledning i EU1 klyngen mislykkedes med en autentificering fejl i omkring 4 timer og 34 minutter. * Henter eksisterende artefakter\ (downloads\) blev ikke påvirket. * Manuel upload artefakter uden for en rørledning blev ikke påvirket. * Andre klynger / regioner blev ikke berørt af dette spørgsmål. # * * Rodårsag * * Den komponent, der er ansvarlig for håndtering af artefakt-uploads, distribueres som et containerbillede. I EU1-klyngen hentes dette billede fra et internt register, der afspejler en offentlig billedkilde; i andre klynger hentes det samme billede direkte fra den offentlige kilde. En publiceringsfejl i vores udgivelsesproces forårsagede en ny opbygning af denne komponent til at blive offentliggjort ved hjælp af en version etiket, der allerede var i brug, snarere end at blive tildelt en ny, unik version. Som et resultat, to forskellige billeder endte i forbindelse med samme version etiket i den offentlige kilde. Vores interne register spejle billeder fra den offentlige kilde via en automatiseret replikation proces. På grund af hvordan denne replikation blev udløst, kopierede den det originale\ (tidligere\) billede, der var forbundet med denne version etiket snarere end den korrigerede. Det betød, at EU1-klyngen - som trækker fra det indre spejl - endte med at køre et andet, defekt billede end andre klynger, som trækker direkte fra den offentlige kilde og derfor fik det korrigerede billede. Det defekte billede indeholdt en autentificering problem, der fik rørledningen uploads til at mislykkes. # * * Mitigation * * * Omvendt den berørte konto til den sidste kendte-god version af upload komponent, straks genoprette rørledningen uploads. * Udgivet en korrigeret, permanent version af komponenten til at løse problemet på tværs af alle klynger. Næste skridt Name * Fix upload trin for at fjerne den underliggende containerrelateret defekt, der gjorde denne fejl tilstand muligt. * Opdatér vores release pipeline for denne komponent, så at udgivelse af et billede aldrig kan overskrive en eksisterende version - hver publikation skal oprette en ny, særskilt version, der går fremad.
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 Under en nylig produktion implementering, en defekt i vores interne implementering værktøj forårsaget to kritiske tjenester til at køre med forkerte, ikke-produktion konfiguration værdier i vores produktionsmiljø Dette førte til et beslægtet sæt af fire forskellige symptomer: ukorrekt konfiguration adfærd, intermitterende login / adgang fejl, en filestore adgang problem påvirker en kunde miljø, og forsinkede pipeline status opdateringer i UI. Name Vi har identificeret og er ved at gennemføre en permanent rettelse for den underliggende konfiguration defekt, og har allerede sat ressourcer og kapacitet ændringer, der løser UI forsinkelse symptom. Name På intet tidspunkt under denne hændelse var rørledninger henrettelser selv tabt, beskadiget, eller efterladt i en fast tilstand. Hvor udførelse adfærd blev påvirket, det var begrænset til forsinkelser i status synlighed, ikke i den underliggende behandling. # Incident details # Forkert produktionskonfigurationsværdier anvendt Vores ingeniørhold bekræftede en fejl i servicehåndterens deployeringsrørledning, der fik visse produktionstjenester til at blive anvendt ved hjælp af konfigurationsværdier beregnet til et andet miljø, snarere end den korrekte produktionskonfiguration. Name * * Rodårsag * * Name Den tjeneste, der er ansvarlig for at hente konfiguration tilsidesætter under implementering forespørgsler en intern API, der returnerer maksimalt 1.000 resultater per anmodning. Det samlede antal tjenester i miljøet steg for nylig ud over denne grænse. Som et resultat, enhver service ud over de første 1.000 returnerede blev ikke inkluderet i svaret, og installationsledningen lydløst faldt tilbage til standard konfigurationsværdier for disse tjenester. Dette er en bekræftet pagineringsdefekt i deployeringsværktøjet, ikke et problem med konfigurationsværdierne selv. Name * * Opløsning * * Name Engineering har bekræftet mekanismen og er ved at gennemføre en permanent rettelse for at fjerne dette grænserelaterede hul i installationsledningen. # # Intermitterende login / adgangsfejl Under tjeneste Manager implementering refereret ovenfor, nogle brugere oplevede intermitterende login eller adgang fejl. Under normal drift bør tidligere kørende instanser fortsætte med at betjene trafikken uden afbrydelse, mens en ny ibrugtagning er i gang. I denne hændelse, at fallback adfærd ikke fandt sted som forventet, bidrage til at få adgang til fejl under implementering vinduet. # Filestore Access Emne Der blev identificeret et problem med filestore-adgang, som var specifikt for Prod-3-miljøet og påvirkede en enkelt kundes miljø. * * Rodårsag * * Dette er relateret til en IAM / storage- skovl tilladelse konfiguration på Service Manager, potentielt udløst af rollback aktivitet. # Forsinket Pipeline Udførelse statusopdateringer i UI Nogle brugere bemærkede, at den pipeline udførelse graf i UI var langsom til at opdatere og ikke afspejler den seneste status straks. Det er vigtigt, at dette kun var en forsinkelse af synligheden. Der var ingen indvirkning på egentlige henrettelser af rørledninger, og ingen henrettelser blev fanget eller mislykkedes som følge af dette spørgsmål. * * Rodårsag * * Grafen for udførelse af rørledningen er baseret på en meddelelsesstrøm\ (orkestreringsloggen\) for at modtage statusopdateringer. Under hændelsesvinduet, forbrugerbehandling af denne strøm faldt bag\ (høj forbruger lag\), som forsinkede, hvor hurtigt status opdateringer nåede UI. Dette skyldtes, at den underliggende database var midt i en planlagt skalering på samme tid, og en trafikstigning i dette vindue yderligere forværret forsinkelsen. Brugerne oplevede dette som tilsyneladende rørledning langsommelighed, selv om de underliggende henrettelser kørte normalt. * * Opløsning * * Vi har øget ressourcekapaciteten for de berørte komponenter for at opretholde mere end 50% ekstra headroom fremad, hvilket reducerer følsomheden over for lignende belastningsspidser. Denne ændring er blevet gennemført og er i øjeblikket ved at blive valideret som en del af den langsigtede hærdning for denne del af platformen. # Impact Summary * Service Manager og Licens Manager kørte med forkerte konfigurationsværdier i Prod-1 og Prod-3 miljøer. * Nogle brugere oplevede intermitterende login eller adgang fejl under den berørte implementering vindue. * En kunde miljø i Prod-3 oplevede en filestore adgang problem. * Brugere på tværs af berørte miljøer oplevede forsinkede pipeline udførelse status opdateringer i UI; underliggende pipeline henrettelser fortsatte med at køre korrekt og blev ikke tabt, sidder fast, eller beskadiget. # Forebyggende handlinger Følgende korrigerende og forebyggende foranstaltninger er blevet identificeret. Name ; * * Korrigerende / forebyggende aktion * * ECB 's Styrelsesråd Note 124; Korrekt paginering grænse i konfiguration- lookup service, så alle tjenester er returneret og evalueret, uanset den samlede antal. Note 124; Tilføj sikkerhedsforanstaltninger, så en tjeneste, der ikke kan hente sin konfiguration mislykkes sikkert\ (fx advarsler og blokerer implementering\) snarere end lydløst at falde tilbage til ikke-produktion standard.; Note 124; Forøg postgres og messaging- pipeline ressource headroom\ (mål: større end 50% ledig kapacitet\) for at reducere følsomhed over for samtidige belastning og skalering begivenheder.; Name _ Vi anerkender virkningen denne hændelse havde på tværs af flere områder af platformen og værdsætter din tålmodighed, som vi arbejder gennem en komplet opløsning. _
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 Customers on Prod1, Prod2, and Prod3 clusters experienced intermittent widget load failures and increased load times when accessing AIDI 2.0 dashboards on July 22, 2026. Not all widgets were affected simultaneously the issue manifested as sporadic failures rather than a full outage. No customer data was lost. SEI 1.0 customers were not impacted. ## Root Cause Over time, a routine database maintenance process failed to run on certain tables in our analytics database, causing those tables to accumulate a large volume of internal metadata used to track deleted records. When the database planned queries against these tables, it loaded all of this accumulated metadata into memory, causing memory usage on the affected nodes to spike repeatedly. These repeated spikes triggered an automatic safety mechanism that restarts a node when it detects excessive memory pressure, and the affected nodes began restarting in a loop as a result. This caused intermittent, degraded query performance on AIDI 2.0 dashboards for the duration of the incident. ## Impact Customers on Prod1, Prod2, and Prod3 clusters may have experienced intermittent widget load failures or increased load times on AIDI 2.0 dashboards. **Duration:** July 22, 2026, 07:58 PDT – 16:16 PDT \(~8 hours 18 minutes\), with intermittent widget failures; system was restarted and under active monitoring from 08:25 PDT onward. ### What was not impacted? * Data ingestion and processing * SEI 1.0 customers * Integrations and metadata flows No customer data was lost. ## Remediation Upon identifying the issue, the affected database nodes were restarted at 08:25 PDT, which restored initial stability. We continued to monitor the system closely, and when intermittent degradation was still observed afterward, we applied several additional fixes: * Adjusted database configuration settings to limit the amount of memory used for processing accumulated metadata, and tuned query-planning settings to reduce memory pressure. * Ran cleanup jobs to reduce the backlog of accumulated metadata on the affected tables. * Increased capacity on the affected database nodes to provide additional headroom. These changes progressively stabilized the system, and the incident was fully resolved at 16:16 PDT. ## Action Items To prevent recurrence, we are implementing the following: 1. We have upgraded the backend which includes underlying improvements that handle memory spikes caused by excessive delete files. 2. We have rolled out automated compaction jobs for newly introduced tables to prevent delete file accumulation going forward.
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.