Split driftsforstyrrelser

1. 27. oktober 2026 kl. 19.52 UTCinvestigating

   Vi undersøger i øjeblikket dette spørgsmål.

2. 27. oktober 2026 kl. 19.58 UTCinvestigating

   CI-rørledninger på VM-infrastrukturen svigter ved det indledende trin, fordi opgaven går til en delegeret uden for den planlagte pulje

3. 27. oktober 2026 kl. 21.15 UTCidentified

   Spørgsmålet er blevet identificeret, og et fix er ved at blive gennemført.

4. 27. oktober 2026 kl. 22.16 UTCmonitoring

   Et fix er blevet gennemført, og vi overvåger resultaterne.

5. 27. oktober 2026 kl. 22.24 UTCresolved

   Denne hændelse er blevet løst.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 19. oktober 2026 kl. 07.46 UTCinvestigating

   Vi undersøger i øjeblikket dette spørgsmål.

2. 19. oktober 2026 kl. 08.02 UTCidentified

   Spørgsmålet er blevet identificeret, og et fix er ved at blive gennemført.

3. 19. oktober 2026 kl. 08.04 UTCmonitoring

   Et fix er blevet gennemført, og vi overvåger resultaterne.

4. 19. oktober 2026 kl. 08.21 UTCresolved

   Denne hændelse er blevet løst.

5. 23. oktober 2026 kl. 18.21 UTCpostmortem

   # * * Oversigt * * Den 19. oktober 2026, mellem ca. 12: 10 AM og 12: 55 AM PDT, kunder på Prod4 oplevede fejl og periodisk manglende adgang til Harness Pipelines-tjenester. Kraftige henrettelser af rørledninger forårsagede en kraftig stigning i CPU og hukommelsesbrug på rørledningen, og i en kort periode var alle tjenestetilfælde ikke tilgængelige. Harness engineering skalerede tjenesten både lodret og vandret, som genoprettet service. Et fix for den underliggende adfærd bliver rullet ud. # * * Root Case * * Den 19. oktober, et stort antal samtidige henrettelser med meget store henrettelsesgrafer kørte en skarp stigning i klyngeressourcer. Servicen gemmer og henter denne fulde udførelse graf til visualisering formål og yderligere fremme rørledningerne til næste stater. Vores selvskalaer på Prod4 tog længere tid end normalt for skalering ressourcer på grund af en kraftig stigning i CPU og hukommelse. Som en del af fixet, vil opdateringen af udførelsesgrafen nu behandle grafen ændringer trinvist i stedet for den fulde graf. Det bliver rullet ud i en gradvis måde og vil blive helt rullet ud tidligst. # * * Impact * * * Berørte brugere: Kunder på Prod4. * Symptomer: manglende adgang til rørledning funktionalitet i Harness platform. * Data: Ingen tab af data. * Foreslåede workaround: Ingen påkrævet fra kunder. Harness Engineering løst problemet. * Varighed af virkning: Ca. 20 minutter fuld utilgængelighed og forringet ydeevne i 25 minutter. Harness fortsatte overvågningen efter genopretning og bekræftede platformstabilitet med kunderne. # * * Respiration * * * * Øjeblikkelig * * Harness engineering skaleret rørledningen service både lodret\ (flere ressourcer per eksempel\) og vandret\ (flere tilfælde\), og fjernet tilfælde i en usund tilstand. Tilfældet tæller stabiliseret og normal service blev genoprettet. Systemet vil forblive skaleret op indtil fixet er helt rullet ud. * * Permanente fix og action elementer * * For at forhindre sådanne spørgsmål i at ske igen, Harness er 1. Justering af auto heal / skalering proces, så virkningen er minimal til ingen. 2. Optimering af udførelse graf flow, så store grafer kan være proces hurtigere.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 15. oktober 2026 kl. 10.10 UTCinvestigating

   Vi undersøger i øjeblikket dette spørgsmål.

2. 15. oktober 2026 kl. 10.10 UTCidentified

   Spørgsmålet er blevet identificeret, og et fix er ved at blive gennemført.

3. 15. oktober 2026 kl. 10.27 UTCresolved

   Denne hændelse er blevet løst.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 15. oktober 2026 kl. 08.04 UTCinvestigating

   Vi undersøger i øjeblikket dette spørgsmål.

2. 15. oktober 2026 kl. 08.05 UTCidentified

   Spørgsmålet er blevet identificeret, og et fix er ved at blive gennemført.

3. 15. oktober 2026 kl. 08.09 UTCmonitoring

   Et fix er blevet gennemført, og vi overvåger resultaterne.

4. 15. oktober 2026 kl. 08.15 UTCresolved

   Denne hændelse er blevet løst.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 13. oktober 2026 kl. 01.06 UTCinvestigating

   Vi undersøger i øjeblikket dette spørgsmål.

2. 13. oktober 2026 kl. 01.07 UTCidentified

   Spørgsmålet er blevet identificeret, og et fix er ved at blive gennemført.

3. 13. oktober 2026 kl. 01.56 UTCmonitoring

   Et fix er blevet gennemført, og vi overvåger resultaterne.

4. 13. oktober 2026 kl. 04.29 UTCresolved

   Denne hændelse er blevet løst.

5. 23. oktober 2026 kl. 03.16 UTCpostmortem

   . .

Automatisk oversat fra den officielle hændelsesopdatering.

