Cronologia delle interruzioni di Split

1. 27 ottobre 2026 alle ore 19:52 UTCinvestigating

   Stiamo attualmente indagando su questo problema.

2. 27 ottobre 2026 alle ore 19:58 UTCinvestigating

   Le tubazioni CI sull'infrastruttura VM stanno fallendo alla fase di inizializzazione perché il compito va ad un delegato al di fuori del pool previsto

3. 27 ottobre 2026 alle ore 21:15 UTCidentified

   Il problema è stato identificato e si sta attuando una correzione.

4. 27 ottobre 2026 alle ore 22:16 UTCmonitoring

   Una soluzione è stata implementata e stiamo monitorando i risultati.

5. 27 ottobre 2026 alle ore 22:24 UTCresolved

   Questo incidente è stato risolto.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 19 ottobre 2026 alle ore 07:46 UTCinvestigating

   Stiamo attualmente indagando su questo problema.

2. 19 ottobre 2026 alle ore 08:02 UTCidentified

   Il problema è stato identificato e si sta attuando una correzione.

3. 19 ottobre 2026 alle ore 08:04 UTCmonitoring

   Una soluzione è stata implementata e stiamo monitorando i risultati.

4. 19 ottobre 2026 alle ore 08:21 UTCresolved

   Questo incidente è stato risolto.

5. 23 ottobre 2026 alle ore 18:21 UTCpostmortem

   # Summary # Il 19 ottobre 2026, tra circa 12:10 AM e 12:55 AM PDT, i clienti su Prod4 hanno sperimentato errori e indisponibilità intermittente dei servizi Harness Pipelines. Le esecuzioni di pipeline pesanti hanno portato un forte aumento dell'utilizzo della CPU e della memoria sul servizio pipeline, e per un breve periodo tutte le istanze di servizio non erano disponibili. L'ingegneria di cablaggio ha scalato il servizio sia verticalmente che orizzontalmente, che il servizio restaurato. Una soluzione per il comportamento sottostante è in fase di lancio. ♪#Root Cause ♪ Il 19 ottobre, l'elevato numero di esecuzioni con grafici di esecuzione molto grandi ha portato un forte aumento delle risorse di cluster. Il servizio memorizza e recupera questo grafo di esecuzione completo per scopi di visualizzazione e ulteriore avanzamento delle tubazioni verso i prossimi stati. I nostri autoscalatori su Prod4 hanno richiesto più tempo del solito per le risorse di scaling a causa di un forte aumento della CPU e della memoria. Come parte della correzione, l'aggiornamento del grafico di esecuzione ora processerà le modifiche del grafico in modo incrementale invece del grafico completo. Si sta facendo rotolare fuori in modo graduale e sarà completamente rotolato fuori al più presto. # * Utenti interessati: Clienti su Prod4. * Sintomo: indisponibilità della funzionalità pipeline nella piattaforma Harness. * Dati: Nessuna perdita di dati. * Funzionamento consigliato: Non richiesto dai clienti. L'ingegneria delle armi ha risolto il problema. * Durata dell'impatto: circa 20 minuti di piena indisponibilità e prestazioni degradate per 25 minuti. Harness ha continuato il monitoraggio dopo il recupero e la stabilità della piattaforma confermata con i clienti. Revisione: Immediate. L'ingegneria delle armi ha scalato il servizio pipeline sia verticalmente \(più risorse per istanza\) sia orizzontalmente \(più istanze\), sia rimosso istanze in uno stato malsano. Il conteggio delle istanze stabilizzato e il servizio normale è stato ripristinato. Il sistema rimarrà scalato fino a quando la correzione è completamente arrotolato. **Atti permanenti e oggetti d'azione** Per evitare che tali problemi accadano di nuovo, Harness è 1. Tuning il processo di guarigione/scaling automatico in modo che l'impatto è mimimale a nessuno. 2. Ottimizzazione del flusso del grafico di esecuzione in modo che i grandi grafici possano essere processati più velocemente.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 15 ottobre 2026 alle ore 10:10 UTCinvestigating

   Stiamo attualmente indagando su questo problema.

2. 15 ottobre 2026 alle ore 10:10 UTCidentified

   Il problema è stato identificato e si sta attuando una correzione.

3. 15 ottobre 2026 alle ore 10:27 UTCresolved

   Questo incidente è stato risolto.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 15 ottobre 2026 alle ore 08:04 UTCinvestigating

   Stiamo attualmente indagando su questo problema.

2. 15 ottobre 2026 alle ore 08:05 UTCidentified

   Il problema è stato identificato e si sta attuando una correzione.

3. 15 ottobre 2026 alle ore 08:09 UTCmonitoring

   Una soluzione è stata implementata e stiamo monitorando i risultati.

4. 15 ottobre 2026 alle ore 08:15 UTCresolved

   Questo incidente è stato risolto.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 13 ottobre 2026 alle ore 01:06 UTCinvestigating

   Stiamo attualmente indagando su questo problema.

2. 13 ottobre 2026 alle ore 01:07 UTCidentified

   Il problema è stato identificato e si sta attuando una correzione.

3. 13 ottobre 2026 alle ore 01:56 UTCmonitoring

   Una soluzione è stata implementata e stiamo monitorando i risultati.

4. 13 ottobre 2026 alle ore 04:29 UTCresolved

   Questo incidente è stato risolto.

