82 Split incidents · aprile 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.
# Sommario Durante una recente distribuzione di produzione, un difetto nel nostro strumento di distribuzione interna ha causato due servizi critici da eseguire con valori di configurazione errati e non produttivi nel nostro ambiente di produzione Ciò ha portato a un insieme correlato di quattro sintomi distinti: comportamento di configurazione errato, guasti intermittenti di login / accesso, un problema di accesso di filetore che interessa un ambiente cliente, e aggiornamenti di stato pipeline ritardati nell'interfaccia utente. Abbiamo identificato e stiamo implementando una correzione permanente per il difetto di configurazione sottostante, e abbiamo già messo in atto le modifiche di risorse e capacità che risolvono il sintomo di ritardo dell'interfaccia utente. A nessun punto durante questo incidente erano esecuzioni stesse perse, corrotte, o lasciate in uno stato bloccato. Dove il comportamento di esecuzione è stato interessato, è stato limitato a ritardi nella visibilità dello stato, non nel trattamento sottostante. # Dettagli incidenti ## Valori di configurazione di produzione non corretti applicati Il nostro team di ingegneri ha confermato un difetto nella pipeline di distribuzione Service Manager che ha causato alcuni servizi di produzione da distribuire utilizzando valori di configurazione destinati ad un ambiente diverso, piuttosto che la corretta configurazione di produzione. ♪Root Cause ♪ Il servizio responsabile dell'acquisizione della configurazione sovrascrive durante le domande di distribuzione un'API interna che restituisce un massimo di 1.000 risultati a richiesta. Il numero totale di servizi nell'ambiente è cresciuto di recente oltre tale limite. Di conseguenza, qualsiasi servizio al di là dei primi 1.000 restituiti non era incluso nella risposta, e la pipeline di distribuzione silenziosamente cadde ai valori di configurazione di default per quei servizi. Questo è un difetto di impaginazione confermato nel tooling di distribuzione, non un problema con i valori di configurazione stessi. # Risoluzione # L'ingegneria ha confermato il meccanismo e sta implementando una fissazione permanente per rimuovere questo gap relativo ai limiti nella pipeline di distribuzione. ## Intermittent Login / Access Falls Durante l'implementazione di Service Manager di cui sopra, alcuni utenti hanno sperimentato errori di login intermittenti o di accesso. In base al normale funzionamento, le istanze precedentemente in esecuzione dovrebbero continuare a servire il traffico senza interruzioni mentre una nuova distribuzione è in corso. In questo incidente, quel comportamento fallback non si è verificato come previsto, contribuendo a accessi guasti durante la finestra di distribuzione. ## Filestore Access Problema Un problema di accesso di filetore è stato identificato che era specifico per l'ambiente Prod-3 e ha interessato un singolo ambiente del cliente. ♪Root Cause ♪ Questo è relativo a una configurazione di autorizzazione IAM / storage-bucket su Service Manager, potenzialmente innescato da attività rollback. ## Aggiornamenti dello stato di esecuzione dell'esecuzione del tubo in ritardo nell'interfaccia utente Alcuni utenti hanno osservato che il grafico di esecuzione della pipeline nell'interfaccia utente era lento a rinfrescare e non ha riflettuto lo stato più recente prontamente. Importante, questo è stato solo un ritardo di visibilità: non c'è stato alcun impatto sulle esecuzioni di pipeline reali, e nessuna esecuzione è stata bloccata o fallita a seguito di questo problema. ♪Root Cause ♪ Il grafico di esecuzione pipeline si basa su un flusso di messaggi \(il registro di orchestrazione\) per ricevere aggiornamenti di stato. Durante la finestra incidente, l'elaborazione dei consumatori di questo flusso è caduta dietro \(high consumer lag\), che ha ritardato quanto rapidamente gli aggiornamenti di stato raggiunto l'interfaccia utente. Ciò è stato causato dal fatto che il database sottostante era nel mezzo di un'operazione di scaling pianificata allo stesso tempo, e un picco di traffico durante quella finestra ulteriormente esacerbato il ritardo. Gli utenti hanno sperimentato questo come apparente lentezza del gasdotto, anche se le esecuzioni sottostanti erano in esecuzione normalmente. # Risoluzione # Abbiamo aumentato la capacità delle risorse per i componenti interessati a mantenere più del 50% di spazio di riserva in avanti, riducendo la sensibilità a punte di carico simili. Questo cambiamento è stato implementato e attualmente viene convalidato come parte di indurimento a lungo termine per questa parte della piattaforma. # Impact Sintesi * Service Manager e License Manager hanno eseguito con valori di configurazione errati negli ambienti Prod-1 e Prod-3. * Alcuni utenti hanno sperimentato accessi intermittenti o guasti di accesso durante la finestra di distribuzione interessata. * Un ambiente cliente in Prod-3 ha sperimentato un problema di accesso di filetore. * Gli utenti di ambienti interessati hanno visto ritardati aggiornamenti dello stato di esecuzione delle tubazioni nell'interfaccia utente; le esecuzioni delle pipeline sottostanti hanno continuato a funzionare correttamente e non sono stati persi, bloccati o corrotti. # Azioni preventive Sono state identificate le seguenti azioni correttive e preventive. | ** Azione dominante/preventiva ** | | --- | Correggere il limite di paginazione nel servizio di configurazione-lookup in modo che tutti i servizi vengano restituiti e valutati, indipendentemente dal conteggio totale. | Aggiungi salvaguardie in modo che un servizio che non riesce a recuperare la sua configurazione fallisca in modo sicuro \(ad esempio avvisi e blocchi il dispiegamento\) piuttosto che cadere silenziosamente di default non di produzione. # | Aumentare le caselle postali e l'intestazione delle risorse di messaggistica \(target: maggiore del 50% di capacità di riserva\) per ridurre la sensibilità agli eventi di carico e scaling concomitanti. # Riconosciamo l'impatto che questo incidente ha avuto su più aree della piattaforma e apprezziamo la vostra pazienza mentre lavoriamo attraverso una risoluzione completa.
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.
## Summary Customers on Prod1, Prod2, and Prod3 clusters experienced intermittent widget load failures and increased load times when accessing AIDI 2.0 dashboards on July 22, 2026. Not all widgets were affected simultaneously the issue manifested as sporadic failures rather than a full outage. No customer data was lost. SEI 1.0 customers were not impacted. ## Root Cause Over time, a routine database maintenance process failed to run on certain tables in our analytics database, causing those tables to accumulate a large volume of internal metadata used to track deleted records. When the database planned queries against these tables, it loaded all of this accumulated metadata into memory, causing memory usage on the affected nodes to spike repeatedly. These repeated spikes triggered an automatic safety mechanism that restarts a node when it detects excessive memory pressure, and the affected nodes began restarting in a loop as a result. This caused intermittent, degraded query performance on AIDI 2.0 dashboards for the duration of the incident. ## Impact Customers on Prod1, Prod2, and Prod3 clusters may have experienced intermittent widget load failures or increased load times on AIDI 2.0 dashboards. **Duration:** July 22, 2026, 07:58 PDT – 16:16 PDT \(~8 hours 18 minutes\), with intermittent widget failures; system was restarted and under active monitoring from 08:25 PDT onward. ### What was not impacted? * Data ingestion and processing * SEI 1.0 customers * Integrations and metadata flows No customer data was lost. ## Remediation Upon identifying the issue, the affected database nodes were restarted at 08:25 PDT, which restored initial stability. We continued to monitor the system closely, and when intermittent degradation was still observed afterward, we applied several additional fixes: * Adjusted database configuration settings to limit the amount of memory used for processing accumulated metadata, and tuned query-planning settings to reduce memory pressure. * Ran cleanup jobs to reduce the backlog of accumulated metadata on the affected tables. * Increased capacity on the affected database nodes to provide additional headroom. These changes progressively stabilized the system, and the incident was fully resolved at 16:16 PDT. ## Action Items To prevent recurrence, we are implementing the following: 1. We have upgraded the backend which includes underlying improvements that handle memory spikes caused by excessive delete files. 2. We have rolled out automated compaction jobs for newly introduced tables to prevent delete file accumulation going forward.
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.