1. 12. oktober 2026 kl. 15.25 UTCinvestigating

   Vi oplever i øjeblikket HTTP 429 (rate- begrænsende) fejl, når Harness Cloud bygger adgang til Maven Central, som kan påvirke bygge udførelse. Vores team arbejder aktivt med Sonatype for at løse problemet så hurtigt som muligt. Vi vil give yderligere opdateringer, når vi gør fremskridt.

2. 12. oktober 2026 kl. 19.31 UTCresolved

   Denne hændelse er blevet løst.

3. 23. oktober 2026 kl. 03.06 UTCpostmortem

   tldr:\ (Der var en kort sats begrænsning af maven central\) Flere detaljer at følge

Automatisk oversat fra den officielle hændelsesopdatering.

1. 8. oktober 2026 kl. 10.23 UTCmonitoring

   Et fix er blevet gennemført, og vi overvåger resultaterne.

2. 8. oktober 2026 kl. 10.53 UTCresolved

   Denne hændelse er blevet løst.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 6. oktober 2026 kl. 21.46 UTCinvestigating

   Vi undersøger i øjeblikket dette spørgsmål.

2. 6. oktober 2026 kl. 21.47 UTCinvestigating

   Vi fortsætter med at undersøge dette spørgsmål.

3. 6. oktober 2026 kl. 22.03 UTCidentified

   Spørgsmålet er blevet identificeret, og et fix er ved at blive gennemført.

4. 6. oktober 2026 kl. 22.30 UTCmonitoring

   Et fix er blevet gennemført, og vi overvåger resultaterne.

5. 6. oktober 2026 kl. 22.30 UTCmonitoring

   Et fix er blevet gennemført, og vi overvåger resultaterne. Vi har fået bekræftet, at dette spørgsmål er løst.

6. 6. oktober 2026 kl. 22.44 UTCresolved

   Denne hændelse er blevet løst.

7. 23. oktober 2026 kl. 02.12 UTCpostmortem

   # 1. Oversigt Den 6. oktober 2026 kunne rørledninger med IaCM-fase ikke starte på Prod1 i ca. to timer. Berørte brugere oplevede en fejl, da rørledningen forsøgte at skabe sin udførelsesplan. Rørledninger, der ikke brugte en IaCM-fase fortsatte med at køre normalt i hele. Den underliggende årsag var en intern logging defekt i tjenesten, der håndterer IaCM fase udførelse: under en specifik, sjælden timing betingelse, at tjenesten eget logging system kunne ende med at vente på sig selv på ubestemt tid, hvilket igen bremsede den bredere proces, der er ansvarlig for at forberede rørledningen udførelse planer. Spørgsmålet blev udløst af et usædvanligt stort udbrud af log aktivitet fra en kundes rørledning. Vi løste den umiddelbare virkning ved at rulle tjenesten tilbage til sin tidligere stabile version, og en permanent kode fix er i øjeblikket i test. # 2. Impact * Alle rørledninger med en IaCM-fase på Prod1 kunne ikke starte i ca. to timer. * Flere kunder på Prod1 klyngen blev påvirket. * Pipelines, der ikke bruger en IaCM-fase blev ikke påvirket og fortsatte med at køre normalt. * Ingen data blev tabt som følge af denne hændelse. * Som en bivirkning af rollback bruges til at løse denne hændelse, en ikke-relateret fix for en kunde\ (udvidelse af hvor længe en vis godkendelse token forbliver gyldig i lange rørledninger\) blev midlertidigt vendt tilbage. Det fiks blev genanvendt samme aften. # 3. Rodårsag Den tjeneste, der er ansvarlig for IaCM-rørledningsfaserne, logger sin aktivitet gennem en intern kø: Logbeskeder placeres på køen, og en enkelt baggrundsmedarbejder læser løbende fra den og skriver meddelelserne ud. Hver for sig har denne tjeneste et filter, der kan omskrive sværhedsgraden af visse logbeskeder tilbage på samme kø. Under en specifik, smal timing betingelse, dette skabte et dødvande, hvis køen tilfældigvis var helt fuld på det nøjagtige tidspunkt en omskrevet besked blev sendt tilbage på det, den ene arbejdstager med ansvar for at frigøre plads på køen ville selv sidde fast venter på plads til at frigøre op, en betingelse, det aldrig kunne løse, da det var det eneste, der kunne have befriet dette rum. Når det skete, alle andre dele af tjenesten, der var nødvendige for at logge noget også blev hængende venter, som cascaded ind i de-plan- skabelsesprocessen mislykkes for enhver rørledning ved hjælp af en IaCM-fase. # 4. Opløsning * Rolled tjenesten tilbage til sin sidste stabile version, som løste den umiddelbare hændelse. # 5. Forebyggende handlinger 1. * * Optimer den underliggende defekt * *: Optimer og tune logging filter, så omskrivning af en meddelelses sværhedsgrad sker på den tråd, der genererede loglinjen, i stedet for at blive genindsendt gennem den samme baggrund arbejders kø, fjerne dødvandet tilstand helt. 2. * * Forbedre overvågning på logging- kø sundhed * *: tilføje målinger og alarmering på denne interne kø, så denne klasse af mætning sider vores on- call team automatisk snarere end at stole på kunderapporter. 3. * * Evaluere grænser og udføre høje stresstest med meget store rørledninger * *:

Automatisk oversat fra den officielle hændelsesopdatering.