5. 23 ottobre 2026 alle ore 03:16 UTCpostmortem

   . .

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 12 ottobre 2026 alle ore 15:25 UTCinvestigating

   Attualmente stiamo sperimentando errori HTTP 429 (limita-tasso) quando Harness Cloud costruisce l'accesso a Maven Central, che possono influenzare l'esecuzione. Il nostro team sta lavorando attivamente con Sonatype per risolvere il problema il più velocemente possibile. Forniamo ulteriori aggiornamenti mentre facciamo progressi.

2. 12 ottobre 2026 alle ore 19:31 UTCresolved

   Questo incidente è stato risolto.

3. 23 ottobre 2026 alle ore 03:06 UTCpostmortem

   tldr: \(C'è stato un breve tasso limitato dal centro del fondo\) Maggiori dettagli da seguire

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 8 ottobre 2026 alle ore 10:23 UTCmonitoring

   Una soluzione è stata implementata e stiamo monitorando i risultati.

2. 8 ottobre 2026 alle ore 10:53 UTCresolved

   Questo incidente è stato risolto.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 6 ottobre 2026 alle ore 21:46 UTCinvestigating

   Stiamo attualmente indagando su questo problema.

2. 6 ottobre 2026 alle ore 21:47 UTCinvestigating

   Stiamo continuando a indagare su questo problema.

3. 6 ottobre 2026 alle ore 22:03 UTCidentified

   Il problema è stato identificato e si sta attuando una correzione.

4. 6 ottobre 2026 alle ore 22:30 UTCmonitoring

   Una soluzione è stata implementata e stiamo monitorando i risultati.

5. 6 ottobre 2026 alle ore 22:30 UTCmonitoring

   Una soluzione è stata implementata e stiamo monitorando i risultati. abbiamo la conferma di questo che fissa il problema.

6. 6 ottobre 2026 alle ore 22:44 UTCresolved

   Questo incidente è stato risolto.

7. 23 ottobre 2026 alle ore 02:12 UTCpostmortem

   # 1. Sommario Il 6 ottobre 2026, le tubazioni contenenti una fase IaCM non sono state in grado di iniziare su Prod1 per circa due ore. Gli utenti interessati hanno visto un errore quando la pipeline ha tentato di creare il suo piano di esecuzione. Le tubature che non hanno usato una fase IaCM hanno continuato a funzionare normalmente durante tutto. La causa di fondo era un difetto di registrazione interno nel servizio che gestisce l'esecuzione della fase IaCM: in una condizione di tempismo specifico e raro, che il proprio sistema di registrazione del servizio potrebbe finire in attesa su se stesso indefinitamente, che a sua volta ha bloccato il processo più ampio responsabile per la preparazione dei piani di esecuzione pipeline. Il problema è stato innescato da un'insolitamente grande scoppio di attività di registro da una pipeline del cliente. Abbiamo risolto l'impatto immediato spostando il servizio alla sua versione stabile precedente, e un codice fisso permanente è attualmente in prova. # 2. Impatto * Tutti i gasdotti che utilizzano una fase IaCM su Prod1 non sono stati in grado di iniziare per circa due ore. * I clienti multipli sul cluster Prod1 sono stati colpiti. * Le tubature che non hanno utilizzato uno stadio IaCM non sono state influenzate e hanno continuato a funzionare normalmente. * Nessun dato è stato perso a seguito di questo incidente. * Come effetto collaterale del rollback utilizzato per risolvere questo incidente, una correzione non correlata per un cliente \(a seconda di quanto tempo un determinato token di autenticazione rimane valido durante le tubazioni di lungo periodo\) è stato temporaneamente reindirizzato. Quella soluzione e' stata riapplicata la stessa sera. # 3. Causa di radice Il servizio responsabile delle fasi della pipeline IaCM registra la sua attività attraverso una coda interna: i messaggi di registro sono posizionati sulla coda, e un singolo lavoratore di sfondo legge continuamente da esso e scrive i messaggi fuori. Separatamente, quel servizio ha un filtro che può riscrivere la gravità di alcuni messaggi di log di nuovo su quella stessa coda. In una condizione di temporizzazione specifica, stretta, questo ha creato un deadlock, se la coda è capitato di essere completamente piena al momento esatto un messaggio riscritto è stato inviato indietro su di esso, l'unico lavoratore responsabile per liberare spazio sulla coda si sarebbe bloccato in attesa di spazio per liberarsi, una condizione che non potrebbe mai risolvere, poiché era l'unica cosa che avrebbe potuto liberare tale spazio. Una volta che è successo, ogni altra parte del servizio che ha avuto bisogno di registrare qualcosa anche è rimasto bloccato in attesa, che ha cascaded nel processo di tubazione-plan-creation in mancanza per qualsiasi pipeline utilizzando una fase IaCM. # 4. Risoluzione * Rolled il servizio alla sua ultima versione stabile, che ha risolto l'incidente immediato. # 5. Azioni preventive 1. **Ottimizzare il difetto sottostante**: Ottimizzare e sintonizzare il filtro di registrazione in modo che la riscrittura della gravità di un messaggio avvenga sul filo che ha generato la linea di log, piuttosto che essere rispedito attraverso la stessa coda del lavoratore di sfondo, eliminando completamente la condizione di deadlock. 2. ** Monitoraggio dell'Enhance sulla salute del logging-queue**: aggiungere metriche e allertare su questa coda interna in modo che questa classe di saturazione pagine il nostro team on-call automaticamente piuttosto che contare sui rapporti del cliente. 3. ** Valutare i limiti e eseguire test di stress elevati con condotte molto grandi**:

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 16 ottobre 2026 alle ore 10:41 UTCresolved

   Il 7 ottobre 2026, dalle 08:00 UTC alle 11:00 UTC (1:30 alle 16:30 PM IST), alcune esecuzioni pipeline sul cluster Prod 7 hanno visto fallimenti intermittenti nelle valutazioni passo Policy (OPA).

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 6 ottobre 2026 alle ore 12:54 UTCmonitoring

   Una soluzione è stata implementata e stiamo monitorando i risultati.

2. 6 ottobre 2026 alle ore 15:35 UTCresolved

   Questo incidente è stato risolto.

3. 10 ottobre 2026 alle ore 01:57 UTCpostmortem

   ## I clienti su Prod 2 hanno sperimentato guasti intermittenti di pochi passi Verifica all'avvio. I passi colpiti sono falliti poco dopo il lancio con un messaggio che indica la verifica continua\(CV\) non ha potuto raggiungere un servizio di Harness interno. Il problema è derivato da un recente aggiornamento di servizio che ha introdotto la connessione pooling per migliorare le prestazioni e l'affidabilità con un'impostazione mantenibile incompatibile con il timeout del servizio di ricezione. Nessun dato del cliente è stato perso o danneggiato. ### Customer Impact I clienti che utilizzano CV Verificare i passaggi su Prod-2 hanno visto guasti intermittenti durante la finestra incidente. Il tasso di fallimento era basso — la maggior parte delle esecuzioni completate con successo in tutta la finestra. Pipeline che non hanno usato CV Verifica passi non sono stati colpiti. ## Root Cause Un recente aggiornamento del servizio CV ha introdotto la connessione pooling a un componente della piattaforma interna, con una durata di mantenimento più lunga di quella timeout del componente. Le connessioni idle abbastanza a lungo sono state chiuse silenziosamente dal server; il servizio CV non ha rilevato questo e non ha avuto alcuna logica di riprovazione per tali guasti, causando loro di superficie direttamente come verifica guasti passo. Il problema è stato intermittente perché ha interessato solo le connessioni che è accaduto essere inattivo abbastanza a lungo per scadere. ### Mitigation La durata della connessione manten-alive è stata ridotta all'interno del timeout del servizio di ricezione. I fallimenti si sono avvicinati immediatamente allo zero e non sono stati osservati ulteriori fallimenti di questo tipo su qualsiasi ambiente di produzione. ## Prossimo passo Per prevenire la ricorrenza, Harness: *** Manutenzione della connessione Fix:** Ha sintonizzato il manten-alive predefinito e abilitato la riprovazione automatica sui guasti di connessione in modo che gli errori di stallo-connessione vengano maneggiati in modo trasparente. * *Add resilience at step start:** Introduce retry con backoff per la chiamata di servizio interno all'inizio del passo Verify, così i guasti transitori isolati non emergono come guasti passivi immediati. # Improva allerta' # Monitoraggio migliorato per i tassi di errore di connessione interna.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 6 ottobre 2026 alle ore 11:58 UTCinvestigating

   Stiamo attualmente indagando su questo problema.

2. 6 ottobre 2026 alle ore 11:59 UTCinvestigating

   Stiamo continuando a indagare su questo problema.

3. 6 ottobre 2026 alle ore 12:24 UTCidentified

   Il problema è stato identificato e si sta attuando una correzione.

4. 6 ottobre 2026 alle ore 16:21 UTCresolved

   Questo incidente è stato risolto.

5. 9 ottobre 2026 alle ore 18:48 UTCpostmortem

   # In **Tuesday, 6 ottobre 2026**, IaCM pipelines che utilizzano il plugin **OpenTofu** in **Prod1** fallito intermittentemente per un account di produzione. Lo stesso canale spesso è riuscito a riprovare, senza modifiche di configurazione. Le esecuzioni tipiche fallivano per circa 90 minuti. Altri moduli Harness non sono stati ampiamente influenzati. Non abbiamo alcun rapporto sulla perdita dei dati del cliente. Le tubature che hanno finito all'interno della vita token non sono state influenzate da questo difetto. # Causa radice # Le fasi IaCM hanno coniato i token di autenticazione che sono scaduti dopo un'ora. I controlli di policy più tardi in un lungo periodo poi hanno respinto il token, quindi il passaggio è scaduto o ha fallito l'autenticazione. Quella vita di un'ora e' stata fissata. Le corse di circa 90 minuti hanno attraversato il segno di un'ora, motivo per cui i fallimenti si sono presentati su tubazioni più lunghe e spesso sgomberati su una retry più breve. Un insieme separato di errori di piano nello stesso account è venuto dalla configurazione delle credenziali nello spazio di lavoro del cliente ed è al di fuori di questo incidente. ## Impact *** Area di produzione: * IaCM condutture utilizzando i plugin IaCM che parlano con OPA sdk. *** Esperienza di cliente:** timeout intermittenti e guasti di autenticazione dopo l'iniezione segreta, in esecuzione più di circa un'ora. * * Ambiente: * Prod1, un conto di produzione ♪Datas ♪ Nessuna perdita di dati riportata. ## Remediation # Immediate # Ha aperto una pagina di stato per l'account Prod1 interessato, e ha spedito un cambiamento intermedio IaCM manager per una classe dei guasti osservati mentre il plugin fix è stato costruito. # Permanente # Spedito un plugin OpenTofu hotfix così la scadenza token è configurabile. In produzione la vita è stata cresciuta a circa 6 ore, quindi una lunga pipeline non supera il token. Il hotfix è stato convalidato in QA e distribuito in Prod1. Ci scusiamo per il disturbo causato. Si prega di raggiungere il contatto di supporto Harness se avete ulteriori domande.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 5 ottobre 2026 alle ore 22:01 UTCinvestigating

   Stiamo attualmente indagando su questo problema.

2. 5 ottobre 2026 alle ore 23:50 UTCidentified

   Il problema è stato identificato e si sta attuando una correzione.

3. 6 ottobre 2026 alle ore 00:26 UTCmonitoring

   Una soluzione è stata implementata e stiamo monitorando i risultati.

4. 6 ottobre 2026 alle ore 00:26 UTCmonitoring

   Stiamo continuando a monitorare eventuali ulteriori problemi.

5. 6 ottobre 2026 alle ore 00:39 UTCresolved

   Verificato i problemi SSO risolti e risolti.

6. 9 ottobre 2026 alle ore 16:17 UTCpostmortem

   ## Okta Applicazione SP-Initiated SSO Login Errori # Sommario Tra il 5 ottobre 2026, 18:18 UTC e il 6 ottobre 2026, 00:26 UTC, alcuni clienti di Harness non sono stati in grado di accedere al server Harness Hosted MCP tramite SAML Single Sign-On \(SSO\). L'autenticazione principale dell'utente Harness Portal è rimasta completamente operativa. Gli utenti interessati hanno visto errori di login o sono stati reindirizzati a una pagina SSO non valida invece di completare il login. Il problema è stato causato dalla rottura dei cambiamenti in una versione di aggiornamento del servizio di identità Harness HarnessID. L'abbiamo riparato con una serie di hotfix, e il login SSO è stato completamente restaurato per tutti i clienti interessati. # Impact # Gli utenti che effettuano l'accesso a Harness MCP tramite SAML SSO non sono stati in grado di completare l'autenticazione. Le sessioni MCP esistenti che si basavano su SSO non potevano essere aggiornate, quindi alcuni utenti dovevano firmare di nuovo e non potevano. I login non-SSO a Hosted MCP hanno lavorato durante la maggior parte dell'incidente. Nessun dato del cliente è stato perso o esposto. I clienti che utilizzano la propria configurazione generica di applicazione SAML 2.0 in Okta non sono stati colpiti. # Causa della radice # Il 29 settembre 2026 fu pubblicata una versione aggiornata dell'applicazione Harness alla Okta Integration Network. L'aggiornamento ha aggiunto il supporto per la registrazione di più URL di risposta \(ACS\), in modo che i clienti che eseguono Harness in diverse regioni o ambienti potrebbero configurare più di un URL di callback. Harness include un valore AssertionConsumerServiceURL nella richiesta di autenticazione SAML che invia a Okta. Prima di questo aggiornamento, Okta non ha convalidato tale valore per le istanze delle applicazioni senza ulteriori URL ACS configurati e ha invece restituito l'affermazione SAML all'URL predefinito dell'applicazione. Dopo l'aggiornamento, questa validazione è diventata attiva in tutte le istanze di applicazione esistenti, comprese quelle in cui il cliente non aveva mai configurato un ulteriore URL ACS. Poiché il valore richiesto non era presente nell'elenco registrato dell'istanza, Okta ha restituito un errore HTTP 400. L'applicazione aggiornata è passata attraverso la revisione OIN standard di Okta, che include la verifica retrocompatibilità contro gli impianti esistenti dell'integrazione pubblicata. Questa modifica del comportamento di validazione per le istanze senza ulteriori URL ACS configurati non è stata emersa durante quella recensione, quindi ha raggiunto i clienti al momento del rilascio. # Remediation # Immediate Response # Due soluzioni di lavoro sono state pubblicate sulla pagina di stato: accedi dalla tegola Harness in Okta \(IdP-initiated login\), che non è stato interessato, o registrare l'URL Okta SSO dell'applicazione nel campo Ulteriori URL ACS dell'applicazione Harness Okta. L'irruzione ha coinvolto ogni cliente interessato direttamente e convalidato il loro accesso. # Risoluzione # Rimozione dell'applicazione alla versione precedente è stato deliberatamente evitato, in quanto ciò avrebbe differito solo la stessa interruzione alla prossima release. Ogni cliente interessato è stato invece sbloccato attraverso la registrazione dell'URL ACS, e stiamo lavorando con Okta per rendere nuovamente condizionato la convalida dell'URL ACS, in modo che le istanze senza ulteriori URL ACS configurati si comportino esattamente come hanno fatto prima, e non è richiesta alcuna azione del cliente. # Articoli d'azione Per evitare che tali problemi accadano di nuovo, Harness prenderà i seguenti elementi di azione 1. Lavorare con Okta per ripristinare la validazione dell'URL condizionale di ACS, quindi le istanze senza ulteriori URL ACS configurati si comportano esattamente come prima e non è richiesta alcuna azione del cliente. 2. Pubblicare una guida di configurazione dedicata per l'applicazione Harness OIN nella documentazione di Harness, compresi i requisiti di risposta \(ACS\) URL. 3. Aggiungi un passo di verifica indipendente pre-release contro le configurazioni dei clienti esistenti per qualsiasi aggiornamento futuro all'applicazione Okta pubblicata, accanto alla recensione di Okta. 4. Migrare l'autenticazione dell'utente a Harness ID, che rimuove completamente la dipendenza da questo comportamento di convalida.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 29 settembre 2026 alle ore 20:31 UTCinvestigating

   Stiamo attualmente indagando su questo problema.

2. 29 settembre 2026 alle ore 20:31 UTCidentified

   Il problema è stato identificato e si sta attuando una correzione.

3. 29 settembre 2026 alle ore 20:57 UTCidentified

   Abbiamo identificato un problema che si applica solo a SP-initiated login attraverso l'applicazione Harness Okta pubblicata. Dopo un recente aggiornamento a tale applicazione, questi tentativi di login hanno restituito un errore HTTP 400 quando l'URL SSO configurato mancava da ulteriori URL ACS. Le configurazioni generali SAML 2.0 in Okta non sono interessate. Soluzioni immediate: Utilizzare login IDP-initiated. Avviare il login dalla tegola di applicazione Harness in Okta. O Aggiungi il tuo URL Harness SSO ad ulteriori URL ACS nell'applicazione Harness Okta pubblicata.

4. 2 ottobre 2026 alle ore 00:33 UTCresolved

   Questo incidente è stato risolto.

5. 7 ottobre 2026 alle ore 18:30 UTCpostmortem

   # 1. Sommario A partire dal 29 settembre 2026, i clienti che si sottoscrivono a Harness attraverso l'applicazione Harness pubblicata nella Okta Integration Network \(OIN\) non sono stati in grado di completare il login SP-initiated SSO. Gli utenti interessati hanno ricevuto un errore HTTP 400 da Okta invece di essere firmati. Il problema è stato introdotto da una modifica del modo in cui Okta ha convalidato la risposta richiesta \(ACS\) URL per le installazioni esistenti dell'applicazione Harness pubblicata. I lavori sono stati pubblicati entro un'ora dal primo rapporto e ogni cliente interessato è stato sbloccato. # 2. Impatto * L'impatto è stato limitato ai clienti utilizzando l'applicazione Harness pubblicata dalla Okta Integration Network for SP-initiated login \ (iniziare il login da Harness\). Quei tentativi hanno restituito un errore HTTP 400 da Okta. * IdP-initiated login, iniziato dalla piastrella Harness in Okta, ha continuato a lavorare in tutto. * I clienti che utilizzano la propria configurazione generica di applicazione SAML 2.0 in Okta non sono stati colpiti. * Nessun dato del cliente è stato perso o esposto. # 3. Causa di radice Il 29 settembre 2026 fu pubblicata una versione aggiornata dell'applicazione Harness alla Okta Integration Network. L'aggiornamento ha aggiunto il supporto per la registrazione di più URL di risposta \(ACS\), in modo che i clienti che eseguono Harness in diverse regioni o ambienti potrebbero configurare più di un URL di callback. Harness include un valore AssertionConsumerServiceURL nella richiesta di autenticazione SAML che invia a Okta. Prima di questo aggiornamento, Okta non ha convalidato quel valore per le istanze delle applicazioni che non avevano ulteriori URL ACS configurati, e ha semplicemente restituito l'affermazione SAML all'URL ACS predefinito dell'applicazione. Dopo l'aggiornamento, questa validazione è diventata attiva su tutte le istanze esistenti dell'applicazione, comprese quelle in cui il cliente non aveva mai configurato un ulteriore URL ACS. Poiché il valore richiesto non è stato presente nell'elenco registrato dell'istanza, Okta ha respinto la richiesta di autenticazione con un errore HTTP 400. L'applicazione aggiornata è passata attraverso la revisione OIN standard di Okta, che include la verifica retrocompatibilità contro gli impianti esistenti di un'integrazione pubblicata. Questa modifica del comportamento di validazione per le istanze senza ulteriori URL ACS configurati non è stata emersa durante quella recensione, quindi ha raggiunto i clienti al rilascio. # 4. Rimediazione # Immediate Response # Due soluzioni sono state pubblicate sulla pagina di stato: accedi dalla tegola Harness in Okta \(IdP-initiated login\), che non è stato interessato; o registra l'URL Okta SSO dell'applicazione nel campo Ulteriori URL ACS dell'applicazione Harness Okta. Supporto impegnato ogni cliente interessato direttamente e convalidato sign-in con loro. # Risoluzione # Rimozione dell'applicazione alla versione precedente è stato deliberatamente evitato, in quanto ciò avrebbe differito solo la stessa interruzione alla prossima release. Ogni cliente interessato è stato invece sbloccato attraverso la registrazione dell'URL ACS, e stiamo lavorando con Okta per rendere nuovamente condizionato la convalida dell'URL ACS, in modo che le istanze senza ulteriori URL ACS configurati si comportino esattamente come hanno fatto prima e non è richiesta alcuna azione del cliente. # 5. Articoli di azione Per evitare che tali problemi accadano di nuovo, stiamo lavorando su | **Action Item | | --- | Lavorare con Okta per ripristinare la validazione dell'URL condizionale ACS, quindi le istanze senza ulteriori URL ACS configurati si comportano esattamente come prima e non è richiesta alcuna azione del cliente. # | Pubblica una guida di configurazione dedicata per l'applicazione Harness OIN nella documentazione di Harness, inclusa la risposta \(ACS\) requisiti URL. | Aggiungi un passo di verifica indipendente pre-release contro le configurazioni dei clienti esistenti per qualsiasi aggiornamento futuro all'applicazione Okta pubblicata, accanto alla recensione di Okta. | Migrate autenticazione utente a Harness ID, che rimuove completamente la dipendenza da questo comportamento di validazione. #

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 29 settembre 2026 alle ore 18:45 UTCinvestigating

   Stiamo attualmente indagando su questo problema.

2. 29 settembre 2026 alle ore 21:55 UTCmonitoring

   Una soluzione è stata implementata e stiamo monitorando i risultati.

3. 29 settembre 2026 alle ore 22:01 UTCresolved

   Questo incidente è stato risolto.

4. 2 ottobre 2026 alle ore 22:40 UTCpostmortem

   ## Tra circa **11:37 AM e 3:01 PM PDT \(18:37–22:01 UTC\) il 29 settembre 2026**, i clienti che utilizzano Harness CI self-hosted Linux cloud runners in **prod1/prod2 \(us-west1\)** hanno sperimentato guasti di rete intermittenti durante l'esecuzione delle tubazioni — in primo luogo Git/network timeouts durante l'acquisizione del codice sorgente. ♪Root Cause ♪ Ciò è dovuto principalmente alla saturazione del nostro NAT, che è stato fuorfato da una capacità di calcolo del provider cloud temporaneo, impedendo il nuovo provisioning della VM. ### Impact * I clienti in esecuzione self-hosted Linux CI costruisce in us-west1 sega **intermittent build/pipeline fails**, non un full outage. * Errori osservati di fronte al cliente inclusi Git fetch timeouts, ad esempio `Failed per connettersi a github.com porta 443: Connessione timed out` Revisione: * **Immediate:** Carico VM bilanciato ARM dal percorso us-west1 saturo verso il centro1 \(in parte limitato dalla capacità centrale1\); riavviato i gateway Nuvo NAT interessati, che stabilizzato rete pipeline. **Action Items** 1. Sicuro porta NAT aggiuntivo / capacità IP \(In corso\) 2. Migliorare il rilevamento della saturazione NAT e avvisare prima dell'impatto del cliente. 3. Valutare le contingenze di capacità transfrontaliere in modo che la carenza di calcolo di una regione non blocchi la mitigazione del failover.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 29 settembre 2026 alle ore 14:41 UTCinvestigating

   Stiamo attualmente indagando su questo problema.

2. 29 settembre 2026 alle ore 15:54 UTCmonitoring

   Una soluzione è stata implementata e stiamo monitorando i risultati.

3. 29 settembre 2026 alle ore 15:57 UTCmonitoring

   Stiamo continuando a monitorare eventuali ulteriori problemi.

4. 29 settembre 2026 alle ore 18:49 UTCresolved

   Questo incidente è stato risolto.

5. 2 ottobre 2026 alle ore 05:37 UTCpostmortem

   # Sommario # I clienti su Prod-2 hanno sperimentato elevati tassi di guasto nelle pipeline di verifica continua. I lavori di verifica non sono riusciti a completare o segnalare errori perché i lavoratori di raccolta dati CV non hanno potuto comunicare con il servizio della piattaforma che coordina il loro lavoro. Questo è stato causato da un picco di traffico inaspettato a uno dei nostri sistemi di backend. Il servizio è stato ripristinato mettendo a punto il componente della piattaforma interessata. Nessuna perdita di dati o corruzione si è verificato. ♪Customer Impact ♪ I clienti che utilizzano la verifica continua su Prod-2 hanno visto i lavori di pipeline di verifica guasto o tempo fuori durante la finestra incidente. Una frazione significativa di casi di lavoro di verifica che si sono verificati durante questo periodo si è conclusa in un guasto operativo. Le tubature che non utilizzano CV hanno continuato a funzionare normalmente. ♪Root Cause ♪ Una grande esecuzione di provisioning automatizzata ha creato un numero significativo di lavoratori persistenti di monitoraggio CV in una breve finestra, che ha sopraffatto un componente piattaforma condivisa. L'improvviso aumento delle chiamate in uscita concomitante ha esaurito le connessioni di rete disponibili su ogni istanza di servizio. Mitigazione. Il limite massimo di scaling per il servizio CV è stato aumentato, permettendo di espandere la capacità di soddisfare la domanda. I fallimenti si fermarono poco dopo la fine della scalata. # Next Steps # Per prevenire la ricorrenza, Harness: * * Aumentare la capacità headroom e aggiungere provviste guardrails:** Alzare il limite di scaling del servizio CV per mantenere la stanza sotto i carichi di scoppio, e introdurre il limite di tasso per la fornitura di massa dei servizi monitorati. ♪ Improve Resiliency ♪ Aggiunga il backoff esponenziale e il jitter per i retries del lavoratore, e usi un pool di connessione riutilizzabile per ridurre l'overhead e prevenire guasti transitori da compounding sotto alta concurrency. *Migliora il monitoraggio e l'avviso: * Migliorare l'avviso per i tassi di crescita dei lavoratori anormali per conto, così le condizioni simili vengono rilevate e agite in precedenza.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 29 settembre 2026 alle ore 13:12 UTCresolved

   Il 28 settembre 2026, abbiamo osservato un problema con la copia dei file dal Harness Filestore durante la fase di esportazione, dove i file venivano copiati come file null/empty. Di conseguenza, tutte le pipeline che utilizzano le API di Filestore sono state bloccate durante la finestra incidente. Il problema è stato causato a causa di un rollout di Feature Flag che è stato reindirizzato una volta che il problema è stato scoperto. Tutte le operazioni sono tornate alla normalità.

2. 1 ottobre 2026 alle ore 17:28 UTCpostmortem

   ## Il 28 settembre 2026, alcuni clienti su Prod-2 hanno sperimentato fallimenti nelle fasi della pipeline di CD che leggono il contenuto di File Store utilizzando espressioni pipeline \(ad esempio, `\). Le espressioni colpite hanno restituito nullo invece del contenuto di file previsto, causando passi a carico per fallire o comportarsi in modo errato. Il problema è stato tracciato ad un aggiornamento della piattaforma che ha ottimizzato i controlli di autorizzazione sulle API di File Store. L'aggiornamento è stato ristampato e le espressioni di File Store funzionano normalmente da allora. ### Customer Impact * Solo i passaggi di pipeline su Prod-2 che leggono il contenuto di File Store attraverso le espressioni sono stati colpiti. Le pipe che non utilizzano le espressioni di File Store non sono state influenzate. * Espressioni colpite risolte a null, causando passi che dipendono da file di configurazione o impostazioni per non riuscire o produrre output errato. * Nessun contenuto di File Store è stato modificato. Nessun file, segreti, credenziali o artefatti sono stati esposti, e nessun dato è stato perso. ## Root Cause Nell'ambito di un'iniziativa di sicurezza in corso, Harness ha implementato controlli di autorizzazione più severi su diverse API della piattaforma, tra cui l'API che serve il contenuto di File Store. Quando una pipeline valuta un'espressione File Store, un servizio Harness interno chiama un altro per recuperare il file. I nuovi controlli di autorizzazione sono falliti, con conseguente rifiuto delle richieste e delle espressioni di nullità. ### Mitigation Una volta che l'aggiornamento della piattaforma è stato identificato come la causa, è stato rotolato indietro in tutto l'ambiente di produzione. Le espressioni di File Store sono risolte correttamente dal rollback. Non è richiesta alcuna azione del cliente. ### Preventive Measures & Next Steps ***Audit affetti APIs:** Verificare tutte le API in cui sono stati applicati i controlli più severi di autorizzazione per garantire che le chiamate interne di servizio a servizio siano correttamente contabilizzate. Traduzione: Migliorare le suite di test automatizzate per includere la valutazione dell'espressione di File Store attraverso i percorsi di esecuzione pipeline

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 23 settembre 2026 alle ore 20:17 UTCinvestigating

   Stiamo attualmente indagando problemi di connettività che interessano i clienti i cui ambienti sono protetti da firewall Palo Alto Networks. Questi firewall bloccano le connessioni alle API di Harness, che possono causare: - Esecuzioni di condotte fallite - Incapacità di implementare applicazioni - Intermittent timeouts quando si accede alle funzionalità della piattaforma Harness - Fallimenti di integrazione con strumenti di terze parti - Delegare la connettività con la piattaforma Harness Questo problema non è causato da un'interruzione di servizio Harness, ma piuttosto da regole firewall sul lato della rete. Stiamo consigliando ai clienti di fare un'eccezione per i nostri endpoint DNS.

2. 24 settembre 2026 alle ore 08:43 UTCmonitoring

   Mitigazione Disponibile: Traffico di Harness bloccato dalla politica di sicurezza di rete Abbiamo identificato un problema in cui alcuni clienti potrebbero non essere in grado di accedere a Harness perché il traffico di Harness viene classificato come “AI-Platform” dai controlli di sicurezza della rete Palo Alto e successivamente bloccato dalla politica firewall/INET del cliente. Se stai vivendo questo problema: Si prega di contattare il team Network/Firewall/CyberSecurity della vostra organizzazione e richiedere che il traffico Harness richiesto sia consentito attraverso la vostra politica Palo Alto firewall. Come mitigazione, i clienti possono consentire la categoria URL “AI-Platform” per gli endpoint Harness richiesti, o aggiungere i domini Harness interessati/FQDN all'elenco approvato/permesso della loro organizzazione, in conformità con le loro politiche di sicurezza. Dopo l'aggiornamento della politica firewall, l'accesso a Harness dovrebbe essere ripristinato. Importante: La politica firewall è gestita dal team di rete/sicurezza del cliente. Se il endpoint Harness è erroneamente classificato da Palo Alto, i clienti possono anche richiedere una recensione della categoria URL da Palo Alto Networks.

3. 25 settembre 2026 alle ore 17:10 UTCresolved

   Dopo la consultazione con Palo Alto Networks, possiamo confermare che il 23 settembre 2026, app.harness. io è stato classificato come AI Platform Service dal Palo Alto Networks Team. Palo Alto Networks ha inviato un avviso ai clienti in agosto sulla riclassificazione. Questo cambiamento può mettere AI Platform Service sotto una politica diversa da app.harness. io's precedenti regolee categorizzazione, Computer e Internet Info. La politica applicata dipende dalle impostazioni del cliente. I clienti di Harness dovrebbero discutere questa categorizzazione e gli avvisi con il loro team di rete interno e Palo Alto Networks.

4. 13 ottobre 2026 alle ore 04:50 UTCpostmortem

   .

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 22 settembre 2026 alle ore 16:40 UTCinvestigating

   Stiamo attualmente indagando su questo problema.

2. 22 settembre 2026 alle ore 17:14 UTCidentified

   Il problema è stato identificato e si sta attuando una correzione.

3. 22 settembre 2026 alle ore 18:01 UTCmonitoring

   Una soluzione è stata implementata e stiamo monitorando i risultati.

4. 22 settembre 2026 alle ore 18:38 UTCresolved

   Questo incidente è stato risolto.

5. 2 ottobre 2026 alle ore 22:05 UTCpostmortem

   # Sommario Il 22 settembre 2026, tre dei nostri gateway di rete in uscita in una regione divennero malsani e cominciò a rifiutare una piccola percentuale di nuovi tentativi di connessione in uscita. Il problema è stato risolto lo stesso problema giorno completamente senza ulteriore ricorrenza o seguito impatto. La causa sottostante era un buffer di monitoraggio del traffico interno saturo su quei gateway, che ha causato i loro controlli sanitari per rispondere troppo lentamente e ottenere marcato malsano. # Impact # * Solo tre casi di gateway in una regione sono stati colpiti; altre regioni e altri gateway nella stessa regione non sono stati influenzati. * Non c'è stato alcun fallimento in cascata, il problema è stato completamente risolto con un singolo giro di porte riavviamento, e non si sono verificati problemi di follow-on dopo. # Causa della radice # I nostri gateway di rete in uscita eseguono un componente interno che monitora il traffico di rete per la visibilità operativa. Sotto l'alto traffico sostenuto, il buffer interno di questo componente è diventato saturo, che ha creato la backpressure abbastanza grave per rallentare le proprie risposte di controllo sanitario del gateway oltre il timeout che il nostro bilanciatore di carico consente. Una volta superato il timeout, il bilanciatore di carico ha segnato le porte colpite malsano e ha cominciato a rifiutare una parte di nuove connessioni destinate a loro. L'inoltro dei pacchetti reali ha continuato a funzionare normalmente durante l'incidente. Questo è stato specificamente un problema di controllo e monitoraggio-buffer, non un fallimento della capacità di inoltro del nucleo dei gateway. # Risoluzione Le tre istanze di gateway colpite sono state riavviate manualmente, che ha eliminato il buffer di monitoraggio saturo e immediatamente ripristinato il normale comportamento di controllo della salute. I rifiuti di connessione si fermarono appena il riavvio completato, e non era necessario alcun ulteriore intervento. # Azioni preventive Traduzione: | --- | Sostituire l'attuale approccio di monitoraggio del traffico su tutti i gateway con un'implementazione più efficiente e più bassa che non può saturare in questo modo, e che avvisa bene prima di qualsiasi impatto visibile dal cliente. | Implement automatico, sostituzione periodica di istanze di gateway di lunga durata su un programma fisso, in modo che nessun caso può accumulare il tipo di degrado relativo all'età visto in questo incidente. # | Le istanze di gateway Migrate alle infrastrutture ottimizzate in rete con una capacità di rete sostanzialmente più dedicata, più adatta al traffico ad alto rendimento sostenuto. | Migliorare l'utilizzo del buffer di monitoraggio esistente mentre la sostituzione a più lungo termine viene eliminata. | Migliorare l'avviso specificamente sulla latenza di risposta di controllo sanitario gateway, per catturare i primi segni di degrado prima che diventi visibile dal cliente. #

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 22 settembre 2026 alle ore 14:00 UTCidentified

   Il problema è stato identificato e si sta attuando una correzione.

2. 22 settembre 2026 alle ore 14:08 UTCmonitoring

   Una soluzione è stata implementata e stiamo monitorando i risultati.

3. 22 settembre 2026 alle ore 14:20 UTCresolved

   Questo incidente è stato risolto.

4. 2 ottobre 2026 alle ore 22:10 UTCpostmortem

   Come la causa principale precedente.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 21 settembre 2026 alle ore 16:39 UTCinvestigating

   Stiamo attualmente indagando su questo problema.

2. 21 settembre 2026 alle ore 17:12 UTCidentified

   Il problema è stato identificato e si sta attuando una correzione.

3. 21 settembre 2026 alle ore 18:27 UTCmonitoring

   Una soluzione è stata implementata e stiamo monitorando i risultati.

4. 21 settembre 2026 alle ore 18:33 UTCresolved

   Questo incidente è stato risolto.

5. 29 settembre 2026 alle ore 22:39 UTCpostmortem

   # Il 21 settembre 2026, i clienti di Prod 2 hanno sperimentato degraded e quindi in gran parte non disponibile cruscotti di distribuzione per circa tre ore. Il problema è stato causato da una serie di query di analisi dietro quei cruscotti che leggono molto più dati di cui hanno bisogno, che ha esaurito la capacità del database che li serve. Un riavvio del servizio interessato ha ripristinato completamente i cruscotti, e la piattaforma è stata stabile da allora. ## Impatto del cliente Pagine di Dashboard caricato lentamente o timed fuori tra 14:48 e 18:11 UTC. Esecuzione di tubazioni e registrazione di distribuzione eseguito su infrastrutture separate e ha continuato a funzionare normalmente. Nessuna perdita di dati o corruzione si è verificato. # Causa radice # Le query del cruscotto mancavano un filtro a fascia di tempo sulla colonna utilizzata per dividere la tabella più grande in segmenti settimanali, quindi ogni query leggeva tutti i dati storici invece del solo periodo richiesto. La correttezza non è mai stata influenzata — i cruscotti hanno restituito i risultati giusti; solo la quantità di dati letti per produrli era eccessiva. Mentre il volume dei dati cresceva, il costo di quelle letture superava quello che il database poteva servire, e i retries delle query inadeguate aggiungevano ulteriore carico, quindi la condizione non ha chiarito fino a quando il servizio è stato riavviato. # Mitigazione # * Effettuato un riavvio del servizio interessato, che ha interrotto il ciclo di riprova e ha permesso al database di completare il suo lavoro eccezionale * Latenza confermata del cruscotto e l'utilizzo della connessione del database sono tornati ai livelli normali ## Prossimo passo Per prevenire la ricorrenza, Harness: * Aggiungi il filtro di fascia di tempo mancante alle query del cruscotto interessato in modo da ogni lettura solo il periodo richiesto * Sostituire i retries immediati con i ritocchi legati e di supporto * Migliorare il rilevamento aggiungendo avvisi sull'utilizzo della connessione del database e sui costi di esecuzione per-query

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.