88 Harness incidents · marzo 2026 — official updates, affected components, duration and resolution details.
Stiamo attualmente indagando su questo problema.
Questo incidente è stato risolto.
Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.
L'esecuzione del tubo è bloccata in Prod1. Stiamo indagando sul problema.
Una soluzione è stata implementata e stiamo monitorando i risultati.
Questo incidente è stato risolto.
Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.
Stiamo attualmente indagando su questo problema.
Il problema è stato identificato e si sta attuando una correzione.
Una soluzione è stata implementata e stiamo monitorando i risultati.
Questo incidente è stato risolto.
# Tra il 27 agosto e il 28 agosto 2026, i clienti hanno sperimentato un problema in cui alcune tubazioni, distribuzioni e risorse correlate sono apparsi come non trovato nella Harness UI e API, anche se i dati sottostanti sono rimasti intatti. Il problema si è verificato durante un programmato aggiornamento delle infrastrutture interne che ha interessato la comunicazione tra i servizi della piattaforma interna. Di conseguenza, le richieste che dipendevano dalla risoluzione di account, organizzazione e scopo di progetto non erano in grado di completare con successo, il che ha portato a risposte errate non riscontrate che sono state restituite ai clienti per le entità esistenti. Ingegneria ha identificato il problema, ha rotolato indietro il cambiamento, e il servizio normale ripristinato. Nessun dato del cliente è stato perso o cancellato durante l'incidente. # Causa radice # Il problema è stato causato da un errore di configurazione introdotto durante un aggiornamento pianificato di routing del servizio interno in produzione. Un servizio di piattaforma interna responsabile della risoluzione di account, organizzazione e contesto di progetto non è stato in grado di convalidare richieste da altri servizi di Harness dopo la modifica è stata applicata. Poiché questo passo di validazione è necessario prima che molte entità legga e le azioni connesse con la pipeline possono procedere, le richieste fallite emerse ai clienti come non trovato errori per le risorse che hanno continuato ad esistere normalmente. Il problema è stato limitato all'ambiente di produzione interessato ed è stato risolto modificando il cambiamento e ripristinando il percorso di comunicazione del servizio precedente. ## Impact * Alcuni clienti hanno visto le pipeline esistenti, le implementazioni e le entità correlate appaiono come non si trovano nell'interfaccia utente e API. * Alcune operazioni correlate alla pipeline, tra cui la progressione dell'esecuzione, avvio webhook-triggered, la valutazione di trigger programmata e l'elenco delle entità, sono state temporaneamente interrotte. * Il problema ha interessato la disponibilità e la visibilità delle entità esistenti, ma non ha rimosso i dati o modificare le configurazioni dei clienti. * Non si è verificato alcun accesso non autorizzato, e non è stata osservata alcuna perdita di dati del cliente. ## Remediation # Immediate # Revertito l'aggiornamento della configurazione dell'infrastruttura e ripristinato il percorso di comunicazione del servizio in precedenza funzionante. Traduzione: Verificato che le ricerche delle entità interessate, le operazioni di pipeline e le API dipendenti funzionassero normalmente dopo il rollback. # Permanente # Corretto il trattamento di configurazione associato all'aggiornamento in modo che i problemi simili non interferiscano con l'autenticazione di servizio-a-servizio nei futuri rollout. ## Elementi di azione Per evitare che tali problemi accadano di nuovo, Harness sarà 1. Migliorare la convalida della configurazione migliorando i test di pre-deployment per verificare la comunicazione interna dei servizi prima di spostare il traffico di produzione. 2. Migliorare il monitoraggio e l'avviso per i guasti di autenticazione interni in modo che i problemi possono essere rilevati prima. 3. Migliorare la gestione degli errori in modo che i guasti di dipendenza sono meno probabilità di apparire ai clienti come risorsa non trovato errori.
Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.
Stiamo attualmente indagando su un problema segnalato nelle tubazioni IACM nei cluster Prod-1, Prod-2, Prod-4 e EU1.
Stiamo continuando a indagare su questo problema.
Abbiamo annullato il cambiamento che ha causato questo problema in tutti i cluster.
Questo incidente è stato risolto.
Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.
Stiamo attualmente indagando su questo problema.
Attualmente stiamo indagando sui rapporti che l'interfaccia utente di Feature Management & Experimentation (FME) non riesce a caricare. I clienti che tentano di accedere alla console FME possono incontrare errori o pagine non rispondenti. La valutazione della bandiera caratteristica e il traffico SDK non sono considerati interessati. Un ulteriore aggiornamento seguirà a breve.
Una soluzione è stata implementata e stiamo monitorando i risultati.
Questo incidente è stato risolto.
# * A partire da **23:42 UTC** il 23 agosto 2026, diversi clienti FME hanno riferito guasti caricando l'UI FME. * FME UI Artifacts servito dal CDN è scaduto a causa di una politica di conservazione, causando FME UI di non caricare. * Qualsiasi richiesta di bandiera cambia attraverso l'API, cambia la consegna e il data pipeline continua a funzionare senza interruzioni. # Causa radice # * La FME UI viene servita da un CDN. Gli artefatti UI sono stati sfrattati a causa di una politica di conservazione, causando l'interfaccia utente di non caricare per tutti gli utenti. ## Impact * Il FME UI non è stato in grado di caricare per tutti gli utenti in tutti gli ambienti di produzione. ### Che cosa non è stato influenzato? * Funzionalità SDK e valutazione della bandiera runtime * Chiamate API di amministrazione * Dati di configurazione della bandiera del cliente * Nessuna perdita di dati è avvenuta ## Remediation * FME UI è stato ripristinato nel CDN attraverso una distribuzione * Recupero confermato in tutti gli ambienti di produzione prima di chiudere l'incidente. ## Elementi di azione * Migliorare la politica di ritenzione patrimoniale in modo che la versione attualmente attiva non sia mai soggetta a sfratto.
Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.
Stiamo attualmente indagando su questo problema.
La lentezza potrebbe causare uno dei sintomi seguenti: - Pipeline che non iniziano - Delays in esecuzione - Pipeline cancellate a causa dei timeout
Il nostro provider cloud sta affrontando un incidente attivo e stiamo seguendo.
Stiamo continuando a indagare su questo problema.
Il nostro provider cloud ha confermato un incidente in corso che colpisce più regioni. Le tubazioni di cablaggio non hanno subito fallimenti, anche se alcuni utenti possono continuare a sperimentare la lentezza. Stiamo monitorando la situazione da vicino e fornirà aggiornamenti come ulteriori informazioni diventano disponibili.
Stiamo osservando migliori latencies in tutta la scheda seguendo la correzione implementata dal nostro provider cloud. Stiamo continuando a monitorare la situazione da vicino e forniremo ulteriori aggiornamenti come garantito. Abbiamo notato alcune esecuzioni bloccate per CI per un paio di clienti, che stiamo indagando
Questo incidente è stato risolto.
# Sommario Il 20 agosto 2026, a partire dalle 15:00 UTC circa, la piattaforma Harness ha sperimentato una diffusa degrado delle prestazioni in tutti gli ambienti produttivi. Le esecuzioni di pipeline che normalmente completano in circa due minuti hanno richiesto sette a dieci minuti. La consegna continua, l'integrazione continua, l'orchestrazione delle tubazioni e la gestione delle funzionalità e l'esperimento sono stati tutti colpiti. Google Cloud Platform ha sperimentato un incidente multi-prodotto nella regione us-west1 che interessa Bigtable, Compute Engine, Google Kubernetes Engine, e persistent-disk I/O. Il degrado ha aumentato latenza di funzionamento del database da circa 2 ms a oltre 10 ms al 95 ° per centoile, che a sua volta ha causato ritardo di elaborazione del messaggio-queue e propagato ad ogni servizio che dipende dall'accesso tempestivo del database. # Impact # E' stato un degrado, non un'estrazione. Pipeline ha continuato a eseguire e completare con successo durante tutto; erano lenti piuttosto che non mancare. Nessun dato è stato perso, e nessun lavoro del cliente è stato abbandonato a seguito di questo incidente. ♪Root cause ♪ L'infrastruttura di produzione di Harness negli ambienti interessati funziona su dischi persistenti di Google Cloud Platform nella regione us-west1. Quando lo strato di archiviazione è stato degradato, l'effetto si è propagato attraverso la piattaforma in una catena prevedibile: **Degrado I/O persistente in noi-ovest1.** Google Cloud Platform ha sperimentato un incidente multi-prodotto che interessa Bigtable, Compute Engine, Google Kubernetes Engine e prestazioni persistenti-disk. Questo è stato un fallimento dell'infrastruttura nell'ambiente del fornitore, al di fuori del controllo di Harness. # Azioni preventive # Anche se Harness non può impedire un fallimento dell'infrastruttura del provider cloud. Le azioni sottostanti sono finalizzate a rilevare uno più veloce ed essere meglio posizionati per agire su di esso. Traduzione: | --- | Prosegui il pre-testing di routine dei fallimenti del database di cross-region mirati, come eseguito durante questo incidente, per mantenere la disponibilità di failover verificata piuttosto che assumere | | Valuta la prontezza del failover multi-regione a pieno ritmo per scenari futuri in cui la latenza trasversale sarebbe inaccettabile |
Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.
Stiamo attualmente indagando su questo problema.
Il problema è stato identificato e si sta attuando una correzione.
Una soluzione è stata implementata e stiamo monitorando i risultati.
Questo incidente è stato risolto.
## Il 20 agosto 2026, tra 10:24 e 14:55 UTC, un sottoinsieme di FME scrive fallito. Le scritture fatte dall'UI FME e le scritture fatte con i gettoni di accesso Harness \(PAT e SATs\) non sono state influenzate. La valutazione della bandiera di Runtime ha continuato a funzionare normalmente. Il problema è stato mitigato da un recente cambiamento di autenticazione in un servizio di governance condiviso, e le scritture interessate sono tornate alla normalità di 14:55 UTC. Stato: [https://status.harness.io/incidents/rhthgm7d5dkz](https://status.harness.io/incidents/rhthgm7d5dkz) ## Root Cause Un cambiamento nel modo in cui un servizio di governance condiviso autenticato chiamate in entrata ha portato a alcune scritture FME essere respinto. Quegli scritti hanno usato le credenziali di servizio-servizio che il servizio di governance non poteva più verificare dopo la modifica. FME supera un fallimento di governance al client come HTTP 499, lo stesso stato utilizzato quando una politica di governance nega intenzionalmente un cambiamento. Poiché il 499 è una risposta valida e attesa in quel percorso di negazione, i guasti non sembravano un outage sui nostri avvisi, e l'incidente è stato identificato dai rapporti dei clienti piuttosto che il rilevamento interno. ### Impact * Un sottoinsieme di FME scrive non riuscito durante la finestra, principalmente quelli fatti utilizzando le chiavi API legacy Split o modificare la pianificazione richiesta. * Gli scritti fatti dalla FME UI non sono stati influenzati. * Le scritture che utilizzano i gettoni di accesso di Harness \(PAT e SATs\) non sono state influenzate. * La valutazione della bandiera Runtime è continuata normalmente. * Non si è verificata alcuna perdita di dati. Le scritture fallite non sono state applicate. ### Remediation Revertito il cambiamento di autenticazione governance-service. Le scritture colpite ritornano immediatamente alla normalità. ### Elementi di azione Per evitare che tali problemi accadano di nuovo, * L'armonia restituirà un errore distinto \(non 499\) quando una scrittura fallisce perché la governance non potrebbe essere valutata, quindi non è confuso con una politica intenzionale negazione. * Aggiungi all'avviso sulla richiesta di valutazione della governance, piuttosto che fare affidamento sul codice di stato volto al cliente. * Espandi il supporto di autenticazione per le valutazioni dei criteri. * Espandi la copertura automatizzata per ulteriori scenari di scrittura.
Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.
Stiamo attualmente indagando su questo problema.
Stiamo continuando a indagare su questo problema.
Il problema è stato identificato e si sta attuando una correzione.
Una soluzione è stata implementata e stiamo monitorando i risultati.
Stiamo continuando a monitorare eventuali ulteriori problemi.
Questo incidente è stato risolto.
# Sommario # Il 19 agosto 2026 tra le 12:35 e le 17:29 UTC, il servizio Harness Application Security ha sperimentato una significativa disgregazione che interessa sia la console di customer-facing che la pipeline di ingestione di dati nelle regioni SaaS Production e US1. ♪Root Cause ♪ Il servizio di configurazione interno che fornisce le impostazioni di runtime a quasi ogni altro componente è stato sovraccaricato e inserito un ciclo di riavvio ripetuto. Poiché molti servizi dipendono da esso, gli effetti sono stati ampi: pagine di console come politiche di protezione, viste di postura, registri di attività, inventario API e politica personalizzata non è riuscito a caricare o timed out, e l'elaborazione a valle ha bloccato mentre in attesa di configurazione non poteva ottenere. # L'impatto del cliente # Traduzione: | --- | | Console \(UI\) impatto | Le pagine multiple non sono state caricate o cedute, comprese le politiche di protezione, le pagine degli eventi di postura e le viste di postura all'interno di dashboard e pagine di insight, query dei log di attività, schermi dell'inventario API, policy personalizzata, e viste e widget sensibili-dati. # | Impatto di ingestione | Processo di telemetria di sicurezza degradato gravemente e, in alcuni percorsi, interrotto interamente. Lag dei consumatori è cresciuta attraverso la normalizzazione, il raggruppamento, il rilevamento di anomalia, la generazione e le relative fasi di elaborazione. # | Perdita di dati | Un sottoinsieme di telemetria ingerita durante la rottura è stato definitivamente abbandonato. # Mitigazione. Diverse mitigazioni intermedie CPU e memoria aggiuntive, rilassate soglie di controllo della salute, un riavvio del database, e un pool di connessione più grande ha analizzato il problema. Disabilitare la nuova funzione in entrambe le regioni colpite ha ripristinato il throughput bruscamente e duramente. L'incidente è stato risolto alle 17:29 UTC. # Azioni preventive # Le seguenti azioni sono impegnate e tracciate internamente al completamento. La funzione che ha innescato questo incidente rimane disabilitata e non sarà riattivata fino a quando il lavoro qui sotto è completo e convalidato. Traduzione: | --- | | | OPtimize the code by tuning parametri come l'evizione della cache e la ritenzione , valutare l'impaginazione basata sul cursore per il recupero delle regole di massa in quanto i conti di regola crescono | | Aggiungi un indice di database appositamente costruito per il modello di accesso alla visualizzazione dei servizi | | Remediate pipeline recovery semantics in modo che i consumatori riproducono in modo sicuro dopo la perdita di posizione-marker invece di saltare backlog | | Mandate staged rollout per override di configurazione che alterano i modelli di richiesta a valle: cluster a basso volume, poi mid-volume, poi high-volume | | Aggiungi protezione di backpressure e concurrency al servizio di configurazione: circuito di rottura, code delimitate e isolamento timeout | | Migliorare l'osservabilità mediante la strumentazione di metriche più dettagliate |
Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.
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.
Stiamo monitorando le tubazioni bloccate in prod2. Le nuove esecuzioni stanno passando mentre stiamo monitorando continuamente i servizi.
Stiamo monitorando le tubazioni bloccate in prod2. Per i clienti che stanno ancora vedendo tubazioni bloccate, vi chiediamo di interrompere e re-trigger.
Questo incidente è stato risolto.
# Summary # Il 6 agosto 2026 \(Morning PDT\), alcuni clienti che eseguono tubazioni nell'ambiente di produzione Prod2 osservano le esecuzioni di pipeline che hanno smesso di fare progressi — fasi che non hanno avanzato e non hanno prodotto ulteriori aggiornamenti di output o di stato. Il problema è stato segnalato dai clienti interessati. Gli ingegneri di Harness hanno identificato la causa, mitigato l'impatto e le esecuzioni delle tubazioni sono tornate al normale funzionamento. Il problema è stato causato da un'espressione auto-referenziale pipeline. Un webhook Git ha innescato una pipeline che ha fatto riferimento al contenuto del payload webhook, e il payload stesso conteneva ulteriori copie di quella stessa espressione. Ogni giro di risoluzione di espressione ha quindi prodotto più espressioni per risolvere, raddoppiando la quantità di lavoro ogni volta. Questo esaurì le risorse dell'istanza di servizio elaborando che l'esecuzione, e altre esecuzioni assegnate alla stessa istanza non erano in grado di progredire mentre era in quello stato. # Durante la finestra incidente \(circa 6:11 AM alle 11:23 PDT il 6 agosto 2026\): * Le esecuzioni di alcuni clienti sul Prod2 hanno bloccato la media esecuzione e non hanno fatto ulteriori progressi. * Esecuzioni colpite non hanno prodotto nuovi aggiornamenti di uscita passo o stato, e devono essere abortiti e re-run dopo la mitigazione. * Il comportamento è stato limitato alle esecuzioni che sono state elaborate dall'istanza di servizio interessata — le tubazioni gestite da altre istanze hanno continuato ad eseguire normalmente. Non c'era perdita di dati. Le definizioni di Pipeline, la storia dell'esecuzione e lo stato memorizzato non sono state influenzate. La maggior parte degli oleodotti su Prod2 ha continuato a eseguire con successo durante l'incidente; l'impatto primario era che alcune esecuzioni in volo non potevano essere completate e dovevano essere rielaborate una volta che il problema è stato mitigato. ♪#Root Cause ♪ Harness pipelines supporta espressioni che vengono risolte a runtime — per esempio, un'espressione che inserisce il contenuto del payload Git webhook che ha innescato la pipeline. In questo caso, un messaggio di Git commit conteneva il testo letterale dell'espressione payload stesso, due volte, e la pipeline faceva riferimento a quella stessa espressione payload. Poiché il messaggio di commit fa parte del payload webhook, risolvendo l'espressione inserita l'intero payload — comprese le due copie letterali dell'espressione portata nel messaggio di commit. Quelle copie appena inserite sono state poi trattate come espressioni da risolvere, e ogni passaggio ha inserito altre due copie complete del payload. La dimensione del valore da trattare, e il lavoro richiesto per elaborarlo, quindi raddoppiato su ogni passaggio e cresciuto esponenzialmente piuttosto che convergere. L'armonia ha una salvaguardia destinata a fermare esattamente questo: la risoluzione dell'espressione è delimitata da una profondità di nidificazione massima, al di là della quale la risoluzione si ferma e la pipeline non riesce con un errore esplicito. Un difetto di tale salvaguardia significava che il limite non è stato applicato in questo caso specifico auto-referenziale, quindi la risoluzione ha continuato incontrollato. La risoluzione dell'espressionazione è in linea con i thread che avviano i passaggi della pipeline. Come ogni passaggio consumato progressivamente più memoria e CPU senza mai completare, l'istanza di servizio che esegue che il lavoro ha smesso di fare progressi, e ogni esecuzione assegnata a quell'istanza bloccato — che è ciò che i clienti hanno segnalato. # Mitigation # Harness ha completato i seguenti passi di mitigazione immediata: * Identificata la pipeline e il modello di espressione responsabile della risoluzione di fuga. * Ha bloccato l'istanza di servizio interessata in modo che non richiedesse ulteriori lavori. Le rimanenti istanze sane hanno raccolto ed elaborato le esecuzioni in coda normalmente. * Confermato che le esecuzioni di pipeline sono tornate alla normalità e hanno chiuso l'incidente. Queste azioni hanno ripristinato il normale comportamento di esecuzione delle tubazioni e hanno risolto l'impatto rispetto al cliente. # Action Items # Per ridurre il rischio di ricorrenza e migliorare il rilevamento, le seguenti azioni sono in varie fasi di attuazione: * Fissare il difetto nella profondità dell'espressione e salvaguardare il loop-detection in modo che le espressioni auto-referenziali sono catturate e falliscono velocemente con un errore chiaro invece di consumare risorse senza limiti. * Prevenire che le espressioni di carico utile vengano risolte dal contenuto di payload del trigger, rimuovendo completamente il percorso auto-referenziale. * Tendere la massima profondità di nidificazione dell'espressione e valutare il rilevamento esplicito del loop oltre al limite di profondità esistente. * Migliorare i test automatizzati in ambienti pre-produzione che riproducono modelli di espressione auto-referenziale e verificare che la salvaguardia li rileva e li ferma. * Aggiungi monitoraggio per questo modello nelle esecuzioni pipeline in modo che venga rilevato proattivamente.
Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.
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.
Stiamo attualmente indagando su questo problema.
Una soluzione è stata implementata e stiamo monitorando i risultati.
Questo incidente è stato risolto.
Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.
Stiamo attualmente indagando su questo problema.
Il problema è stato identificato e si sta attuando una correzione.
Una soluzione è stata implementata e stiamo monitorando i risultati.
Questo incidente è stato risolto.
# Summary # Tra il 25 luglio e il 4 agosto 2026, i cruscotti per l'esecuzione delle condotte e le pagine panoramiche dei cluster Harness Prod 2 e Prod 3 hanno mostrato i dati che erano tra dietro in tempo reale. I Pipelines stessi continuarono a costruire, distribuire ed eseguire normalmente durante tutto il corso; il problema era limitato a quanto rapidamente i record di esecuzione sono stati copiati nel database che serve la visualizzazione di report e dashboard. **Nessun dato del cliente è stato perso.** Ogni record interessato è rimasto duramente memorizzato e è stato riprodotto nel datastore di analisi una volta che la limitazione sottostante è stata rimossa. Harness migrava i cluster interessati ad una versione scalabile e in coda del componente di replica il 1o agosto 2026 e completava le schede di dati mirate per tutti gli account interessati. ♪Root cause ♪ Harness mantiene un componente di change-data-capture che replica continuamente i record di esecuzione delle tubazioni dal datastore operativo primario in un datastore di serie temporale separato ottimizzato per dashboard e query di reporting. Dashboards letto esclusivamente dal datastore di analisi. Quando la replicazione cade dietro, i cruscotti rendono una visione accurata ma più vecchia del mondo, mentre l'esecuzione stessa non è influenzata. Ciò è stato causato da un forte aumento del volume di scrittura del database da un altro modulo di piattaforma di Harness che condivide lo stesso percorso di replica ha superato il soffitto di throughput della versione precedente, single-instance di quel componente ancora in esecuzione in Prod 2 e Prod 3. Un backlog formato e cresciuto. # Azioni preventive # L'armonia ha completato o commesso le seguenti azioni per prevenire tali problemi. Traduzione: | --- | Fine sintonizzare l'avviso di replica in modo che qualsiasi ritardo oltre una soglia definita venga notificato | | Aggiungi un pannello di replica lag al pannello di monitoraggio della piattaforma standard in modo che la salute del gasdotto sia visibile a on-call per impostazione predefinita | | Ridurre l'amplificazione di scrittura da moduli co-tenant attraverso la limitazione della velocità per-module o il filtraggio dell'entità sul flusso di replica |
Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.
Stiamo attualmente indagando su questo problema.
Il problema è stato identificato e si sta attuando una correzione.
Una soluzione è stata implementata e stiamo monitorando i risultati.
Questo incidente è stato risolto.
# **Summary** On July 31, 2026, artifact uploads performed through pipeline in the EU1 cluster began failing with an authentication error. Uploads initiated manually \(outside of a pipeline\) were not affected, and the ability to retrieve existing artifacts \(downloads\) was also unaffected — this was isolated to the specific pipeline upload path in one cluster. # **Impact** * Artifact uploads performed through pipeline in the EU1 cluster failed with an authentication error for approximately 4 hours and 34 minutes. * Retrieving existing artifacts \(downloads\) was not affected. * Manually uploading artifacts outside of a pipeline was not affected. * Other clusters/regions were not affected by this issue. # **Root Cause** The component responsible for handling pipeline-based artifact uploads is distributed as a container image. In the EU1 cluster, this image is retrieved from an internal registry that mirrors a public image source; in other clusters, the same image is retrieved directly from the public source. A publishing error in our release process caused a new build of this component to be published using a version label that was already in use, rather than being assigned a new, unique version. As a result, two different images ended up associated with the same version label in the public source. Our internal registry mirrors images from the public source via an automated replication process. Because of how that replication was triggered, it copied the original \(earlier\) image associated with that version label rather than the corrected one. This meant the EU1 cluster — which pulls from the internal mirror — ended up running a different, defective image than other clusters, which pull directly from the public source and therefore received the corrected image. The defective image contained an authentication issue that caused pipeline uploads to fail. # **Mitigation** * Reverted the affected account to the last known-good version of the upload component, immediately restoring pipeline uploads. * Published a corrected, permanent version of the component to resolve the issue across all clusters. # **Next steps** * Fix the upload step to remove the underlying container-related defect that made this failure mode possible. * Update our release pipeline for this component so that publishing an image can never overwrite an existing version — every publish must create a new, distinct version going forward.
Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.
Sommario - Siamo in grado di affrontare intermittentemente i problemi di connettività di rete con il nostro Build VM non è in grado di connettersi a risorse esterne. Stiamo indagando sul problema.
Una soluzione è stata implementata e stiamo monitorando i risultati.
Stiamo continuando a monitorare eventuali ulteriori problemi.
Questo incidente è stato risolto.
## 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..
Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.
Stiamo attualmente indagando su questo problema.
Una soluzione è stata implementata e stiamo monitorando i risultati.
Questo incidente è stato risolto.
Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.
Stiamo attualmente indagando su questo problema.
Stiamo continuando a indagare su questo problema.
Il problema è stato identificato e si sta attuando una correzione.
Stiamo continuando a lavorare per risolvere questo problema.
Una soluzione è stata implementata e stiamo monitorando i risultati.
Stiamo continuando a monitorare eventuali ulteriori problemi.
Questo incidente è stato risolto.
# Summary During a recent production deployment, a defect in our internal deployment tooling caused two critical services to run with incorrect, non-production configuration values in our production environment This led to a related set of four distinct symptoms: incorrect configuration behavior, intermittent login/access failures, a filestore access issue affecting one customer environment, and delayed pipeline status updates in the UI. We have identified and are implementing a permanent fix for the underlying configuration defect, and have already put in place resource and capacity changes that resolve the UI delay symptom. At no point during this incident were pipeline executions themselves lost, corrupted, or left in a stuck state. Where execution behavior was affected, it was limited to delays in status visibility, not in the underlying processing. # Incident Details ## Incorrect Production Configuration Values Applied Our engineering team confirmed a defect in the Service Manager deployment pipeline that caused certain production services to be deployed using configuration values intended for a different environment, rather than the correct production configuration. **Root Cause** The service responsible for fetching configuration overrides during deployment queries an internal API that returns a maximum of 1,000 results per request. The total number of services in the environment recently grew beyond that limit. As a result, any service beyond the first 1,000 returned was not included in the response, and the deployment pipeline silently fell back to default configuration values for those services. This is a confirmed pagination defect in the deployment tooling, not an issue with the configuration values themselves. **Resolution** Engineering has confirmed the mechanism and is implementing a permanent fix to remove this limit-related gap in the deployment pipeline. ## Intermittent Login / Access Failures During the Service Manager deployment referenced above, some users experienced intermittent login or access failures. Under normal operation, previously running instances should continue serving traffic without interruption while a new deployment is in progress. In this incident, that fallback behavior did not occur as expected, contributing to access failures during the deployment window. ## Filestore Access Issue A filestore access issue was identified that was specific to the Prod-3 environment and affected a single customer's environment. **Root Cause** This is related to an IAM / storage-bucket permission configuration on Service Manager, potentially triggered by rollback activity. ## Delayed Pipeline Execution Status Updates in UI Some users observed that the pipeline execution graph in the UI was slow to refresh and did not reflect the latest status promptly. Importantly, this was a visibility delay only: there was no impact to actual pipeline executions, and no executions were stuck or failed as a result of this issue. **Root Cause** The pipeline execution graph relies on a message stream \(the orchestration log\) to receive status updates. During the incident window, consumer processing of this stream fell behind \(high consumer lag\), which delayed how quickly status updates reached the UI. This was caused by the fact that the underlying database was in the middle of a planned scaling operation at the same time, and a traffic spike during that window further exacerbated the delay. Users experienced this as apparent pipeline slowness, even though the underlying executions were running normally. **Resolution** We have increased resource capacity for the affected components to maintain more than 50% spare headroom going forward, reducing sensitivity to similar load spikes. This change has been implemented and is currently being validated as part of longer-term hardening for this part of the platform. # Impact Summary * Service Manager and License Manager ran with incorrect configuration values in the Prod-1 and Prod-3 environments. * Some users experienced intermittent login or access failures during the affected deployment window. * One customer environment in Prod-3 experienced a filestore access issue. * Users across affected environments saw delayed pipeline execution status updates in the UI; underlying pipeline executions continued to run correctly and were not lost, stuck, or corrupted. # Preventive Actions The following corrective and preventive actions have been identified. | **Corrective / Preventive Action** | | --- | | Correct the pagination limit in the configuration-lookup service so that all services are returned and evaluated, regardless of total count. | | Add safeguards so that a service which cannot retrieve its configuration fails safely \(e.g. alerts and blocks the deployment\) rather than silently falling back to non-production defaults. | | Increase Postgres and messaging-pipeline resource headroom \(target: greater than 50% spare capacity\) to reduce sensitivity to concurrent load and scaling events. | _We recognize the impact this incident had across multiple areas of the platform and appreciate your patience as we work through a complete resolution._
Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.
Stiamo indagando su un problema che influisce sui cruscotti AIDI. Gli utenti possono sperimentare maggiori tempi di carico o guasti intermittenti durante l'accesso ai dashboard. Il nostro team sta lavorando attivamente per identificare la causa principale e ripristinare le prestazioni normali. Forniremo aggiornamenti come ulteriori informazioni diventano disponibili.
Il problema è stato identificato e si sta attuando una correzione.
Una soluzione è stata implementata e stiamo monitorando i risultati.
Questo incidente è stato risolto.
# I clienti sui cluster Prod1, Prod2, e Prod3 hanno sperimentato guasti di carico dei widget intermittenti e un aumento dei tempi di carico quando si accede ai dashboard AIDI 2.0 il 22 luglio 2026. Non tutti i widget sono stati colpiti simultaneamente il problema si è manifestato come errori sporadici piuttosto che un outage completo. Nessun dato del cliente è stato perso. I clienti SEI 1.0 non hanno avuto un impatto. # Causa radice # Nel corso del tempo, un processo di manutenzione del database di routine non è riuscito a funzionare su alcune tabelle nel nostro database di analisi, causando tali tabelle di accumulare un grande volume di metadati interni utilizzati per monitorare i record cancellati. Quando il database ha pianificato le domande contro queste tabelle, ha caricato tutti questi metadati accumulati in memoria, causando l'utilizzo della memoria sui nodi colpiti a picco ripetutamente. Queste punte ripetute hanno innescato un meccanismo di sicurezza automatico che riavvia un nodo quando rileva eccessiva pressione della memoria, e i nodi colpiti hanno iniziato a riavviare in un loop di conseguenza. Ciò ha causato le prestazioni intermittenti e degradate di query sui dashboard AIDI 2.0 per la durata dell'incidente. ## Impact I clienti su cluster Prod1, Prod2, e Prod3 possono avere sperimentato guasti di carico dei widget intermittenti o tempi di carico aumentati sui dashboard AIDI 2.0. **Durata:** 22 luglio 2026, 07:58 PDT – 16:16 PDT \(~8 ore 18 minuti\), con guasti dei widget intermittenti; sistema è stato riavviato e sotto monitoraggio attivo dalle 08:25 PDT in poi. ### Che cosa non è stato influenzato? * Ingestione e trattamento dei dati * clienti SEI 1.0 * Integrazioni e flussi di metadati Nessun dato del cliente è stato perso. ## Remediation Al momento dell'identificazione del problema, i nodi del database interessati sono stati riavviatiti alle 08:25 PDT, che ha ripristinato la stabilità iniziale. Abbiamo continuato a monitorare attentamente il sistema, e quando il degrado intermittente è stato ancora osservato in seguito, abbiamo applicato diverse correzioni aggiuntive: * Impostazioni di configurazione del database regolate per limitare la quantità di memoria utilizzata per l'elaborazione di metadati accumulati e impostazioni di pianificazione delle query sintonizzate per ridurre la pressione della memoria. * Lavori di pulizia casuale per ridurre il backlog di metadati accumulati sulle tabelle interessate. * Capacità aumentata sui nodi di base interessati per fornire ulteriori headroom. Questi cambiamenti stabilizzarono progressivamente il sistema, e l'incidente fu completamente risolto a 16:16 PDT. ## Elementi di azione Per evitare il ripetersi, stiamo implementando: 1. Abbiamo aggiornato il backend che include miglioramenti sottostanti che gestiscono le punte di memoria causate da file di cancellazione eccessiva. 2. Abbiamo implementato lavori di compattazione automatizzati per le tabelle appena introdotte per impedire l'accumulo di file eliminando in futuro.
Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.
Stiamo attualmente indagando su questo problema.
Il problema è stato identificato e si sta attuando una correzione.
Una soluzione è stata implementata e stiamo monitorando i risultati.
Questo incidente è stato risolto.
# Sommario Il 17 luglio 2026, a seguito di una distribuzione di codice di routine, i clienti sulle versioni precedenti del delegato \(858xx e seguenti\) hanno iniziato a sperimentare le costruzioni CI ritardate su Harness Cloud-hosted costruisce utilizzando la nostra capacità di build-queueing globale. Le costruzioni colpite hanno sperimentato una pausa inaspettata fino a circa 8 minuti nella fase "di attesa per l'infrastruttura" prima di continuare, piuttosto che procedere entro la prossima volta prevista. Nel complesso la lentezza della costruzione era intermittente. # Impact # * Tutte le costruzioni CI sono state potenzialmente soggette a ritardo; l'impatto è stato più pronunciato per le costruzioni sull'infrastruttura ospitata da Harness Cloud utilizzando la funzione di build-queueing globale. * Le costruzioni colpite hanno sperimentato una pausa inspiegabile fino a circa 8 minuti prima di continuare, seguita da un "inizio freddo" più lento in quanto una slot di calcolo pre-riservato non era disponibile - questo ha presentato agli utenti come lente costruisce piuttosto che costruire guasti. * I conti in esecuzione su nuove versioni del delegato \(858xx e sopra\) non sono stati influenzati. * Nessuna costruzione ha fallito in modo diretto a causa di questo problema, e nessun dato è stato perso. # Causa della radice # La causa principale era un cambiamento di codice interno che inavvertitamente ha rotto come un record di build-queueing specifico è stato letto di nuovo dal nostro database una volta che costruisce che era già stato in coda sotto la versione precedente del codice incontrato la nuova versione distribuita. Abbiamo risolto l'impatto immediato ripulindo i record interessati e ripristinando il cambiamento di codice sottostante, e stiamo implementando diverse salvaguardie per evitare che questa classe di emissione si ripeta. # I prossimi passi # Noi valutiamo il rischio di una simile ricorrenza in quanto le seguenti azioni sono sottoposte. Il percorso di codice specifico che ha causato questo incidente è già stato deviato, e stiamo implementando salvaguardie strutturali in modo che questa classe generale di problema non possa ripetersi, indipendentemente da dove nella base di codice potrebbe altrimenti verificarsi. | ** Azione dominante/preventiva ** | | --- | Aggiungi identificatori espliciti e stabili a tutte le classi di dati interne che vengono memorizzate nel nostro database, in modo che le future riorganizzazione del codice interno non possano rompere la capacità del sistema di leggere i record precedentemente memorizzati. # | Introdurre test di rollback e retrocompatibilità nel nostro ambiente di pre-produzione, specificamente progettato per catturare questa classe di problema prima che raggiunga la produzione. #
Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.
Stiamo attualmente indagando su questo problema.
Il problema è stato identificato e si sta attuando una correzione.
Una soluzione è stata implementata e stiamo monitorando i risultati.
Stiamo continuando a monitorare eventuali ulteriori problemi.
Questo incidente è stato risolto.
# Sommario Tra il 19 giugno e il 17 luglio 2026, il passaggio Git Clone incorporato — e qualsiasi passo pipeline utilizzando il plugin clone drone-git — non è riuscito su ARM64 Kubernetes costruire infrastrutture con l'errore exec /usr/local/bin/clone: errore di formato exec. AMD64 \(Intel/AMD\) costruisce, Windows costruisce, e il percorso binario senza container VM non sono stati colpiti. La causa principale è stato un difetto nel nostro processo di pubblicazione di immagini interne che ha causato le immagini del drone-git ARM64-tagged per contenere effettivamente i binari AMD64. Abbiamo identificato e mitigato il problema lo stesso giorno in cui è stato segnalato ritorcendo l'immagine del drone-git all'ultima versione nota-buona. Non è stata richiesta alcuna modifica dell'azione del cliente o della configurazione. # Causa della radice # Il 19 giugno 2026, una bonifica di sicurezza ristrutturato come l'immagine del drone-git è costruita. Le build AMD64 sono state aggiornate correttamente, ma la pipeline di build ARM64 non ha costruito direttamente i file ARM64 — ha adattato il file di build AMD64 tramite la sostituzione del testo e l'ha compilato sull'infrastruttura ARM64. Il cambiamento del 19 giugno ha modificato il file AMD64 in modo che la sostituzione silenziosamente no-op'd invece di fallire, così il pipeline ha pubblicato un'immagine taggata ARM64 i cui binari Git Clone e Git LFS sono stati ancora compilati per AMD64. # Impact # * Interessato: Il passo Git Clone integrato, e qualsiasi passo pipeline utilizzando il plug-in clone del drone-git, in esecuzione su ARM64 Kubernetes costruire infrastrutture, in tutti i conti, tra il 6 luglio e il 17 luglio 2026. * Sintomo: Builds ha fallito nella fase Git Clone con exec /usr/local/bin/clone: errore di formato exec. * Non interessato: AMD64 \(Intel/AMD\) Kubernetes e VM costruisce, Windows costruisce, il percorso di esecuzione senza container VM, e la nostra variante di immagine indurita. # Mitigation Abbiamo reindirizzato la versione dell'immagine del drone-git utilizzata in tutti i servizi interessati all'ultima versione nota-buona. Ciò ha completamente risolto i guasti di esecuzione ARM64; non sono state richieste modifiche di configurazione del cliente. # I prossimi passi # Per evitare che tali problemi accadano di nuovo. * Ricostruisci il pipeline di pubblicazione di immagini ARM64 per costruire i nostri file ARM64 dedicati, piuttosto che adattare i file di build AMD64. * Migliora la validazione automatizzata post-pubblica ad ogni rilascio dell'immagine: verifica l'architettura binaria corrisponde al tag dell'immagine, e eseguire un test di fumo funzionale prima che un'immagine sia considerata rimovibile. * Espandi la copertura di test automatizzata per includere scenari di costruzione di ARM64 Kubernetes. * Rimuovere le versioni di immagine intermedia interessate dalla circolazione una volta che il rilascio corretto è convalidato.
Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.