Cronologia delle interruzioni di Uipath

1. 28 ottobre 2026 alle ore 10:04 UTCinvestigating

   Stiamo indagando su una maggiore latenza e ritardi nell'esecuzione del lavoro all'interno del servizio dell'orchestratore nella regione Europa. Il nostro team sta lavorando attivamente per identificare la causa principale e fornirà ulteriori aggiornamenti come ulteriori informazioni diventano disponibili.

2. 28 ottobre 2026 alle ore 10:28 UTCmonitoring

   Il problema è stato mitigato, e stiamo monitorando il servizio per garantire la stabilità.

3. 28 ottobre 2026 alle ore 11:15 UTCresolved

   Il problema è stato risolto, e il servizio orchestratore funziona normalmente.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 27 ottobre 2026 alle ore 16:39 UTCresolved

   Il 27 ottobre 2026, tra le 14:35 e le 16:08 UTC, la Comprensione dei documenti nella regione Europa ha sperimentato un'estrazione parziale che riguarda l'estrazione generativa, la classificazione generativa e l'autovalida. La causa principale era un problema di connettività con un fornitore di storage di terze parti. La connettività è stata ripristinata e abbiamo confermato che l'estrazione e la classificazione funzionano normalmente dalle 16:08 UTC.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 26 ottobre 2026 alle ore 14:04 UTCidentified

   Stiamo attualmente indagando su un problema che influisce sulla disponibilità di informazioni e servizi ops di automazione. Il nostro team sta valutando attivamente la situazione per identificare la causa sottostante e determinare i passaggi necessari per ripristinare le operazioni normali. Ulteriori aggiornamenti saranno forniti come ulteriori informazioni diventano disponibili.

2. 26 ottobre 2026 alle ore 15:35 UTCidentified

   Il problema con Automation Ops è stato risolto. Stiamo attualmente aspettando che il problema del servizio Insights venga mitigato. Ulteriori aggiornamenti saranno condivisi come diventano disponibili.

3. 26 ottobre 2026 alle ore 17:09 UTCidentified

   Il servizio di informazioni a Singapore, Giappone, Svizzera, Canada, India, Regno Unito, Europa, Stati Uniti, UAE, Corea del Sud e Australia è fisso e stiamo applicando correzioni su altre regioni

4. 26 ottobre 2026 alle ore 18:27 UTCresolved

   Il problema è stato risolto, e tutti i servizi sono ora operativi normalmente.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 27 ottobre 2026 alle ore 10:13 UTCresolved

   Il 26 ottobre 2026, tra le 10:20 e le 17:30 UTC, Automation Cloud Robots (VM) ha sperimentato un parziale outage che interessa le operazioni della macchina. Durante questa finestra, azioni come l'avvio, l'arresto o la fornitura di macchine VM potrebbero non essere state completate, e i lavori programmati su tali macchine potrebbero essere stati ritardati o danneggiati. La causa era un permesso di cattiva configurazione su un sottoinsieme delle risorse infrastrutturali sottostanti. Il nostro team ha identificato il problema, corretto la configurazione, e ha confermato che le operazioni della macchina funzionano normalmente dalle 17:30 UTC. Stiamo valutando come è stata introdotta la cattiva configurazione e stiamo aggiungendo dei controlli per evitare una ricorrenza. Nessuna azione è richiesta dalla vostra parte. Se si vedono ancora lavori falliti o bloccati da quella finestra, si prega di riprovarli, e il supporto di contatto se il problema persiste.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 23 ottobre 2026 alle ore 21:35 UTCresolved

   Tra 20:42 e 21:19 UTC il 23 ottobre, alcuni clienti dell'Orchestrator in Europa hanno visto risposte lente e errori intermittenti. Questo includeva chiamate robot per ottenere beni, elementi di coda di processo e lo stato di lavoro di rapporto. Alcuni lavori incustoditi potrebbero aver fallito in questo periodo. La causa è stata un improvviso aumento del carico che ha raggiunto i limiti delle risorse del database. Abbiamo aggiunto la capacità del database, e le prestazioni è tornato alla normalità dal 21:19 UTC. I clienti i cui lavori sono falliti in questa finestra potrebbero aver bisogno di riavviarli.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 22 ottobre 2026 alle ore 12:59 UTCinvestigating

   Abbiamo identificato un problema che riguarda IXP per i clienti ospitati nella regione Australia. Dal 10:24 UTC, le richieste che utilizzano il modello Gemini 2.5 Flash stanno fallendo nella regione. Altri modelli non sono interessati. I dati dei clienti continuano ad essere trattati solo in Australia. Stiamo lavorando con Google per ripristinare il servizio

2. 22 ottobre 2026 alle ore 14:19 UTCmonitoring

   Una correzione è stata implementata e il servizio sta recuperando. Stiamo monitorando il sistema per garantire il pieno recupero. Ulteriori aggiornamenti saranno condivisi presto

3. 22 ottobre 2026 alle ore 14:33 UTCinvestigating

   Dopo il recupero iniziale, il servizio è nuovamente degradato. Stiamo indagando e lavorando verso una risoluzione. Forniremo ulteriori aggiornamenti mentre diventano disponibili.

4. 22 ottobre 2026 alle ore 15:42 UTCinvestigating

   Abbiamo contattato Google Support e hanno iniziato a indagare sulla loro fine. Continueremo a monitorare e condividere gli aggiornamenti come li abbiamo.

5. 22 ottobre 2026 alle ore 17:56 UTCmonitoring

   Stiamo osservando miglioramenti sul traffico Gemini 2.5 Flash. Stiamo monitorando una possibile correzione da Google.

6. 22 ottobre 2026 alle ore 21:02 UTCresolved

   Il problema è risolto da Google.

7. 26 ottobre 2026 alle ore 03:20 UTCpostmortem

   ## Impatto del cliente Tra il 22 ottobre 2026 alle ore 10:24 UTC e il 22 ottobre 2026 alle ore 18:04 UTC, richieste di elaborazione dei documenti che hanno usato Gemini 2.5 Flash nella regione Australia fallito con errori di capacità. L'impatto è durato circa 7 ore e 40 minuti. Un sottoinsieme di clienti che utilizzano i flussi di lavoro di estrazione di documenti in quella regione sono stati colpiti. Durante un tentativo temporaneo di in-regione fallback, alcune richieste di estrazione recuperato brevemente, ma l'attribuzione di livello di parola e il testo di pagina generato sono stati degradati fino a quando il fallback anche ha cominciato a fallire. # La causa principale era una disgregazione di rete regionale lato fornitore durante la manutenzione corrente. Ciò ha causato una grave limitazione della larghezza di banda nell'ambiente di manutenzione del modello del fornitore, che ha impedito ai sistemi di backend di caricare i dati del modello necessari per servire le richieste Gemini 2.5 Flash e Gemini 3.5 Flash in modo affidabile nella regione interessata. ## Detection Il problema è stato rilevato tramite avviso automatico che ha identificato errori di limitazione dei tassi su Gemini 2.5 Flash nella regione Australia. Il nostro team di ingegneria ha confermato attraverso la telemetria che le richieste colpite erano in fallimento costantemente e ha iniziato a coordinare una risposta. # A 1:40 pm UTC, abbiamo indirizzato il traffico Gemini 2.5 Flash a Gemini 3.5 Flash all'interno della stessa regione per preservare la residenza dei dati. La telemetria iniziale non ha mostrato errori di capacità dopo quel cambiamento, ma entro le 2:10 UTC, Gemini 3.5 Flash stava anche ritornando errori di capacità, quindi il fallback non era più possibile. Alle 2:05 UTC, abbiamo regolato i percorsi relativi di elaborazione dei documenti in modo che l'attribuzione e la generazione di pagina-testo userebbero lo stesso in-regione fallback; che la regolazione completata a circa 2:09 pm UTC. Dopo la caduta anche fallito, abbiamo reindirizzato il cambiamento di routing, e entro le 16:28 pm traffico UTC era tornato sul percorso Gemini 2.5 Flash previsto. Alle 17:38 UTC, la telemetria ha mostrato migliorare i tassi di successo Gemini 2.5 Flash. Dalle 18:04 UTC in poi, non sono stati osservati ulteriori errori di capacità, e le richieste successive sono succedute. ## Seguilo # 1. Completare la valutazione di capacità del modello riservato per la regione interessata utilizzando i modelli di traffico osservati 2. Valutare il comportamento di riprova e di backoff nei client di elaborazione dei documenti per ridurre l'amplificazione di riprovazione durante i guasti della capacità lato del fornitore.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 15 ottobre 2026 alle ore 12:27 UTCinvestigating

   Da circa 11:17 UTC, i clienti di diverse regioni hanno sperimentato problemi con UiPath Agents and Solutions Management. I nuovi posti di lavoro possono rimanere in Pending status, e gli agenti in esecuzione possono sperimentare ritardi durante l'elaborazione di escalation o in attesa di risultati degli strumenti. Stiamo indagando sul problema e stiamo lavorando verso una risoluzione.