1. 16. oktober 2026 kl. 10.41 UTCresolved

   Den 7. oktober 2026, fra 08: 00 UTC til 11: 00 UTC (1: 30 PM til 4: 30 PM IST), nogle rørledninger henrettelser på Prod 7 klyngen oplevede intermitterende svigt i politik (OPA) trin evalueringer.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 6. oktober 2026 kl. 12.54 UTCmonitoring

   Et fix er blevet gennemført, og vi overvåger resultaterne.

2. 6. oktober 2026 kl. 15.35 UTCresolved

   Denne hændelse er blevet løst.

3. 10. oktober 2026 kl. 01.57 UTCpostmortem

   # # # Oversigt Kunder på Prod 2 oplevede intermitterende svigt i et par Verificér trin ved opstart. Berørte trin mislykkedes kort efter lanceringen med en meddelelse, der indikerer Kontinuerlig Verifikation\ (CV\) kunne ikke nå en intern Harness service. Problemet stammede fra en nylig service opdatering, der indførte forbindelse pooling for at forbedre ydeevne og pålidelighed med en keep-alive indstilling uforenelig med den modtagende tjenestes timeout. Ingen kundedata blev tabt eller ødelagt. Kundeeffekt Kunder, der bruger CV Verificér trin på Prod-2 så intermitterende trin fejl under hændelsesvinduet. Fejlprocenten var lav - de fleste henrettelser gennemført med succes gennem hele vinduet. Pipelines, der ikke brugte CV Verify trin var upåvirket. # # Root Cause En nylig CV-opdatering af tjenesten indførte forbindelse pooling til en intern platform komponent, med en holdbarhed længere end den komponent tomgang timeout. Tilslutninger i tomgang længe nok blev lydløst lukket af serveren; CV-tjenesten ikke detektere dette og havde ingen gentry logik for sådanne fejl, hvilket får dem til at overflade direkte som Verify trin svigt. Problemet var intermitterende, fordi det kun påvirkede forbindelser, der tilfældigvis er tomgang længe nok til at udløbe. # # Mitigation Forbindelsen holder-levende varighed blev reduceret til at falde inden for den modtagende tjenestes tomgang. Fejl faldt til næsten nul straks, og der er ikke observeret yderligere trin fejl af denne type på noget produktionsmiljø. Næste skridt For at forhindre gentagelse, vil Harness: * * * Retter forbindelseshåndtering: * * Tuneret standard holde-i live og aktiveret automatisk prøve på forbindelse fejl, så stille- forbindelse fejl håndteres gennemsigtigt. * * * Tilføj modstandsdygtighed ved trinopstart: * * Introducer gentag med backoff for den interne service opkald ved Verify trin start, så isolerede forbigående svigt ikke overflade som umiddelbare trin svigt. * * * Forbedre alarmering: * * Forbedret overvågning af interne fejlrater for forbindelse.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 6. oktober 2026 kl. 11.58 UTCinvestigating

   Vi undersøger i øjeblikket dette spørgsmål.

2. 6. oktober 2026 kl. 11.59 UTCinvestigating

   Vi fortsætter med at undersøge dette spørgsmål.

3. 6. oktober 2026 kl. 12.24 UTCidentified

   Spørgsmålet er blevet identificeret, og et fix er ved at blive gennemført.

4. 6. oktober 2026 kl. 16.21 UTCresolved

   Denne hændelse er blevet løst.

5. 9. oktober 2026 kl. 18.48 UTCpostmortem

   # # Summary På * * Tirsdag, 6 oktober 2026 * *, IaCM rørledninger, der bruger * * OpenTofu plugin * * i * * Prod1 * * mislykkedes periodisk for en produktionskonto Påvirkede kører injicerede hemmeligheder med succes, derefter senere trin timet ud eller mislykkedes godkendelse. Den samme rørledning lykkedes ofte at prøve igen, uden nogen konfigurationsændring. Typiske fejlslagne henrettelser løb i omkring 90 minutter. Andre Harness-moduler var ikke stort set påvirket. Vi har ingen rapport om tab af kundedata. Pipelines, der sluttede inde i token levetid var upåvirket af denne defekt. # Root Cause De IaCM trin minted godkendelse tokens, der udløb efter en time. Politikkontroller senere på lang sigt så afvist token, så trin timet ud eller mislykkedes godkendelse. At en time levetid blev rettet. Løber på omkring 90 minutter krydsede en-time mærket, hvilket er grunden til fiaskoerne dukkede op på længere rørledninger og ofte ryddet på en kortere gentry. Et separat sæt af planfejl på den samme konto kom fra kreditmæssig setup i kundens arbejdsplads og er uden for denne hændelse. # Impact * * * Produktområde: * * IaCM rørledninger ved hjælp af IaCM plugins taler med OPA sdk. * * * Kundeoplevelse: * * intermitterende timeouts og autentificering svigt efter hemmelig injektion, på kører længere end omkring en time. * * * Miljø: * * Prod1, én produktionskonto * * * Data: * * Ingen datatab rapporteret. Name # Respiration * * * Øjeblikkelig: * * Åbnede en status side for den berørte Prod1-konto, og sendte en midlertidig IaCM manager ændring for en klasse af de observerede fejl, mens plugin fix blev bygget. * * * Fast: * * Smed en OpenTofu plugin hotfix så token udløb er konfigurerbar. I produktionen blev levetiden hævet til omkring 6 timer, så en lang rørledning ikke overleve token. Hotfix blev valideret i QA og sendt til Prod1. Vi undskylder forstyrrelsen. Kontakt venligst din Harness-støttekontakt, hvis du har yderligere spørgsmål.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 5. oktober 2026 kl. 22.01 UTCinvestigating

   Vi undersøger i øjeblikket dette spørgsmål.