2. 15 ottobre 2026 alle ore 13:04 UTCmonitoring

   Il problema è stato mitigato. Stiamo monitorando i servizi interessati in tutte le regioni per garantire la stabilità e confermare che l'avvio del lavoro e le implementazioni delle soluzioni funzionano normalmente.

3. 15 ottobre 2026 alle ore 13:22 UTCresolved

   Questo incidente è stato risolto. Tra le 11:15 e le 12:45 UTC il 15 ottobre, un problema di configurazione interna ha impedito ad alcuni eventi di essere consegnato tra i servizi UiPath in più regioni. Il problema è stato risolto rinviando il cambiamento, e la nuova attività viene elaborata normalmente. Alcuni lavori avviati o in corso durante questa finestra possono richiedere l'attenzione: - Agenti: Gli agenti in attesa delle attività di Action Center o dei risultati degli strumenti di automazione possono rimanere bloccati. I lavori iniziati da Orchestrator possono anche apparire bloccato o tempo libero. - Maestro: I processi in attesa delle attività degli utenti potrebbero non essere tornati dopo il completamento del compito. - Apps: Gli stati degli elementi di queue possono essere obsoleti e le azioni innescate dal completamento dell'elemento di coda potrebbero non essere state avviate. - Autopilota per tutti: le conversazioni in attesa dei risultati dell'automazione possono rimanere bloccate. - Comprensione e contestazione dei documenti: Automazioni e agenti in attesa di estrazione, validazione o indicizzazione possono rimanere sospesi. - Servizio di integrazione: gli eventi del connettore potrebbero non aver attivato i processi o le notifiche attesi. - Soluzioni e Studio Web: la soluzione installa, disinstalla, pubblica, distribuisce e le validazioni avviate durante questa finestra potrebbero essere fallite o timed out. Il ripristino di tali operazioni può risolvere il problema. Ci scusiamo per l'interruzione e vi ringraziamo per la vostra pazienza.

4. 21 ottobre 2026 alle ore 06:47 UTCpostmortem

   # L'impatto del cliente # Il 15 ottobre 2026, dalle 11:15 alle 12:50 UTC (circa 1 ora e 35 minuti), alcuni eventi scambiati tra i servizi cloud di UiPath non sono stati consegnati. I clienti in tutte le regioni cloud commerciali sono stati colpiti. Durante questa finestra: - I nuovi agenti potrebbero rimanere nello stato dei Pending. Agenti in esecuzione in attesa di un risultato di strumento, un'escalation umana, l'estrazione di documenti, o la messa a terra di contesto potrebbe non riprendere. - Agenti conversazionali e Autopilota per tutte le conversazioni che hanno iniziato un'automazione potrebbero non aver ricevuto il suo risultato. - Le istanze di processo Maestro in attesa di un'attività utente potrebbero non essere andate avanti dopo che l'attività è stata completata, e i processi innescati da eventi di connettore Integration Service potrebbero non essere iniziati. - Le applicazioni che mostrano o reagiscono allo stato dell'elemento di coda possono mostrare informazioni obsolete. - La soluzione installa, disinstalla, pubblica e le distribuzioni potrebbero fallire o time out. - Alcune modifiche dell'utente, del gruppo e della cartella effettuate nella finestra potrebbero non essere propagate a tutti i servizi. Il lavoro è iniziato dopo 12:50 UTC non è stato interessato. Esecuzione del lavoro robot, code e trigger gestiti all'interno dell'Orchestrator continuava a lavorare normalmente. "Root cause" Stavamo spostando la consegna della configurazione dei servizi interni a un nuovo meccanismo, una modifica destinata a non avere alcun effetto sui clienti. Quando questa modifica è stata applicata al servizio di consegna eventi, la configurazione che ha prodotto mancava di un valore richiesto. Senza di esso, il servizio ha trattato diverse integrazioni di prodotto come spento e silenziosamente smesso di fornire i loro eventi. Poiché il cambiamento ha raggiunto tutte le regioni di produzione allo stesso tempo, ogni regione è stata colpita. "Detection" Il problema è stato rilevato alle 11:51 UTC, circa 35 minuti dopo l'impatto iniziato, quando il monitoraggio ha avvertito i lavori di agente rimanenti nello stato di Pending. Seguono i rapporti delle implementazioni di soluzioni, e un incidente è stato dichiarato a 12:12 UTC. Responsabilità Dopo la prima rilevazione alle 11:51 UTC, la modifica di configurazione è stata identificata e un rollback è stato avviato alle 12:00 UTC. Un rollback iniziale a 12:14 UTC non ha completamente restaurato la consegna. Il team ha quindi interrotto il nuovo processo di consegna della configurazione e ha ripristinato la configurazione precedente. La consegna degli eventi ha cominciato a recuperare a 12:40 UTC, e il recupero completo in tutte le regioni è stato confermato a 12:50 UTC. Dove possibile, abbiamo riprodotto eventi persi in modo che il lavoro interessato potrebbe continuare. ♪Follow up ♪ 1. Il nuovo processo di consegna della configurazione è stato sospeso per il servizio interessato e rimarrà sospeso fino a quando la configurazione non viene generata correttamente. 2. Convalida configurazione prodotta dal nuovo meccanismo di consegna per i valori richiesti prima che venga applicato a qualsiasi ambiente. 3. Eseguire le modifiche alla consegna di configurazione progressivamente in tutte le regioni invece di in una sola volta. 4. Migliorare il nostro monitoraggio per rilevare in pochi minuti quando gli eventi smettono di essere consegnati a un'integrazione di prodotto che normalmente li riceve. 5. Migliorare la nostra capacità di recuperare e rideliver eventi persi durante una rottura.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 15 ottobre 2026 alle ore 12:03 UTCresolved

   Alcuni clienti della regione degli Stati Uniti hanno sperimentato ritardi nell'ingestione dei registri dei robot, con una maggiore attività osservata tra circa 11:20 e 11:45 UTC. Il problema è stato risolto e l'ingestione dei registri è tornata alla normalità. Grazie per la pazienza.

2. 22 ottobre 2026 alle ore 10:13 UTCpostmortem

   ## Impatto del cliente Tra circa il 15 ottobre 2026 alle 11:20 UTC e circa il 15 ottobre 2026 alle 11:45 UTC, alcuni clienti nella regione dell'est degli Stati Uniti hanno sperimentato ritardi nell'ingestione dei registri dei robot in UiPath Orchestrator. I registri dei robot non erano aggiornati durante il periodo interessato. L'impatto è durato circa 20 minuti. # Durante l'incidente, sono stati osservati 2 delle 13 istanze di servizio che gestivano l'ingestione del registro robot che non avevano accesso al servizio di ingestione dell'evento. Solo le richieste al servizio di ingestione dell'evento sono state fallite, e solo su questi due casi. Ciò ha causato alcune richieste di ingestione del registro robot di non completare con successo, con conseguente ritardo dei dati di registro per i clienti interessati. La causa principale del perché solo quei due casi hanno perso la connettività al servizio di ingestione eventi non è stato determinato durante l'incidente. Il team si è impegnato in una revisione post-incidente dei registri delle istanze interessate per identificare la causa sottostante. Crediamo che sia un problema di infrastruttura non segnalato dal nostro provider cloud. ## Detection Il problema è stato rilevato attraverso un avviso automatizzato a circa 11:33 UTC il 15 ottobre 2026, e confermato attraverso la telemetria che mostra eccezioni dalle due istanze di servizio colpite. # Dopo il rilevamento, la telemetria ha confermato che solo due istanze di servizio stavano generando eccezioni. I risponditori hanno rimosso quelle due istanze malsano dal servizio, e le istanze di sostituzione sono iniziate automaticamente. Entro circa 20 minuti del primo avviso — di circa 11:53 UTC — telemetria indicato il recupero e controlli sintetici sono stati di passaggio. Un più ampio riavvio di tutte le istanze di servizio è stato considerato ma non eseguito, come il team ha determinato che non dovrebbe procedere senza prima comprendere la causa principale. ## Seguilo # 1. Una revisione post-incidente dei registri delle istanze dei servizi interessati ha rivelato che il problema era relativo alle infrastrutture, e stiamo seguendo con il provider di infrastrutture cloud per maggiori dettagli. 2. Verrà pubblicato un aggiornamento se l'indagine fornisce ulteriori risultati.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 14 ottobre 2026 alle ore 07:26 UTCmonitoring

   A partire da 6:50 UTC abbiamo sperimentato un outage globale che ha interessato il caricamento di applicazioni e applicazioni codificate tutte le regioni tranne per India e Regno Unito. L'estrazione è stata risolta e i servizi sono pienamente operativi. Impatto: nessun impatto utente in corso.