2. 5. oktober 2026 kl. 23.50 UTCidentified

   Spørgsmålet er blevet identificeret, og et fix er ved at blive gennemført.

3. 6. oktober 2026 kl. 00.26 UTCmonitoring

   Et fix er blevet gennemført, og vi overvåger resultaterne.

4. 6. oktober 2026 kl. 00.26 UTCmonitoring

   Vi fortsætter med at overvåge for yderligere spørgsmål.

5. 6. oktober 2026 kl. 00.39 UTCresolved

   Verificerede fix og løst SSO spørgsmål.

6. 9. oktober 2026 kl. 16.17 UTCpostmortem

   # # Okta Application SP- Initiated SSO Login Failures Name # Summary Name Mellem 5. oktober 2026, 18: 18 UTC og 6. oktober 2026, 00: 26 UTC, var nogle Harness kunder ude af stand til at logge ind på Harness Hosted MCP server via SAML Single Sign-On\ (SSO\). Den vigtigste Harness Portal brugergodkendelse forblev fuldt operationel. Berørte brugere så login fejl eller blev omdirigeret til en ugyldig SSO side i stedet for at udfylde sign-in. Name Problemet var forårsaget af at bryde ændringer i en version opgradering af Harness identitet service Harnessid. Vi rettede det med en række hotfixes, og SSO login blev fuldt restaureret for alle berørte kunder. Name # Impact Name Brugere, der meldte sig til Harness MCP via SAML SSO, var ude af stand til at fuldføre autentificeringen. Eksisterende MCP-sessioner, der var baseret på SSO kunne ikke genopfriskes, så nogle brugere var nødt til at logge ind igen og kunne ikke. Ikke-SSO logins til Hosted MCP arbejdede under det meste af hændelsen. Ingen kundedata blev tabt eller afsløret. Kunder, der bruger deres egen generiske SAPL 2.0 applikationskonfiguration i Okta, blev ikke påvirket. "Root Cause Den 29. september 2026 blev en opdateret version af Harness-applikationen offentliggjort i Okta Integration Network. Opdateringen tilføjet støtte til registrering af flere svar\ (ACS\) URL 'er, så kunder, der kører Harness på tværs af flere regioner eller miljøer kunne konfigurere mere end én callback URL. Name Hårdhed omfatter en AssertionConsumerServiceURL-værdi i SAML- godkendelsesanmodningen, som den sender til Okta. Før denne opdatering, Okta ikke validere denne værdi for applikationsinstanser uden yderligere ACS URL 'er konfigureret og i stedet returnerede SAML påstand til programmets standard ACS URL. Efter opdateringen, blev denne validering aktiv på tværs af alle eksisterende applikationsinstanser, herunder dem, hvor kunden aldrig havde konfigureret en yderligere ACS URL. Da den ønskede værdi ikke var til stede i instansens registrerede liste, Otta returnerede en HTTP 400 fejl. Name Den opdaterede ansøgning gik gennem Oktas standard OIN udgivelse gennemgang, som omfatter backward- kompatibilitet kontrol mod eksisterende anlæg af den offentliggjorte integration. Denne ændring i validering adfærd for tilfælde med ingen yderligere ACS URL 'er konfigureret var ikke dukket op under denne gennemgang, så det nåede kunderne på tidspunktet for udgivelsen. # Respiration * * Øjeblikkelig respons * * Name To workarounds blev offentliggjort på statussiden: logge ind fra Harness flise i Okta\ (IdP-initieret login\), som var upåvirket, eller registrere ansøgningen er Okta SSO URL i den ekstra ACS URL-felt af Harness Okta ansøgning. Harness engagerede hver rapporteret berørte kunde direkte og validerede deres sign-in. Name * * Opløsning * * Name Rullende programmet tilbage til den tidligere version blev bevidst undgået, da det ville kun udsætte den samme afbrydelse til den næste udgivelse. Hver berørt kunde blev i stedet frigjort gennem ACS URL registrering, og vi arbejder med Okta at gøre ACS URL validering igen, så tilfælde med ingen yderligere ACS URL 'er konfigureret opfører sig præcis som de gjorde før, og ingen kunde handling er påkrævet. # Action Punkter For at forhindre sådanne spørgsmål i at ske igen, vil Harness tage følgende handling elementer Name 1. Arbejde med Okta at genoprette betinget ACS URL validering, så tilfælde med ingen yderligere ACS URL 'er konfigureret opføre sig præcis som før, og ingen kunde handling er påkrævet. 2. Udgiv en dedikeret konfiguration guide til Harness OIN ansøgning i Harness dokumentation, herunder svar\ (ACS\) URL krav. 3. Tilføj en uafhængig præ-release verificering trin mod eksisterende kundekonfigurationer for enhver fremtidig opdatering til den offentliggjorte Okta ansøgning, sammen med Okta egen gennemgang. 4. Migrer brugergodkendelse til Harness ID, som fjerner afhængigheden af denne validering adfærd helt.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 29. september 2026 kl. 20.31 UTCinvestigating

   Vi undersøger i øjeblikket dette spørgsmål.