2. 14 ottobre 2026 alle ore 07:43 UTCresolved

   A partire da 6:50 UTC abbiamo sperimentato un outage globale che ha interessato il caricamento di applicazioni e applicazioni codificate tutte le regioni tranne per India e Regno Unito. L'estrazione è stata risolta e i servizi sono pienamente operativi. Impatto: nessun impatto utente in corso.

3. 23 ottobre 2026 alle ore 12:08 UTCpostmortem

   ## Impatto del cliente Tra le 06:38 UTC e 07:21 UTC il 14 ottobre 2026, una parte delle richieste a UiPath Apps, Coded Apps, e soluzioni che dipendono da loro fallito in undici regioni: Europa, Stati Uniti, Comunità, Giappone, Singapore, Australia, Canada, Corea del Sud, Svizzera, Emirati Arabi Uniti, e l'ambiente ritardato degli Stati Uniti. Le regioni dell'India e del Regno Unito non sono state colpite. Circa il 2 per cento delle richieste ha fallito nel complesso, tra lo 0,6 e il 5 per cento a seconda della regione. Gli utenti interessati hanno visto che le applicazioni non riescono a caricare, richieste di errori del server di ritorno, o risposte lente. Nelle regioni in cui i baccelli di servizio dovevano essere riavviatititi, Apps era irraggiungibile fino a circa otto minuti. I tempi di risposta sono tornati alla normalità in ogni regione entro le 07:40 UTC. La maggior parte degli utenti di già in esecuzione applicazioni pubblicate notato poco o niente. Le definizioni delle applicazioni sono memorizzate nel browser per un massimo di 24 ore, i dati delle app provengono da Data Service e Orchestrator piuttosto che da questo database, e il servizio mantenuto utilizzando le connessioni del database che ha già tenuto. Le richieste fallite erano quelle che necessitavano di una nuova connessione del database: l'apertura del progettista o dell'elenco delle app, il caricamento di un'app non ancora memorizzata, il download di documenti e immagini archiviate in Apps, il salvataggio o la pubblicazione. # Alle 06:38 UTC, mentre l'accesso al database è stato impostato per una nuova distribuzione regionale, la password dell'utente del database che il servizio Apps utilizza è stato modificato. Tale utente è condiviso dai cluster di database di produzione di tutte le regioni interessate, quindi la modifica applicata a tutti loro in una sola volta. I servizi in esecuzione conservavano ancora la password precedente e non potevano più aprire nuove connessioni di database. Le regioni dell'India e del Regno Unito non utilizzano queste credenziali e non sono state interessate. Il cambiamento era destinato a creare un utente database separato per la nuova regione. Invece, la password dell'utente esistente che tutte le regioni condividono è stato cambiato. Il nostro processo di cambiamento per le credenziali del database non ha chiaramente separato la creazione di nuove credenziali dalla modifica di una esistente, e non ha richiesto un controllo di quanti cluster e regioni un cambiamento di credenziali influenzerebbe. Combinato con un singolo utente del database che è stato condiviso in tutte le regioni, questo ha permesso un cambiamento destinato ad una regione per causare un'estrazione multi-regione. ## Detection Il nostro monitoraggio interno ha sollevato la prima allerta alle 06:41 UTC, tre minuti dopo i primi fallimenti, e avvisi per ogni regione colpita seguito da 06:46 UTC. Alle 06:50 UTC l'ingegnere on-call ha confermato che ogni cluster di produzione è stato rifiutato dal suo database e ha avviato il processo di incidente. # Alle 07:05 UTC la password precedente è stata ripristinata e i guasti di autenticazione si sono fermati ovunque. La maggior parte delle regioni si ricollega automaticamente. Nelle regioni che non lo hanno fatto, i baccelli di servizio sono stati riavviatititi o ridistribuiti: Delayed US alle 07:21 UTC e Svizzera entro le 07:30 UTC. Richiesta fallimenti interrotti alle 07:21 UTC, tempi di risposta sono stati di nuovo alla base entro 07:40 UTC, e abbiamo continuato il monitoraggio fino a quando l'incidente è stato risolto alle 07:43 UTC. ## Seguilo # Per evitare che questo accada di nuovo, siamo: - Introdurre una procedura definita per la creazione e la rotazione delle credenziali del database, con una revisione di pre-cambiamento che stabilisce quali cluster e regioni condividono le credenziali, e un rollout scenico che viene verificato in una regione prima che venga applicato più ampiamente. - Trasferirsi a utenti di database meno privati per ogni regione, in modo che un cambiamento in una regione non possa influenzare un'altra. - Dichiara automaticamente un incidente e chiama i proprietari di database quando lo stesso errore di database viene rilevato in diverse regioni in una sola volta, invece di contare sull'escalation manuale da singoli avvisi regionali. - Abilitare i servizi di raccogliere le credenziali del database aggiornate senza riavviare, e riconnettersi più velocemente dopo un guasto di autenticazione.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 13 ottobre 2026 alle ore 14:03 UTCinvestigating

   Stiamo attualmente indagando su un outage che interessa i servizi UiPath Cloud in più regioni. Gli utenti non sono in grado di accedere ai servizi ospitati nelle regioni interessate. Prossimo aggiornamento: Ulteriori informazioni saranno condivise in quanto diventa disponibile.

2. 13 ottobre 2026 alle ore 14:37 UTCinvestigating

   Stiamo continuando a indagare su questo problema.

3. 13 ottobre 2026 alle ore 14:42 UTCinvestigating

   Una soluzione è stata implementata e stiamo monitorando i risultati. Il problema è stato limitato a Document Understanding, Computer Vision, Semantic Proxy, Autopilot Studi, IXP. Condivideremo un altro aggiornamento una volta che i servizi sono completamente recuperati.

4. 13 ottobre 2026 alle ore 15:10 UTCinvestigating

   Una soluzione è stata implementata e stiamo monitorando i risultati.

5. 13 ottobre 2026 alle ore 15:19 UTCresolved

   Questo incidente è stato risolto dopo il rinnovo del certificato SSL scaduto che ha interessato diversi servizi ML-dipendenti, tra cui IXP, Document Understanding, Computer Vision, Semantic Proxy e Autopilota per gli sviluppatori. Il recupero dei servizi è progredito in tutte le regioni interessate, e gli avvisi automatizzati sono stati configurati per aiutare a rilevare la scadenza del certificato in anticipo e prevenire interruzioni simili in futuro. Grazie per la vostra pazienza e comprensione.

6. 26 ottobre 2026 alle ore 03:17 UTCpostmortem

   ## Impatto del cliente Tra le 13:37 e le 14:40 UTC il 13 ottobre 2026, i clienti di diverse regioni non sono stati in grado di utilizzare documenti non strutturati IXP, IXP Communications Mining e Document Understanding. Computer Vision e Autopilota per le caratteristiche degli sviluppatori che dipendono dagli stessi servizi di machine learning anche fallito. I clienti interessati hanno visto le richieste fallite con le risposte "500 Internal Server Error" o il time out, i progetti IXP che non si aprivano, e le attività di Computer Vision che non hanno eseguito l'automazione. Il servizio è stato interrotto per circa 1 ora. Nessun dato del cliente è stato perso. # Causa radice # L'incidente è stato causato da un certificato di sicurezza scaduto utilizzato per stabilire connessioni sicure a questi servizi. Il certificato è rinnovato da un processo automatizzato. Tale processo non è più stato eseguito con successo e i guasti non hanno sollevato un avviso, quindi il certificato non è stato sostituito prima della sua scadenza. Le connessioni sicure ai servizi interessati sono state respinte da 13:37 UTC. ## Detection Il monitoraggio automatizzato ha iniziato l'avviso su errori e traffico mancante a 13:40 UTC, e l'incidente è stato dichiarato a 13:54 UTC. Il certificato scaduto è stato identificato a 14:00 UTC, e il primo aggiornamento della pagina di stato è stato pubblicato a 14:03 UTC. Nessun avviso ha avvertito che il certificato si stava avvicinando alla scadenza, e i ripetuti fallimenti del rinnovo automatico non sono stati segnalati al team di gestione, quindi il problema è stato rilevato solo una volta che i clienti sono stati colpiti. # Alle 14:06 UTC il team ha confermato che il certificato era scaduto perché il rinnovo automatico era in fallimento. A 14:18 UTC una nuova credenziali è stato rilasciato per il processo di rinnovo. Il rinnovo è stato avviato manualmente a 14:19 UTC e completato a 14:33 UTC, e entro 14:37 UTC ogni punto finale di cliente era stato verificato per servire il certificato rinnovato. Traffico restituito a livelli normali di circa 14:40 UTC. Dopo un periodo di monitoraggio, l'incidente è stato risolto a 15:19 UTC. ## Follow-Up Per evitare incidenti simili in futuro, stiamo facendo i seguenti miglioramenti: - Avvertire bene in anticipo qualsiasi di questi certificati che si avvicinano alla scadenza. - Informare il personale quando il rinnovo automatico fallisce. - Aggiungi i controlli che l'avviso non appena le connessioni sicure a questi servizi falliscono. - Rafforzare la proprietà del processo di rinnovo del certificato e le credenziali su cui si basa.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 13 ottobre 2026 alle ore 10:32 UTCinvestigating

   Stiamo indagando sul problema in cui i registri dell'esecuzione dei robot non vengono visualizzati in Orchestrator. stiamo lavorando per determinare la portata completa e la causa principale.

2. 13 ottobre 2026 alle ore 10:57 UTCresolved

   Questo problema è stato risolto. I registri di esecuzione robot sono sincronizzati e sono visibili in Orchestrator di nuovo per Japan Orchestrator. Grazie per la pazienza.

3. 22 ottobre 2026 alle ore 13:25 UTCpostmortem

   ## Impatto del cliente Tra circa 07:00 UTC il 9 Oct 2026 e 10:45 UTC il 13 Oct 2026, circa il 6% delle voci di registro robot per i clienti nella regione del Giappone non è apparso in Orchestrator. L'esecuzione del lavoro e tutte le altre funzionalità dell'Orchestratore non sono state influenzate. Le voci mancanti divennero visibili in Orchestrator dopo che il problema fu risolto. # I tronchi robot sono posizionati su una coda divisa in 32 partizioni, e un servizio di ingestione legge ogni partizione e memorizza i registri per Orchestratore. Il 9 ottobre, il servizio di ingestione nella regione del Giappone ha smesso di leggere da 2 delle 32 partizioni senza segnalare un errore. I registri su quelle partizioni sono stati tenuti in coda ma non memorizzati, quindi non sono comparsi in Orchestratore. Il nostro monitoraggio ha controllato il servizio nel suo complesso, non ogni partizione, quindi il problema non è stato rilevato automaticamente. ## Detection Il problema è stato rilevato attraverso i rapporti dei clienti. Abbiamo dichiarato un incidente a 10:13 UTC il 13 ottobre e postato una notifica pagina di stato a 10:32 UTC. # Abbiamo riavviato il servizio di ingestione a circa 10:41 UTC, e ha ripreso a leggere tutte le partizioni. I registri tenuti in coda sono stati poi elaborati e sono diventati visibili in Orchestratore. L'incidente è stato risolto alle 10:57 UTC. ## Seguilo # * Stiamo aggiungendo il monitoraggio che ci avvisa quando una singola partizione smette di essere letto, in modo che questo tipo di problema viene rilevato in pochi minuti.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 7 ottobre 2026 alle ore 21:34 UTCinvestigating

   Stiamo indagando sui rapporti di un'estrazione che influisce sui guasti della creazione di attività HITL per il Maestro negli Stati Uniti. Impatto: Gli utenti potrebbero non essere in grado di creare attività HITL. Prossimo aggiornamento: I nostri team stanno lavorando per capire la causa e la portata e condivideranno gli aggiornamenti come disponibile.

2. 8 ottobre 2026 alle ore 01:30 UTCidentified

   Abbiamo individuato la causa di un'interruzione che influisce sulla creazione di attività HITL per il Maestro negli Stati Uniti e stiamo lavorando per mitigare il problema. Impatto: Gli utenti potrebbero non essere in grado di creare attività HITL. Prossimo aggiornamento: I nostri team stanno lavorando per mitigare il problema e condivideranno gli aggiornamenti come disponibile.

3. 8 ottobre 2026 alle ore 03:28 UTCmonitoring

   Stiamo risolvendo per un outage che colpisce la creazione di attività HITL per i Maestri con HITL task SLA timer configurati negli Stati Uniti e stanno lavorando per mitigare il problema. Impatto: Gli utenti potrebbero non essere in grado di creare attività HITL all'interno dei Maestri con timer SLA di attività HITL configurati. Prossimo aggiornamento: I nostri team stanno lavorando per mitigare il problema e condivideranno gli aggiornamenti come disponibile.

4. 8 ottobre 2026 alle ore 04:29 UTCresolved

   La correzione per il problema che influisce sulla creazione di attività HITL per il Maestro con HITL task SLA timer configurati negli Stati Uniti è stata completamente arrotolata. La creazione di attività HITL è tornata alla normalità.

5. 26 ottobre 2026 alle ore 03:16 UTCpostmortem

   ## Impatto del cliente Il 2026-10-05 tra le 9.30 UTC - 2026-10-07 3.30 I clienti UTC, Maestro BPMN e Case che utilizzano i nodi HITL con un Task Timer configurato hanno visto fallimenti delle loro istanze di debug e di produzione nella fase HITL, con 4xx . Sono stati identificati circa 30 casi di questo tipo di clienti in tutti gli Stati Uniti e in Europa, bloccati senza alcun intervento. # Configurare un compito SLA richiede un oggetto compreso i criteri di inizio e fine, il timer della SLA, e il risultato sulla violazione SLA. I clienti lo configurano sul designer Maestro sul nodo HITL. Il risultato è stato erroneamente mantenuto non obbligatorio sulla superficie di progettazione, anche se una configurazione SLA senza un risultato non è persistito e non ha senso di business. Il team di backend Action Center aveva aggiunto una validazione per lanciare una cattiva richiesta (400) in caso di un oggetto SLA non nullo con un risultato mancante. Questo ha finito per influenzare i clienti che avevano aggiunto i criteri Start/End sul nodo ma non configurato un risultato. I casi che in precedenza erano in esecuzione falliti con 400s, e non erano in grado di riprendere ## Detection Un cliente ha riferito il problema al Maestro Engineering SME, che lo ha sollevato internamente con il team. Il team del Maestro ha indagato questo fallimento, e ha osservato un numero crescente di fallimenti per l'USI, e alcuni altri inquilini tramite registri, portandoli a coinvolgere il team di Action Center. # Il team del Maestro ha ricevuto il rapporto del problema dal cliente via Email, e ha fatto alcune indagini iniziali e ha identificato una potenziale regressione, a seguito della quale, l'Action Center SME è stato impegnato, il problema riprodotto su ambienti più bassi, un rollback della funzione applicata e testata, e presentato a tutte le regioni colpite. E 'stato risolto con tutti i casi di essere internamente ritratta e ripresa. ## Seguilo # 1. Aggiungere la convalida per questo scenario attraverso tutte le superfici del codebase di servizio trasversale per garantire la revisione umana 2. Aggiungere i test di monitoraggio e integrazione richiesti in atto per rilevare questo problema più velocemente

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 7 ottobre 2026 alle ore 17:37 UTCinvestigating

   Stiamo indagando i rapporti di lentezza intermittente e gli errori che interessano un sottoinsieme di organizzazioni nella regione di East US di Automation Cloud. Gli utenti interessati possono vedere le pagine dell'Orchestratore UI non riescono a caricare (ad esempio, la pagina Jobs che ritorna "Si è verificato un errore"), e le operazioni di robot come le operazioni di coda e le sessioni iniziano possono intermittently time out. Forniremo un aggiornamento non appena saranno disponibili ulteriori informazioni.