2. 29. september 2026 kl. 20.31 UTCidentified

   Spørgsmålet er blevet identificeret, og et fix er ved at blive gennemført.

3. 29. september 2026 kl. 20.57 UTCidentified

   Vi identificerede et problem, der kun gælder for SP- initieret login gennem den offentliggjorte Harness Otta ansøgning. Efter en nylig opdatering til dette program, disse login forsøg returneret en HTTP 400 fejl, når den konfigurerede SSO URL manglede fra yderligere ACS URL 'er. General SAML 2.0 konfigurationer i Otta påvirkes ikke. Øjeblikkelig opløsning: Brug IDP- initieret login. Start login fra Harness ansøgning flise i Otta. Eller Tilføj din Harness SSO URL til yderligere ACS URL 'er i den offentliggjorte Harness Okta ansøgning.

4. 2. oktober 2026 kl. 00.33 UTCresolved

   Denne hændelse er blevet løst.

5. 7. oktober 2026 kl. 18.30 UTCpostmortem

   # 1. Oversigt Fra september 29, 2026, kunder, der logger ind på Harness gennem den offentliggjorte Harness ansøgning i Okta Integration Network\ (OIN\) var ude af stand til at fuldføre SP- initierede SSO login. Berørte brugere modtog en HTTP 400 fejl fra Okta i stedet for at blive logget ind. Spørgsmålet blev indført ved en ændring i, hvordan Otta validerede den ønskede svar\ (ACS\) URL for eksisterende installationer i den offentliggjorte Harness ansøgning. Workarounds blev offentliggjort inden for en time efter den første rapport, og alle berørte kunder blev frigjort. # 2. Impact Name * Indvirkningen var begrænset til kunder, der bruger den offentliggjorte Harness ansøgning fra Okta Integration Network for SP- initieret login\ (starter sign-in fra Harness\). Disse forsøg returnerede en HTTP 400 fejl fra Otta. * IdP-initieret login, startede fra Harness flise i Okta, fortsatte med at arbejde i hele. * Kunder, der bruger deres egen generiske SAML 2.0 applikationskonfiguration i Okta blev ikke påvirket. * Ingen kundedata blev tabt eller afsløret. # 3. Rodårsag Den 29. september 2026 blev en opdateret version af Harness-applikationen offentliggjort i Okta Integration Network. Opdateringen tilføjet støtte til registrering af flere svar\ (ACS\) URL 'er, så kunder, der kører Harness på tværs af flere regioner eller miljøer kunne konfigurere mere end én callback URL. Hårdhed omfatter en AssertionConsumerServiceURL-værdi i SAML- godkendelsesanmodningen, som den sender til Okta. Før denne opdatering, Okta ikke validere denne værdi for ansøgning tilfælde, der ikke havde nogen yderligere ACS URL 'er konfigureret, og blot returneret SAML påstand til programmets standard ACS URL. Efter opdateringen, blev denne validering aktiv på alle eksisterende tilfælde af programmet, herunder dem, hvor kunden aldrig havde konfigureret en yderligere ACS URL. Da den ønskede værdi ikke var til stede i instansens registrerede liste, Okta afvist autentificering anmodning med en HTTP 400 fejl. Den opdaterede ansøgning gik gennem Oktas standard OIN udgivelse gennemgang, som omfatter baglæns kompatibilitet kontrol mod eksisterende installationer af en offentliggjort integration. Denne ændring i validering adfærd for tilfælde med ingen yderligere ACS URL 'er konfigureret var ikke dukket op i løbet af denne anmeldelse, så det nåede kunderne ved udgivelse. # 4. Respiration * * Øjeblikkelig respons * * To workarounds blev offentliggjort på statussiden: logge ind fra Harness flise i Okta\ (IdP-initieret login\), som var upåvirket; eller registrere ansøgningen er Okta SSO URL i den ekstra ACS URL-felt af Harness Okta ansøgning. Støtte engageret hver berørt kunde direkte og valideret sign-in med dem. Name * * Opløsning * * Rullende programmet tilbage til den tidligere version blev bevidst undgået, da det ville kun udsætte den samme afbrydelse til den næste udgivelse. Hver berørt kunde blev i stedet frigjort gennem ACS URL registrering, og vi arbejder med Okta at gøre ACS URL validering igen, så tilfælde med ingen yderligere ACS URL 'er konfigureret opfører sig præcis som de gjorde før, og ingen kunde handling er påkrævet. # 5. Aktionsposter For at forhindre, at sådanne spørgsmål opstår igen, arbejder vi på * * * * * * * ECB 's Styrelsesråd Name; Note 124; Udgiv en dedikeret konfiguration guide til Harness OIN ansøgning i Harness dokumentation, herunder svar\ (ACS\) URL krav. Note 124; Tilføj en uafhængig pre- release verification trin mod eksisterende kundekonfigurationer for enhver fremtidig opdatering til den offentliggjorte Okta ansøgning, sammen med Okta egen gennemgang. ; Migrér brugergodkendelse til Harness ID, som fjerner afhængigheden af denne validering adfærd helt.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 29. september 2026 kl. 18.45 UTCinvestigating

   Vi undersøger i øjeblikket dette spørgsmål.

2. 29. september 2026 kl. 21.55 UTCmonitoring

   Et fix er blevet gennemført, og vi overvåger resultaterne.

3. 29. september 2026 kl. 22.01 UTCresolved

   Denne hændelse er blevet løst.