2. 7 ottobre 2026 alle ore 18:13 UTCmonitoring

   Abbiamo applicato un aumento di capacità all'infrastruttura di base interessata nella regione degli Stati Uniti d'America orientale e tassi di errore e latenza restituita a livelli normali. Forniremo un aggiornamento non appena saranno disponibili ulteriori informazioni.

3. 7 ottobre 2026 alle ore 19:06 UTCresolved

   Abbiamo il problema nella regione degli Stati Uniti d'America orientale e tassi di errore e la latenza è tornata a livelli normali.

4. 14 ottobre 2026 alle ore 11:42 UTCpostmortem

   ## Impatto del cliente Tra le 13:00 UTC e le 18:15 UTC il 7 ottobre 2026, i clienti nella regione degli Stati Uniti hanno sperimentato errori intermittenti e risposte lente in Orchestrator. Gli utenti interessati possono aver visto le pagine di Orchestrator non caricare, per esempio la pagina di Jobs che ritorna “Un errore si è verificato,” e le operazioni di robot come le operazioni di coda e le sessioni iniziano possono avere intermittentemente tempo fuori. Altri servizi UiPath che dipendono dall'Orchestratore possono anche aver visto risposte o errori più lenti durante questo periodo. # Varie operazioni di Orchestrator frequentemente utilizzate si basavano su una risorsa condivisa di breve durata all'interno del database, incluso il controllo di stato di routine che ogni robot in esecuzione esegue. Mentre il volume dell'attività di robot concomitante in questa regione è cresciuto, le richieste hanno cominciato ad in coda per l'accesso a quella risorsa condivisa invece di completare il loro lavoro. L'effetto è stato selettivo piuttosto che un rallentamento generale: le operazioni che hanno usato questa risorsa sono state ritardate, mentre altri hanno continuato a funzionare normalmente. Poiché il processore del database, la memoria e l'uso di storage sono rimasti tutti all'interno di intervalli normali, il monitoraggio della capacità di routine non ha indicato un problema. ## Detection Il nostro monitoraggio automatizzato ha rilevato il degrado entro circa 35 minuti dall'inizio dell'impatto del cliente, e i nostri ingegneri hanno identificato la contention sottostante durante l'evento. Poiché questo è stato un problema di soddisfazione piuttosto che una carenza di capacità, e tutti gli indicatori di capacità erano normali, l'aumento della capacità del database non era previsto per risolverlo, e il team ha indagato alternative prima di applicarlo. Tale valutazione ha ritardato la mitigazione. # Il nostro team di ingegneria ha aumentato la capacità del database interessato. I tempi di risposta e i tassi di errore sono tornati immediatamente alla normalità e abbiamo continuato a monitorare per confermare che il servizio era stabile prima di chiudere l'incidente. * 13:00: I tassi di errore e i tempi di risposta iniziano a salire per i clienti nella regione degli Stati Uniti. * 13:36: Il monitoraggio automatizzato rileva il degrado e segnala il team di ingegneria on-call. * 13:36 – 17:29: Gli ingegneri indagano. Tutti gli indicatori di capacità del database standard — processore, memoria e archiviazione — rimangono all'interno di intervalli normali in tutto, quindi la causa non è evidente dal monitoraggio di routine. * 17:29: Viene dichiarato un incidente formale e il team di risposta è impegnato. 17:38 Una comunicazione pubblica è pubblicata su [UiPath Status](http://status.uipath.com/) \(Investigazione\). * 17:31 – 17:43: è prevista una capacità di base aggiuntiva per la regione interessata. * 18:00 : Tassi di errore, tempi di risposta e richiesta di ritardo ai livelli normali. * 18:11: La pagina di stato viene aggiornata al fine di monitoraggio e impatto cliente. * 19:06: L'incidente è chiuso dopo il monitoraggio continuo conferma che il servizio è stabile. ## Seguilo # Per evitare che questo accada di nuovo, siamo: * Cambiare le operazioni interessate in modo da non dipendere più dalla risorsa condivisa. Questo è stato presentato a tutti i sistemi interessati e ha notevolmente ridotto la condizione che ha causato l'incidente. * Abilitare il monitoraggio dettagliato del database su questi sistemi, quindi questa classe di contention è visibile mentre sta accadendo piuttosto che dopo. * Migliorare la nostra allerta in modo che un autentico degrado di questo tipo è chiaramente distinguibile dalla variazione di routine, autocorrettante, ed è aumentato più velocemente.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 6 ottobre 2026 alle ore 17:50 UTCinvestigating

   Stiamo indagando i rapporti di un impatto di outage [funzionalità compromessa o sintomo utente] per Orchestratore in Europa. Impatto: Gli utenti possono aspettarsi ritardi per l'ingestione di registri robot e/o la ricerca/esposizione dei registri. Nessun registro sarà perso. Prossimo aggiornamento: I nostri team stanno lavorando per capire la causa e la portata e condivideranno gli aggiornamenti come disponibile.

2. 6 ottobre 2026 alle ore 18:28 UTCidentified

   Abbiamo individuato la causa di un'ingestione in uscita dei registri dei robot per l'Orchestratore in Europa. Impatto: Gli utenti possono aspettarsi ritardi per l'ingestione di registri robot e/o la ricerca/esposizione dei registri. Nessun registro sarà perso. Prossimo aggiornamento: I nostri team stanno lavorando per capire la causa e la portata e condivideranno gli aggiornamenti come disponibile.

3. 6 ottobre 2026 alle ore 18:43 UTCmonitoring

   Abbiamo mitigato il problema che colpisce l'ingestione dei registri dei robot per l'Orchestratore in Europa. Impatto: Gli utenti possono aspettarsi ritardi per l'ingestione di registri robot e/o la ricerca/esposizione dei registri. Nessun registro sarà perso. Prossimo aggiornamento: I nostri team stanno lavorando per capire la causa e la portata e condivideranno gli aggiornamenti come disponibile.

4. 6 ottobre 2026 alle ore 18:44 UTCresolved

   Abbiamo mitigato il problema che colpisce l'ingestione dei registri dei robot per l'Orchestratore in Europa. Impatto: Gli utenti possono aspettarsi ritardi per l'ingestione di registri robot e/o la ricerca/esposizione dei registri. Nessun registro sarà perso. Prossimo aggiornamento: I nostri team stanno lavorando per capire la causa e la portata e condivideranno gli aggiornamenti come disponibile.