4. 2. oktober 2026 kl. 22.40 UTCpostmortem

   # # # Oversigt Mellem ca. * * 11: 37 AM og 3: 01 PM PDT\ (18: 37- 22: 01 UTC\) den 29. september 2026 * *, kunder, der bruger Harness CI selv-hostede Linux cloud løbere i * * prod1 / prod2\ (us- west1\) * * oplevede intermitterende netværkssvigt under udførelse af rørledninger - primært Git / netværk timeouts når du henter kildekode. * * Rodårsag * * Dette skyldtes primært mætning af vores NAT, som blev yderligere forværret af en midlertidig cloud-udbyder beregne kapacitet, der forhindrer nye VM levering der. # # Impact * Kunder, der kører selv-hostede Linux CI bygger i us-west1 sav * * intermitterende bygge / rørledning svigt * *, ikke en fuld udfald. * Observerede customer-vender fejl inkluderet Git hente timeouts, fx 'Kunne ikke oprette forbindelse til github.com port 443: Tilslutning timet ud' * * genoptræning * * * * * Øjeblikkelig: * * Rebalanceret ARM build- VM belastning fra mættet us- west1 sti mod centrum 1\ (delvist begrænset af central 1 kapacitet\); genstartet de berørte Cloud NAT gateways, som stabiliserede rørledningsnetværk. * * Aktionsposter * * 1. Sikre yderligere NAT gateway / IP kapacitet\ (i gang\) 2. Forbedre NAT mætning detektion og varsling forud for kundens indvirkning. 3. Evaluere cross-region kapacitet uforudsete så en enkelt regions computermangel ikke blokere failover afbødning.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 29. september 2026 kl. 14.41 UTCinvestigating

   Vi undersøger i øjeblikket dette spørgsmål.

2. 29. september 2026 kl. 15.54 UTCmonitoring

   Et fix er blevet gennemført, og vi overvåger resultaterne.

3. 29. september 2026 kl. 15.57 UTCmonitoring

   Vi fortsætter med at overvåge for yderligere spørgsmål.

4. 29. september 2026 kl. 18.49 UTCresolved

   Denne hændelse er blevet løst.

5. 2. oktober 2026 kl. 05.37 UTCpostmortem

   * * Oversigt * * Kunder på Prod-2 oplevede forhøjede fejlrater i kontinuerlige verifikationsrørledninger. Verifikation job mislykkedes at fuldføre eller rapporterede fejl, fordi CV dataindsamling arbejdere ikke kunne kommunikere med den platform service, der koordinerer deres arbejde. Dette skyldtes en uventet trafikstigning til et af vores bagende systemer. Tjenesten blev genoprettet ved at skalere den berørte platform komponent. Ingen tab af data eller korruption opstod. Name * * Kundeeffekt * * Kunder, der bruger Kontinuerlig Verifikation på Prod-2 så verifikation rørledning job mislykkes eller tid ud under hændelsesvinduet. En betydelig brøkdel af de verifikationsaktiviteter, der blev gennemført i denne periode, endte med en operationel fiasko. Rørledninger, der ikke bruger CV, fortsatte med at fungere normalt. Name * * Rodårsag * * En stor automatiseret levering løb skabt et betydeligt antal vedvarende CV overvågning arbejdstagere i et kort vindue, som overvældede en fælles platform komponent. Den pludselige stigning i samtidige udgående opkald udtømt de tilgængelige netværksforbindelser på hver service instans. Name * * Mitigation * * Den maksimale skaleringsgrænse for cv-tjenesten blev hævet, så den kunne udvide kapaciteten til at imødekomme efterspørgslen. Fejl stoppede kort efter scale- out blev afsluttet. Name * * Næste skridt * * For at forhindre gentagelse, vil Harness: * * * Øge kapaciteten headroom og tilføje proviant guardrails: * * Øge cv service skalering grænse for at opretholde headroom under sprængbelastning, og indføre sats begrænsning for bulk levering af overvågede tjenester. * * * Forbedre Resistens: * * Tilføj eksponentiel backoff og jitter til arbejderen reles, og brug en genanvendelig forbindelse pulje til at reducere overhead og forhindre forbigående svigt fra compounding under høj koncurrency. * * * Forbedre overvågning og varsling: * * Forbedre varsling om unormale per-account arbejdstager vækstrater, så lignende betingelser er opdaget og handlet på tidligere.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 29. september 2026 kl. 13.12 UTCresolved

   Den 28. september 2026, vi observeret et problem med kopiering af filer fra Harness Filestore under eksport trin, hvor filerne blev kopieret som null / tomme filer. Som følge heraf blev alle rørledninger ved hjælp af Filestore API 'er blokeret under hændelsesvinduet. Problemet blev forårsaget på grund af en Feature Flag udrulning, som blev vendt tilbage, når problemet blev opdaget. Alle operationer er normale igen.