5. 7 ottobre 2026 alle ore 11:08 UTCpostmortem

   ## Impatto del cliente Su, tra le 15:45 UTC e le 18:45 UTC, i clienti ospitati nelle regioni Europa, Australia e Giappone non sono stati in grado di vedere i recenti registri robot in Orchestrator. I registri scritti durante la finestra di impatto non sono comparsi nelle viste di Jobs and Logs o attraverso l'API di Robot Logs, e i registri più vecchi di circa 03:00 UTC quel giorno sono stati disponibili solo intermittenza. La finestra di impatto differiva per regione: - Australia: circa 15:45 UTC a 18:35 UTC - Europa: circa 16:35 UTC a 18:00 UTC - Giappone: circa 16:45 UTC a 18:30 UTC Esecuzione del lavoro, code, trigger e tutte le altre funzionalità Orchestratore non sono state influenzate. Nessun registro robot è stato perso. I registri prodotti durante la finestra di impatto continuarono a essere raccolti e divennero nuovamente visibili una volta mitigato il problema. # Stavamo eseguendo un aggiornamento programmato del servizio Elasticsearch che memorizza i registri robot Orchestrator. L'aggiornamento utilizza un approccio blu/verde: un nuovo cluster viene creato accanto a quello esistente, i dati vengono ripristinati da un backup, la pipeline che ingerisce nuovi log è iniziata su di esso, e solo allora è il traffico passato. Nelle regioni colpite, l'interruttore di traffico è stato approvato dall'ingegnere che esegue l'aggiornamento prima del ripristino dei dati e il recupero di ingestione è stato completato, che è una deviazione dalla nostra procedura di aggiornamento. E' stato un errore umano. Di conseguenza, Orchestrator stava leggendo i registri dei robot da un cluster che non contiene ancora i dati recenti, mentre i nuovi registri continuavano a essere raccolti ma non erano ancora indicizzati sulle richieste di servizio del cluster. L'errore non è stato catturato perché il nostro strumento di distribuzione si basa sull'operatore per verificare la completezza dei dati e non applica l'ordine tra il ripristino dei dati e l'interruttore di traffico. ## Detection Il nostro monitoraggio sintetico, che esegue continuamente lavori di test e verifica che i loro registri vengono restituiti, rilevati registri mancanti nelle regioni colpite e avvisi sollevati. Il nostro team di ingegneria ha correlato gli avvisi con l'aggiornamento in corso, ha dichiarato un incidente e ha pubblicato una notifica della pagina di stato. # Il nostro team di ingegneri ha reindirizzato il traffico ai precedenti cluster di Elasticsearch in tutte e tre le regioni, che hanno immediatamente ripristinato l'accesso a tutti i log dei robot, compresi quelli prodotti durante la finestra di impatto. Abbiamo confermato il recupero attraverso il monitoraggio sintetico in ogni regione interessata e il monitoraggio continuato prima di marcare l'incidente risolto a circa 18:45 UTC. L'aggiornamento dei nuovi cluster continua in background. Il traffico sarà spostato a loro solo dopo che il ripristino dei dati è completo e l'ingestione è confermata per essere aggiornato. ## Seguilo # Per evitare che questo accada di nuovo, siamo: - Modifica della pipeline di distribuzione in modo che l'interruttore di traffico non possa essere eseguito fino a quando il ripristino dei dati e l'ingestione di registro sul nuovo cluster sono verificati come completi. - Aggiungendo un passaggio automatico di rollback alla pipeline, così il traffico può essere restituito al cluster precedente entro pochi minuti se viene rilevato un problema dopo un interruttore.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 6 ottobre 2026 alle ore 12:38 UTCidentified

   Stiamo osservando le prestazioni degradate per i servizi in UAE

2. 6 ottobre 2026 alle ore 12:43 UTCinvestigating

   Stiamo attualmente indagando su questo problema.

3. 6 ottobre 2026 alle ore 14:01 UTCidentified

   Abbiamo identificato il problema come un problema di routing di rete con un fornitore di servizi di terze parti, che influisce sulla connettività per i nostri servizi ospitati negli Emirati Arabi Uniti. Stiamo lavorando con il nostro provider a monte sulla risoluzione e aggiorneremo i progressi qui.

4. 6 ottobre 2026 alle ore 14:22 UTCidentified

   Stiamo continuando a lavorare per risolvere questo problema.

5. 6 ottobre 2026 alle ore 14:51 UTCmonitoring

   Stiamo monitorando la connettività e aggiorneremo questa pagina una volta confermata la stabilità.

6. 6 ottobre 2026 alle ore 15:09 UTCmonitoring

   Stiamo continuando a monitorare eventuali ulteriori problemi.

7. 6 ottobre 2026 alle ore 17:09 UTCresolved

   L'incidente è stato risolto.

8. 21 ottobre 2026 alle ore 05:36 UTCpostmortem

   ## Impatto del cliente Tra le 12:38 UTC e le 14:51 PM UTC, un sottoinsieme di clienti nella regione UAE ha sperimentato guasti quando si accede ai servizi cloud UiPath. L'incidente durò circa 2 ore e 13 minuti. I servizi interessati hanno incluso l'accesso a **cloud.uipath.com**, **account.uipath.com** Servizi ospitati negli Emirati Arabi Uniti. I clienti possono aver riscontrato timeout, autenticazione non riuscita, connessioni di reset o errori del server. # La causa principale era un fallimento di routing di rete regionale presso un fornitore di infrastrutture di terze parti. Un sottoinsieme di percorsi di rete in uscita dalla regione UAN a specifiche reti esterne — tra cui la rete di distribuzione dei contenuti che serve **cloud.uipath.com** e **account.uipath.com** — ha smesso di fornire traffico. Nuovi tentativi di connessione in uscita dai servizi interessati non hanno ricevuto risposte, causando richieste di tempo fuori. Il nostro team di ingegneria ha escluso la configurazione del servizio UiPath, la politica di livello delle applicazioni e la capacità di connessione in uscita come cause. Il fornitore di infrastrutture ha riconosciuto un problema noto che riguarda più clienti sullo stesso percorso di rete. ## Detection Il problema è stato rilevato tramite monitoraggio automatizzato. Di circa 12:40 pm UTC — circa due minuti dopo l'inizio del fallimento — l'indagine ha confermato che i nuovi collegamenti da servizi della regione UAN colpiti ai punti finali chiave UiPath stavano fallendo. # Entro le ore 10.00 UTC, il nostro team di ingegneri ha confermato che il fallimento era limitato a specifici percorsi di rete in uscita, mentre altre destinazioni sono rimaste raggiungibili. La convalida esclude le modifiche del routing UiPath-side, le modifiche della configurazione della distribuzione dei contenuti, la politica di livello delle applicazioni e i problemi della capacità di connessione in uscita. È stato aperto un caso di supporto ad alta affidabilità con il fornitore di infrastrutture di terze parti. A 1:50 pm UTC, il fornitore ha riconosciuto un problema noto che riguarda più clienti. Il nostro team ha continuato a monitorare il recupero dai percorsi di rete interessati e verificare la salute dei servizi come il traffico restituito. Alle 2:51 UTC, i controlli di recupero hanno confermato che il traffico UiPath attraverso i percorsi di consegna dei contenuti colpiti era tornato a livelli normali. I controlli di salute automatizzati e le metriche di servizio hanno confermato il recupero, e i servizi in UAN erano operativi. ## Seguilo # 1. Stiamo perseguendo l'azione correttiva confermata del fornitore di infrastrutture e l'analisi della causa principale per il fallimento del routing regionale. 2. Stiamo esaminando le dipendenze di servizio in uscita nella regione interessata per rafforzare la resilienza contro simili interruzioni di rete di terze parti.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 2 ottobre 2026 alle ore 16:23 UTCinvestigating

   Da circa 15:05 UTC, alcuni clienti nella regione degli Stati Uniti possono vedere i lavori che funzionano su Cloud Robots richiedono più tempo del solito per iniziare, o rimanere nello stato di Pending. I lavori sui tuoi robot non sono influenzati, e nemmeno altre regioni. Abbiamo trovato la causa probabile e stiamo lavorando per ripristinare la normale elaborazione del lavoro. I lavori che sono già in coda non sono persi e verranno elaborati una volta risolto il problema. Posteremo un altro aggiornamento entro 60 minuti.

2. 2 ottobre 2026 alle ore 16:34 UTCmonitoring

   Abbiamo applicato una correzione per il problema che ha ritardato i lavori su Cloud Robots nella regione degli Stati Uniti, e i lavori stanno ricominciando normalmente. I lavori che sono stati ritardati sono ora in fase di elaborazione. Stiamo monitorando per assicurarci che il servizio rimanga stabile e pubblicherà un altro aggiornamento entro 60 minuti.

3. 2 ottobre 2026 alle ore 16:51 UTCmonitoring

   Dopo ulteriori lavori sul problema, i lavori sui Cloud Robots nella regione degli Stati Uniti stanno iniziando normalmente. I lavori che sono stati ritardati in precedenza sono in fase di elaborazione. Stiamo continuando a monitorare il servizio e pubblicheremo un altro aggiornamento una volta risolto il problema.

4. 2 ottobre 2026 alle ore 17:03 UTCresolved

   Questo problema è stato risolto. Tra le 15:05 e le 16:39 UTC, i lavori su Cloud Robots nella regione degli Stati Uniti sono stati lenti per iniziare o rimanere nello stato di Pending. I lavori iniziano normalmente dalle 16:39 UTC, e i posti di lavoro che sono stati ritardati durante questo periodo sono ora stati elaborati. Ci scusiamo per l'interruzione.