2. 1. oktober 2026 kl. 17.28 UTCpostmortem

   # # # Oversigt Den 28. september 2026, nogle kunder på Prod-2 oplevet svigt i CD-rørledninger trin, der læser File Store indhold ved hjælp af rørledningsudtryk\ (f.eks ''\). Berørte udtryk returneret null i stedet for det forventede filindhold, hvilket forårsager afhængige trin til at mislykkes eller opføre sig forkert. Spørgsmålet blev sporet til en platform opdatering, der strammede godkendelse kontrol på File Store API 'er. Opdateringen blev rullet tilbage, og File Store udtryk har fungeret normalt siden. Kundeeffekt * Kun pipeline trin på Prod-2, der læser File Store indhold via udtryk blev påvirket. Pipelines, der ikke bruger Fil Store udtryk, blev ikke påvirket. * Berørte udtryk løst til null, forårsager trin, der afhænger af konfiguration eller indstillinger filer til at mislykkes eller producere forkert output. * Intet fillager indhold blev ændret. Ingen filer, hemmeligheder, legitimation eller artefakter blev afsløret, og ingen data blev tabt. # # Root Cause Som en del af et igangværende sikkerhedsinitiativ, Harness indsat strengere godkendelse kontrol på tværs af flere platform API 'er, herunder API, der tjener File Store indhold. Når en rørledning evaluerer et fillager udtryk, en intern Harness service kalder en anden for at hente filen. Den nye godkendelseskontrol mislykkedes, hvilket resulterede i, at anmodningerne blev afvist, og at udtrykkene returnerede nul. # # Mitigation Når platformen opdatering blev identificeret som årsagen, blev det rullet tilbage på tværs af produktionsmiljøet. File Store udtryk har løst korrekt siden rollback. Der kræves ingen handling fra kundens side. # # Forebyggende foranstaltninger & næste skridt * * * Revision påvirket API 'er: * * Gennemgå alle API' er, hvor den strengere godkendelseskontrol blev anvendt for at sikre, at interne service- til-service opkald er korrekt beskrevet. * * * Forbedre testdækningen: * * Forbedre automatiserede test suiter til at omfatte File Store ekspressionsevaluering på tværs af rørledninger udførelse stier

Automatisk oversat fra den officielle hændelsesopdatering.

1. 23. september 2026 kl. 20.17 UTCinvestigating

   Vi er i øjeblikket ved at undersøge konnektivitet problemer påvirker kunder, hvis miljøer er beskyttet af Palo Alto Networks firewalls. Disse firewalls blokerer forbindelser til Harness API 'er, hvilket kan resultere i: - Mislykkede henrettelser af rørledninger - Manglende evne til at implementere applikationer - Intermitterende timeouts, når adgang Harness platform funktioner - Integrationssvigt med tredjeparts-værktøjer - Delegere forbindelse med Harness platform Dette spørgsmål er ikke forårsaget af en Harness service afbrydelse, men snarere af firewall regler på din netværksside. Vi rådgiver kunderne om at gøre en undtagelse for vores DNS endepunkter.

2. 24. september 2026 kl. 08.43 UTCmonitoring

   Mitigation til rådighed: Harness Traffic Blocked by Network Security Policy Vi har identificeret et problem, hvor nogle kunder kan være ude af stand til at få adgang til Harness, fordi Harness trafik bliver kategoriseret som "AI- Platform" af Palo Alto netværk sikkerhedskontrol og efterfølgende blokeret af kundens firewall / INET politik. Hvis du oplever dette problem: Kontakt din organisations Network / Firewall / CyberSecurity team og bed om, at den krævede Harness trafik er tilladt gennem din Palo Alto firewall politik. Som en afbødning, kan kunderne tillade "AI- Platform" URL-kategori for de krævede Harness endepunkter, eller tilføje de berørte Harness domæner / FQDNs til deres organisations godkendte / tillad liste, i overensstemmelse med deres sikkerhedspolitik. Når firewall-politikken er opdateret, bør adgangen til Harness genoprettes. Vigtigt: Firewall politik forvaltes af kundens netværk / sikkerhed team. Hvis Harness endpoint er forkert kategoriseret af Palo Alto, kan kunderne også anmode om en URL- kategori gennemgang fra Palo Alto Networks.

3. 25. september 2026 kl. 17.10 UTCresolved

   Efter høring af Palo Alto Networks, kan vi bekræfte, at den 23. september 2026, app.harness. io blev kategoriseret som en AI Platform Service af Palo Alto Networks Team. Palo Alto Networks sendte i august en meddelelse til kunderne om omklassificeringen. Denne ændring kan placere AI Platform Service under en anden politik end app.harness. io 's tidligere regelsæt kategorisering, Computer og Internet Info. Den anvendte politik er afhængig af kundeindstillinger. Harness Kunder bør diskutere denne kategorisering og de advarsler med deres interne netværk team og Palo Alto Networks.

4. 13. oktober 2026 kl. 04.50 UTCpostmortem

   .

Automatisk oversat fra den officielle hændelsesopdatering.

1. 22. september 2026 kl. 16.40 UTCinvestigating

   Vi undersøger i øjeblikket dette spørgsmål.

2. 22. september 2026 kl. 17.14 UTCidentified

   Spørgsmålet er blevet identificeret, og et fix er ved at blive gennemført.

3. 22. september 2026 kl. 18.01 UTCmonitoring

   Et fix er blevet gennemført, og vi overvåger resultaterne.

4. 22. september 2026 kl. 18.38 UTCresolved

   Denne hændelse er blevet løst.

5. 2. oktober 2026 kl. 22.05 UTCpostmortem

   # Summary Den 22. september 2026, tre af vores udgående netværk gateways i en region blev usund og begyndte at afvise en lille procentdel af nye udgående tilslutningsforsøg. Spørgsmålet blev løst samme dag problem helt uden yderligere gentagelse eller følger-på virkning. Den underliggende årsag var en mættet intern handel-overvågning buffer på disse gateways, hvilket fik deres sundhedstjek til at reagere for langsomt og få mærket usund. # Impact * Kun tre gateway-instanser i en region blev berørt; andre regioner og andre gateways i samme region blev ikke påvirket. * Der var ingen cascading fiasko, spørgsmålet blev helt løst med en enkelt runde af gateway genstarter, og ingen følges- om spørgsmål opstod bagefter. "Root Cause Vores outbound netværk gateways kører en intern komponent, der overvåger netværkstrafikken for operationel synlighed. Under vedvarende høj trafik, blev denne komponents interne buffer mættet, hvilket skabte modtryk alvorligt nok til at bremse gateways egen sundhedstjek svar ud over den timeout vores belastning balancer tillader. Når timeout blev overskredet, den belastning balancer markeret de berørte gateways usunde og begyndte at afvise en del af nye forbindelser bestemt for dem. Den faktiske pakkeforsendelse fortsatte med at fungere normalt under hele hændelsen. Det var specifikt et spørgsmål om sundhedstjek og overvågning af buffer, ikke en fiasko for gateways 'kerne videresendelse. Opløsning De tre berørte gateway-instanser blev manuelt genstartet, som ryddet den mættede overvågning buffer og straks genoprettet normal sundhed-check adfærd. Forbindelsesafvisninger stoppede så snart genstart afsluttet, og der var ikke behov for yderligere indgriben. # Forebyggende handlinger 124; * * Aktion * * ECB 's Styrelsesråd 1.124; Erstat den nuværende traffic- monitoring metode på alle gateways med en mere effektiv, lavere overhead implementering, der ikke kan mættes på denne måde, og som advarer længe før nogen customer-synlig effekt. ; Implementere automatisk, periodisk udskiftning af langløbende gateway-instanser på en fast tidsplan, så ingen tilfælde kan akkumulere den form for aldersrelateret nedbrydning set i denne hændelse.; 124; Migrate gateway-instanser til netværk-optimeret infrastruktur med væsentligt mere dedikeret netværkskapacitet, bedre egnet til vedvarende høj gennemstrømning trafik. ; Forbedre eksisterende overvågning buffer udnyttelse, mens den langsigtede udskiftning er rullet ud. ; Forbedre alarmering specifikt på gateway-check respons latency, at fange tidlige tegn på nedbrydning, før det bliver bruger- synlige.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 22. september 2026 kl. 14.00 UTCidentified

   Spørgsmålet er blevet identificeret, og et fix er ved at blive gennemført.

2. 22. september 2026 kl. 14.08 UTCmonitoring

   Et fix er blevet gennemført, og vi overvåger resultaterne.

3. 22. september 2026 kl. 14.20 UTCresolved

   Denne hændelse er blevet løst.

4. 2. oktober 2026 kl. 22.10 UTCpostmortem

   Samme som den foregående rod årsag.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 21. september 2026 kl. 16.39 UTCinvestigating

   Vi undersøger i øjeblikket dette spørgsmål.

2. 21. september 2026 kl. 17.12 UTCidentified

   Spørgsmålet er blevet identificeret, og et fix er ved at blive gennemført.

3. 21. september 2026 kl. 18.27 UTCmonitoring

   Et fix er blevet gennemført, og vi overvåger resultaterne.

4. 21. september 2026 kl. 18.33 UTCresolved

   Denne hændelse er blevet løst.

5. 29. september 2026 kl. 22.39 UTCpostmortem

   # # Summary Den 21. september 2026, kunder i Prod 2 oplevede nedbrudt og derefter stort set ikke tilgængelig implementering dashboards i omkring tre timer. Spørgsmålet var forårsaget af et sæt af analytics spørgsmål bag disse dashboards læse langt flere data, end de havde brug for, som udtømt kapaciteten i databasen betjener dem. En rullende genstart af den berørte tjeneste restaurerede dashboards fuldt ud, og platformen har været stabil siden. # Customer Impact Dashboard sider indlæses langsomt eller timet ud mellem 14: 48 og 18: 11 UTC. Pipeline udførelse og implementering registrering kører på separat infrastruktur og fortsatte med at fungere normalt. Ingen tab af data eller korruption opstod. # Root Cause De dashboard forespørgsler manglede et tidsinterval filter på kolonnen bruges til at opdele den største tabel i ugentlige segmenter, så hver forespørgsel læse alle historiske data i stedet for kun den ønskede periode. Korrekthed blev aldrig påvirket - dashboards returnerede de rigtige resultater; kun mængden af data læst for at producere dem var overdreven. Da datamængden steg, oversteg omkostningerne til disse læsninger, hvad databasen kunne tjene, og de svigtende forespørgsler tilføjede yderligere belastning, så betingelsen ikke klart, før tjenesten blev genstartet. # Mitigation * Udført en rullende genstart af den berørte tjeneste, som stoppede retry cyklus og tillod databasen at fuldføre sit fremragende arbejde * Bekræftet dashboard latency og database forbindelse brug returneret til normale niveauer # Next Steps For at forhindre gentagelse, vil Harness: * Tilføj det manglende tidsinterval filter til de berørte dashboard forespørgsler, så hver læser kun den ønskede periode * Erstat øjeblikkelig forsøg med afgrænset, backing- off forsøg * Forbedre detektion ved at tilføje alarmering på databaseforbindelse brug og per- forespørgsel udførelse omkostninger

Automatisk oversat fra den officielle hændelsesopdatering.