5. 14 ottobre 2026 alle ore 14:20 UTCpostmortem

   ## Impatto del cliente Dalle 15:00 alle 16:38 UTC il 2026-10-02, i lavori di Cloud Robots nella regione degli Stati Uniti hanno richiesto più tempo del solito per iniziare, fino a 22 minuti al picco intorno alle 16:20 UTC. Orchestratore rimase disponibile, nessun lavoro è stato perso, nessun'altra regione è stata colpita. Un piccolo numero di clienti ha ricevuto un errore limite temporaneo sulle nuove presentazioni mentre i loro lavori precedenti erano in attesa. ## Detection Avvisi automatizzati sparati a 15:07 UTC, sette minuti dopo l'impatto iniziato. I controlli nella regione degli Stati Uniti sono falliti da circa 15:32 UTC e la risposta incidente è iniziata. # Alle 14:55 UTC un flusso di lavoro del cliente ha cominciato a presentare posti di lavoro a circa 20 volte il suo tasso normale. Il servizio che ammette i posti di lavoro mantiene un conteggio convaluta per-customer nel database e lo aggiorna sotto un blocco di database su ogni inizio e fine del lavoro. A quel ritmo la coda di blocco per il record del cliente è cresciuta fino a quando gli aggiornamenti non sono disponibili. Gli aggiornamenti di attesa hanno occupato la piscina condivisa di lavoratori che inizia posti di lavoro per tutti i clienti della regione, così ogni lavoro del cliente ha aspettato dietro di loro. Il meccanismo destinato a isolare il carico di un cliente è diventato il collo di bottiglia. # Il team ha identificato il percorso di ammissione sovraccarico e il carico di lavoro dietro di esso. Un primo cambiamento di configurazione a 15:46 UTC ha preso di mira il record sbagliato e non ha avuto effetto. Il cambiamento corretto a 16:10 UTC esentò che il tipo di lavoro del cliente dal blocco del database e ha avuto effetto a circa 16:20 UTC. I tempi di inizio sono scesi da circa 13 secondi a meno di un secondo e il backlog di circa 5200 posti di lavoro drenati in 18 minuti. Inizio di lavoro erano normali a 16:38 UTC. Il trigger del cliente è stato spento con il cliente a circa 16:40 UTC. ## Seguilo # La limitazione della velocità bloccata dal database è sostituita dal meccanismo di limitazione della velocità di prestazione elevata in memoria, quindi il carico di un cliente non può bloccare il lavoro inizia per altri. Il cambiamento è completo, testato in pre-produzione con lo stesso carico, e viene eliminato.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 2 ottobre 2026 alle ore 00:13 UTCinvestigating

   Stiamo attualmente indagando su un outage che interessa il portale Insights nella regione degli Emirati Arabi Uniti. Gli utenti di questa regione potrebbero non essere in grado di accedere al portale o potrebbero sperimentare carichi di pagina falliti. Il nostro team sta lavorando attivamente per identificare il servizio di causa e ripristino. Forniremo un altro aggiornamento non appena avremo maggiori informazioni.

2. 2 ottobre 2026 alle ore 00:36 UTCidentified

   Abbiamo identificato un percorso di mitigazione e stiamo avviando un rollback nella regione degli Emirati Arabi Uniti. Gli utenti possono continuare a sperimentare problemi di accesso intermittenti con il portale Insights mentre questo lavoro è in corso. Forneremo un altro aggiornamento una volta che il rollback è completo.

3. 2 ottobre 2026 alle ore 00:41 UTCmonitoring

   Il portale Insights nella regione degli Emirati Arabi Uniti sta caricando con successo seguendo il nostro rollback. Stiamo continuando a monitorare il servizio per confermare la stabilità e fornire un aggiornamento finale una volta che siamo sicuri che il problema è completamente risolto.

4. 2 ottobre 2026 alle ore 00:51 UTCresolved

   Il portale Insights nella regione degli Emirati Arabi Uniti è ora operativo normalmente dopo il rollback. Abbiamo convalidato la funzionalità del portale chiave e confermato che il servizio rimane sano. Questo incidente è ora risolto.

5. 5 ottobre 2026 alle ore 22:58 UTCpostmortem

   ## Impatto del cliente Il 1o ottobre 2026**, il servizio UiPath **Insights** nella regione UAE** non era disponibile. Da circa **23:40 UTC il 1 ottobre alle 00:39 UTC il 2 ottobre**, gli utenti non potevano caricare cruscotti Insights: le richieste fallite con un errore dopo circa 10 secondi. Le richieste di fornitura Insights per i nuovi inquilini nella regione hanno anche fallito. L'interruzione durò circa 59 minuti. Altri servizi UiPath nella regione degli Emirati Arabi Uniti, e Insights in tutte le altre regioni, non sono stati colpiti. Nessun dato del cliente è stato perso. # Causa radice # L'outage è stato causato da un ** cambiamento di configurazione** che ha spedito in un rilascio di Insights programmato. Il cambiamento ha aumentato la versione **minimum TLS \(Transport Layer Security\)** sui endpoint delle applicazioni Insights nella regione UAE da TLS 1.2 a **TLS 1.3**, nell'ambito di uno sforzo di indurimento della sicurezza. Il gateway UiPath che collega il traffico dei clienti a Insights a questi endpoint su TLS 1.2. Una volta che gli endpoint hanno smesso di accettare TLS 1.2, il gateway non poteva più aprire una connessione sicura a loro. Le richieste del cliente hanno tempo e restituito gli errori, anche se l'applicazione Insights stesso è rimasto sano. Il cambiamento si applica solo alla regione degli Emirati Arabi Uniti, motivo per cui nessun'altra regione è stata colpita. ## Detection Il problema è stato rilevato da ** monitoraggio sintetico automatizzato di UiPath**, che verifica continuamente la disponibilità di informazioni da più posizioni. Il primo controllo sanitario fallito è stato registrato alle 23:40 UTC. Avvisi automatizzati sparati in pochi minuti, e il team di ingegneria in chiamata ha iniziato a indagare. # Il team di ingegneria ha confermato che l'esternalizzazione ha interessato solo le Insights nella regione degli Emirati Arabi Uniti. L'applicazione era in esecuzione normalmente, ma nessun traffico clienti stava raggiungendo. Il team ha tracciato il fallimento del passaggio di connessione sicura tra il gateway e l'Insights, e l'ha collegato all'impostazione TLS applicata dal rilascio. A circa **00:38 UTC**, il team ha ripristinato la precedente versione minima TLS \(TLS 1.2\) sui endpoint interessati. I controlli di salute sintetici hanno cominciato a passare immediatamente, e **00:41 UTC** tutti i controlli di vista nella regione degli Emirati Arabi Uniti erano sani. Il team ha continuato a monitorare per confermare la piena stabilità. ## Follow-Up Per prevenire incidenti simili in futuro, stiamo facendo i seguenti passi: * ** Rimozione del cambiamento TLS dal rilascio** in modo che le future distribuzioni non lo riapplicano, fino a quando il gateway supporta TLS 1.3 end to end. * ** Validate connessione-sicurezza cambiamenti contro il gateway** in un ambiente di pre-produzione prima che vengano applicati alla produzione.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 1 ottobre 2026 alle ore 18:57 UTCinvestigating

   A partire dal 1 ottobre alle ore 1:30 UTC, alcuni agenti, compresi gli agenti a basso codice e codificati, hanno iniziato a sperimentare guasti in tutte le regioni quando si utilizzano gemini-3.1-pro-preview e gpt-4o-2024-05-13. Questi modelli potrebbero anche non essere disponibili per la selezione durante la progettazione dell'agente. Stiamo attivamente indagando e lavorando su una soluzione.

2. 1 ottobre 2026 alle ore 19:05 UTCidentified

   Abbiamo identificato il problema e stiamo implementando una correzione. Gli agenti che utilizzano i modelli interessati possono continuare a sperimentare guasti, e i modelli possono rimanere non disponibili per la selezione durante la progettazione degli agenti, mentre la distribuzione completa.

3. 1 ottobre 2026 alle ore 19:46 UTCresolved

   Abbiamo annullato il cambiamento che ha causato questo problema e confermato che i modelli interessati sono nuovamente disponibili. Alcuni agenti possono continuare a sperimentare guasti intermittenti mentre le istanze rinfrescano. Stiamo continuando a monitorare la progettazione e l'esecuzione dell'agente per gemini-3.1-pro-preview e gpt-4o-2024-05-13.

4. 7 ottobre 2026 alle ore 10:15 UTCpostmortem

   ## Impatto del cliente Il 1o ottobre 2026, dalle 14:31 alle 19:40 UTC, agenti configurati con alcuni grandi modelli di lingua, tra cui Gemini 3.1 Pro Preview e GPT-4o (2024-05-13), non è riuscito a iniziare in tutte le regioni, con un errore che dice che il modello non è disponibile. Gli stessi modelli mancavano dalla lista dei modelli mentre progettavano agenti. Gli agenti che utilizzano altri modelli non sono stati colpiti. # Una bandierina di funzionalità è stata ribaltata, causando il servizio Agents di iniziare l'invio di un codice di funzionamento per modellare le richieste di scoperta. Ciò ha causato l'elenco dei modelli serviti per essere l'operazione specifica al contrario della lista dei modelli agenti di base. La lista dei modelli per operazione è stata inizialmente semenzata dalla configurazione di Bring Your Own Model (BYOM) di modelli sovraridabili, che cruciale per gli agenti non ha parità con l'elenco completo dei modelli supportati nel servizio Agents. L'audit interno ha dimostrato che questo è stato un errore e non un gap intenzionale. Nel corso del tempo questo divario non è mai stato affrontato e dopo l'interruttore di bandiera, gli agenti già configurati con uno dei modelli interessati fallirebbero a causa della loro assenza dall'elenco restituito. ## Detection Un cliente ha riferito il problema, ed è stato aumentato ai nostri ingegneri a 16:44 UTC. Il nostro monitoraggio non ha avvisato, perché questo errore di solito indica problemi di configurazione di livello di organizzazione o agente. # Gli ingegneri hanno tracciato i guasti al cambiamento di configurazione e l'hanno ripristinato alle 19:01 UTC. La deviazione ha avuto effetto nei seguenti minuti, e l'ultimo fallimento si è verificato alle 19:40 UTC. ## Seguilo # 1. Le liste dei modelli saranno allineate prima che questo cambiamento venga rifatto. 2. Stiamo cambiando il modo in cui questo errore viene classificato in modo che un picco su piattaforma avvisi i nostri ingegneri.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 1 ottobre 2026 alle ore 18:17 UTCinvestigating

   A partire dal 1 ottobre alle 12:00 PM UTC, gli utenti della comunità in Europa possono sperimentare guasti in Agenti LowCode che utilizzano App di Azione Soluzione-locale. Abbiamo confermato che l'impatto è limitato agli utenti comunitari in Europa. Stiamo attivamente indagando sul problema, determinando l'entità dei fallimenti, e lavorando su una correzione.

2. 1 ottobre 2026 alle ore 18:25 UTCidentified

   Abbiamo identificato il problema causando guasti in agenti di basso codice che utilizzano applicazioni di azione soluzioni-local per gli utenti della comunità in Europa. Stiamo tornando indietro le modifiche precedenti e continuiamo a monitorare il recupero. Forniamo un altro aggiornamento una volta che il rollback è completo o se abbiamo ulteriori informazioni da condividere.

3. 1 ottobre 2026 alle ore 20:08 UTCresolved

   Abbiamo confermato che il rollback è stato completato e il problema che riguarda gli agenti di basso codice che utilizzano applicazioni di azione soluzioni-local per gli utenti comunitari in Europa è stato risolto. I servizi sono stati recuperati e stiamo chiudendo questo incidente.

4. 7 ottobre 2026 alle ore 14:28 UTCpostmortem

   ## Impatto del cliente Il 1 ottobre 2026, dalle 10:50 alle 19:50 UTC, alcuni utenti di Studio Web in Europa non potrebbero debug agenti che chiamano processi di Orchestrator (RPA, agenti, ecc.) o App di Azione dalla stessa soluzione. La chiamata è fallita con un errore "non trovato". Gli agenti e i lavori di produzione non sono stati colpiti. # Un aggiornamento Web di Studio ha cambiato come le risorse della soluzione si trovano durante il debug. Mancava un'impostazione che mantiene il comportamento precedente, quindi debug corre cercava le risorse della soluzione nello spazio di lavoro personale dell'utente invece della cartella debug. ## Detection Test automatizzati end-to-end hanno avvisato i nostri ingegneri a 16:43 UTC. La suite di test end-to-end funziona una volta ogni 2 ore e l'avviso avviene solo dopo 3 guasti di test consecutivi. Il problema è stato segnalato anche da un ambiente cliente. # Dopo aver identificato la causa principale, un rollback è stato avviato alle 18:00 UTC ed è stato completamente in vigore alle 19:50 UTC. Questa durata includeva un fallimento di distribuzione che doveva essere retried, che ha richiesto 50 minuti. Una versione corretta che include l'impostazione è stato distribuito il 2 ottobre alle 13:00 UTC. ## Seguilo # 1. L'impostazione è ora parte della linea di codice principale, quindi le versioni future lo includono. 2. Stiamo migliorando gli avvisi e la suite di test end-to-end per catturare le regressioni prima.

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.

1. 1 ottobre 2026 alle ore 16:32 UTCresolved

   Tra le 14:23 e le 16:04 UTC il 1o ottobre 2026, alcune richieste di eliminare oggetti nei servizi UiPath Automation Cloud nella regione Australia non sono riusciti con errori "404 Not Found". I servizi interessati includono Orchestratore, Comprensione dei documenti, Centro AI e Servizio dati. Altre operazioni, come la visualizzazione, la creazione e l'aggiornamento degli articoli, hanno lavorato normalmente. La causa è stata una modifica di configurazione per il nostro routing richiesta. L'abbiamo rimossa e il servizio è completamente restaurato.

2. 7 ottobre 2026 alle ore 10:15 UTCpostmortem

   ## Impatto del cliente Tra il 1 ottobre 2026 alle 2:23 UTC e le 16:04 UTC, un sottoinsieme di clienti esperti **404 Not Found** errori per alcune richieste UiPath Automation Cloud nella regione Australia. L'incidente durò 1 ora e 41 minuti. Le richieste colpite includono operazioni di cancellazione e alcuni controlli di connessione Robot. I servizi interessati includono l'Orchestratore, la Comprensione dei documenti, l'AI Center e il servizio dati. I lavori robot che hanno chiamato Orchestrator potrebbero aver fallito, e i clienti potrebbero aver bisogno di eseguire qualsiasi lavoro robot che non è riuscito durante questa finestra. Tutte le altre operazioni non sono state influenzate. # Un cambio di configurazione di routing è stato applicato alla regione Australia con un insieme incompleto di operazioni supportate a causa di un timeout nella pipeline di rilascio. Eliminare le operazioni erano mancanti dalla configurazione, quindi tali richieste sono state respinte allo strato di routing con **404 Not Found** prima di raggiungere i servizi sottostanti. ## Detection Il monitoraggio end-to-end automatizzato ha rilevato il problema avvisando i guasti per i controlli di servizio di Document Understanding. Il nostro team di ingegneria ha quindi utilizzato i dati di monitoraggio interno per confermare il modello più ampio di guasti attraverso i servizi interessati. # Durante l'indagine, i dati di monitoraggio hanno dimostrato che le richieste indirizzate attraverso la regione Australia sono state di ritorno **404 Not Found** errori, mentre le richieste indirizzate attraverso altre regioni non sono state influenzate. L'analisi ha identificato che il tempo di inizio di **404 Not Found** aumento di risposta è stato correlato con il tempo in cui la configurazione di routing è entrata in vigore. Il team ha reindirizzato la configurazione di routing alla precedente versione di lavoro. Dopo la deviazione, il monitoraggio ha mostrato i conti di errore in calo entro circa tre minuti, e il servizio è stato completamente restaurato entro il 1 ottobre 2026 alle 16:04 UTC. ## Seguilo # 1. Migliorare gli avvisi dello strato di routing sui cambiamenti della linea di base 4xx 2. Rileva le configurazioni di routing parzialmente applicate prima di avere loro effetto

Tradotto automaticamente dall'aggiornamento ufficiale dell'incidente.