Istoricul incidentelor Uipath

1. 27 octombrie 2026 la 16:39 UTCresolved

   La 27 octombrie 2026, între 14:35 și 16:08 UTC, înțelegerea documentelor în regiunea Europei a avut loc o întrerupere parțială care a afectat extracția generativă, clasificarea genetică și autovalidarea. Cauza principală a fost o problemă de conectivitate cu un furnizor terț de stocare. Conectivitatea a fost restabilită şi am confirmat că extracţia şi clasificarea funcţionează normal de la 16:08 UTC.

Traducere automată din actualizarea oficială a incidentului.

1. 26 octombrie 2026 la 14:04 UTCidentified

   Investigăm în prezent o problemă care afectează disponibilitatea serviciilor de informare şi automatizare. Echipa noastră evaluează în mod activ situația pentru a identifica cauza de bază și a determina pașii necesari pentru a restabili operațiunile normale. Alte actualizări vor fi furnizate pe măsură ce devin disponibile mai multe informații.

2. 26 octombrie 2026 la 15:35 UTCidentified

   Problema operaţiunilor de automatizare a fost rezolvată. Aşteptăm în prezent să se atenueze problema serviciului Insights. Alte actualizări vor fi partajate pe măsură ce devin disponibile.

3. 26 octombrie 2026 la 17:09 UTCidentified

   Serviciul de Insights în Singapore, Japonia, Elveția, Canada, India, Marea Britanie, Europa, Statele Unite, EAU, Coreea de Sud și Australia este stabilit și aplicăm stabilirea pe alte regiuni

4. 26 octombrie 2026 la 18:27 UTCresolved

   Problema a fost rezolvată și toate serviciile funcționează în mod normal.

Traducere automată din actualizarea oficială a incidentului.

1. 27 octombrie 2026 la 10:13 UTCresolved

   La 26 octombrie 2026, între orele 10:20 şi 17:30 UTC, roboţii Cloud Automation (VM) au suferit o pană parţială care afectează operaţiunile maşinilor. În timpul acestei ferestre, este posibil ca acțiuni precum pornirea, oprirea sau furnizarea de mașini VM să nu fi fost finalizate, iar locurile de muncă programate pentru aceste mașini pot fi întârziate sau defecte. Cauza a fost o configurație greșită permisiuni pe un subset de resurse de infrastructură subiacente. Echipa noastră a identificat problema, a corectat configuraţia şi a confirmat că operaţiunile maşinilor funcţionează normal de la 17:30 UTC. Revedem modul în care a fost introdusă configuraţia greşită şi adăugăm controale pentru a preveni repetarea acesteia. Nu este necesară nicio acţiune de partea ta. Dacă încă vedeți locuri de muncă eșuate sau blocate de la acea fereastră, vă rugăm să le rejudecați și să contactați sprijinul în cazul în care problema persistă.

Traducere automată din actualizarea oficială a incidentului.

1. 23 octombrie 2026 la 21:35 UTCresolved

   Între 20:42 și 21:19 UTC la 23 octombrie, unii clienți Orchestratori din Europa au văzut răspunsuri lente și erori intermitente. Acest lucru a inclus apeluri robot pentru a obține active, procesa elementele de coadă și să raporteze starea postului. Unele locuri de muncă nesupravegheate ar fi eșuat în acest timp. Cauza a fost o creștere bruscă a sarcinii care a atins limitele de resurse ale bazei de date. Am adăugat capacitatea bazei de date, iar performanța a revenit la normal de la 21:19 UTC. Clienți ale căror locuri de muncă nu a reușit în această fereastră poate fi necesar să le repornească.

Traducere automată din actualizarea oficială a incidentului.

1. 22 octombrie 2026 la 12:59 UTCinvestigating

   Am identificat o problemă care afectează IXP pentru clienții găzduiți în regiunea Australia. De la 10:24 UTC, cereri care utilizează modelul Gemeni 2.5 Flash sunt în criză în regiune. Alte modele nu sunt afectate. Datele privind clienții continuă să fie prelucrate numai în Australia. Lucrăm cu Google pentru a restabili serviciul

2. 22 octombrie 2026 la 14:19 UTCmonitoring

   Un fix a fost implementat și serviciul este de recuperare. Monitorizăm sistemul pentru a asigura recuperarea completă. Alte actualizări vor fi împărtășite în curând

3. 22 octombrie 2026 la 14:33 UTCinvestigating

   După recuperarea inițială, serviciul s-a degradat din nou. Investigăm și lucrăm la o rezoluție. Vom furniza actualizări suplimentare pe măsură ce acestea devin disponibile.

4. 22 octombrie 2026 la 15:42 UTCinvestigating

   Am contactat Google Support, și au început investigarea la sfârșitul lor. Vom continua să monitorizăm şi să împărtăşim noutăţile aşa cum le avem.

5. 22 octombrie 2026 la 17:56 UTCmonitoring

   Observam imbunatatiri pe Gemini 2.5 Flash trafic. Monitorizăm o posibilă fixare de pe Google.

6. 22 octombrie 2026 la 21:02 UTCresolved

   Problema este rezolvată de pe Google.

7. 26 octombrie 2026 la 03:20 UTCpostmortem

   ## Impactul clientului Între 22 octombrie 2026 la 10:24 am UTC și 22 octombrie 2026 la 6:04 pm UTC, cererile de prelucrare a documentelor care au folosit Gemini 2.5 Flash în regiunea Australiei au eșuat cu erori de capacitate. Impactul a durat aproximativ 7 ore şi 40 minute. Au fost afectate un subset de clienți care utilizează fluxuri de lucru de extracție a documentelor în regiunea respectivă. În timpul unei tentative temporare de retragere din regiune, unele cereri de extracție și-au revenit pe scurt, dar atribuirea la nivel de cuvinte și textul paginii generate au fost degradate până când retragerea a început, de asemenea, să scadă. ## Root cause Cauza principală a fost întreruperea rețelei regionale în timpul întreținerii concomitente. Acest lucru a cauzat trepidaţii severe de lăţime de bandă în mediul de model-servire al furnizorului, ceea ce a împiedicat sistemele de suport să încarce modelele de date necesare pentru a servi Gemini 2.5 Flash şi Gemini 3.5 Flash solicită în mod fiabil în regiunea afectată. ## Detectie Problema a fost detectată prin alertarea automată care a identificat erori de limitare a ratei pe Gemini 2.5 Flash în regiunea Australia. Echipa noastră de inginerie a confirmat prin telemetrie că cererile afectate au eșuat în mod constant și au început coordonarea unui răspuns. ## Response La 1:40 pm UTC, am rutat afectat Gemini 2.5 Flash trafic la Gemini 3.5 Flash în aceeași regiune pentru a menține șederea datelor. Telemetria initiala nu a aratat erori de capacitate dupa aceasta schimbare, ci pana la 2:10 pm UTC, Gemini 3.5 Flash a fost, de asemenea, revenirea erorilor de capacitate, astfel încât retragerea nu mai era viabilă. La 2:05 pm UTC, am ajustat căile de procesare a documentelor aferente, astfel încât atribuirea și generarea de pagini text ar folosi aceeași rezervă în regiune; această ajustare finalizată la aproximativ 2:09 pm UTC. După ce retragerea a eșuat, am revenit schimbarea de rutare, și până la 4:28 pm UTC trafic a fost din nou pe cale Gemini 2.5 Flash așteptat. La 5:38 pm UTC, telemetria a arătat îmbunătățirea Gemini 2.5 Ratele de succes Flash. De la 6:04 pm UTC, nu s-au mai observat erori de capacitate, iar cererile ulterioare au reușit. ## Follow up 1. Completați evaluarea de capacitate a modelului rezervat pentru regiunea afectată utilizând modelele de trafic observate 2. Evaluarea retry and backoff behavior in document procesing clients to reduce retry amplification during provider-side capacity failings.

Traducere automată din actualizarea oficială a incidentului.

1. 15 octombrie 2026 la 12:27 UTCinvestigating

   De la aproximativ 11:17 UTC, clienţii din mai multe regiuni au avut probleme cu Agenţii UiPath şi Managementul Soluţiilor. Noi locuri de muncă pot rămâne în stare în așteptare, iar agenții care rulează pot experimenta întârzieri atunci când prelucrarea escaladarea sau de așteptare pentru rezultatele instrumentelor. Investigăm problema și lucrăm la o rezoluție.

2. 15 octombrie 2026 la 13:04 UTCmonitoring

   Problema a fost atenuată. Monitorizăm serviciile afectate în toate regiunile pentru a asigura stabilitatea și a confirma faptul că începerea locurilor de muncă și desfășurarea de soluții funcționează în mod normal.

3. 15 octombrie 2026 la 13:22 UTCresolved

   Acest incident a fost rezolvat. Între 11:15 și 12:45 UTC la 15 octombrie, o problemă de configurare internă a împiedicat furnizarea unor evenimente între serviciile UiPath în mai multe regiuni. Problema a fost rezolvată prin reluarea schimbării, iar noua activitate este procesată în mod normal. Unele lucrări inițiate sau în curs în timpul acestei ferestre pot necesita atenție: - Agenti: Agentii care asteapta la activitatile Centrului de Actiune sau rezultatele instrumentului de automatizare pot ramane blocate. Locurile de muncă începute de la Orchestrator pot apărea, de asemenea, blocat sau time out. - Maestro: Este posibil ca procesele care așteaptă să nu fi fost reluate după finalizarea sarcinii. - Aplicatii: Statusul la coada poate fi depasit, iar actiunile declansate prin completarea punctului de coada nu au functionat. - Pilot automat pentru toată lumea: Conversațiile care așteaptă rezultatele automatizării pot rămâne blocate. - Înţelegerea documentelor şi fundamentarea contextului: Automatizările şi agenţii care aşteaptă extracţia, validarea sau indexarea pot rămâne suspendate. - Serviciul de Integrare: Evenimentele Conectorilor nu pot declanşa procesele sau notificările aşteptate. - Solutii si Studio Web: Solutii instalatii, dezinstalari, publicatii, implementari si validari initiate in timpul acestei ferestre s-ar putea sa fi esuat sau sa fi expirat. Retrimiterea acestor operațiuni poate rezolva problema. Ne cerem scuze pentru întrerupere şi vă mulţumim pentru răbdare.

4. 21 octombrie 2026 la 06:47 UTCpostmortem

   ** Impactul clientului ** La 15 octombrie 2026, între 11:15 și 12:50 UTC (aproximativ o oră și 35 de minute), unele evenimente schimbate între serviciile de cloud UiPath nu au fost livrate. Clienţii din toate regiunile de cloud comercial au fost afectaţi. În timpul acestei ferestre: - Noul agent poate rămâne în aşteptare. S - ar putea ca agenţii care conduc să aştepte rezultatul unui instrument, al unei escaladări umane, al unei extrageri de documente sau al unui context de împământare să nu fie reluat. - Agenţi conversaţionali şi Autopilot pentru fiecare conversaţie care a început o automatizare s-ar putea să nu fi primit rezultatul. - Cazurile de proces Maestro care aşteaptă o sarcină de utilizator nu ar fi putut merge mai departe după ce sarcina a fost finalizată, iar procesele declanşate de evenimentele de conector Integrare Service ar fi putut să nu înceapă. - Aplicaţiile care arată sau reacţionează la statusul punctului din coadă pot indica informaţii învechite. - Solutia instala, dezinstala, publica, si implementari ar putea esua sau pauza. - Unele modificări de utilizator, grup, și dosar făcute în fereastra ar putea să nu fi propagat la toate serviciile. Lucrările au început după ora 12:50 UTC nu au fost afectate. Executarea de locuri de muncă robot, cozi, și declanșatori manipulate în interiorul Orchestratorului a continuat să funcționeze în mod normal. **Root cause** Mutam livrarea configuraţiei interne a serviciilor către un nou mecanism, o schimbare destinată să nu aibă efect asupra clienţilor. Atunci când această modificare a fost aplicată serviciului de livrare a evenimentului, configurația pe care a produs-o lipsea o valoare necesară. Fără ea, serviciul a tratat mai multe integrări de produse ca oprite și oprit în tăcere furnizarea evenimentelor lor. Deoarece schimbarea a atins toate regiunile de producție în același timp, fiecare regiune a fost afectată. **Detecţia** Problema a fost detectată la 11:51 UTC, la aproximativ 35 de minute după ce a început impactul, atunci când monitorizarea a alertat asupra locurilor de muncă agent rămase în stare în așteptare. Au urmat rapoartele de implementare a soluţiilor, iar un incident a fost declarat la 12:12 UTC. **Responsa ** După prima detectare la 11:51 UTC, modificarea configurației a fost identificată și a început o revenire la ora 12:00 UTC. O revenire inițială la 12:14 UTC nu a restabilit complet livrarea. Echipa a oprit apoi noul proces de livrare a configuraţiei şi a restaurat configuraţia anterioară. Livrarea evenimentului a început să se recupereze la 12:40 UTC, iar recuperarea completă în toate regiunile a fost confirmată la 12:50 UTC. Acolo unde este posibil, am reluat evenimentele pierdute, astfel încât munca afectată să poată continua. **Urmează-te** 1. Noul proces de livrare a configuraţiei a fost întrerupt pentru serviciul afectat şi va rămâne oprit până când configuraţia este generată corect. 2. Validarea configuraţiei produse de noul mecanism de livrare a valorilor necesare înainte de aplicarea pe orice mediu. 3. Rulați modificările la livrarea configurației progresiv pe regiuni în loc de toate regiunile dintr-o dată. 4. Îmbunătățește monitorizarea noastră pentru a detecta în câteva minute când evenimentele încetează să mai fie livrate către o integrare a produselor care le primește în mod normal. 5. Îmbunătățește capacitatea noastră de a recupera și reabilita evenimentele omise în timpul unei întreruperi.

Traducere automată din actualizarea oficială a incidentului.

1. 15 octombrie 2026 la 12:03 UTCresolved

   Unii clienți din regiunea SUA au suferit întârzieri în ingerarea jurnalelor roboților, cu o activitate crescută observată între aproximativ 11:20 și 11:45 UTC. Problema a fost rezolvată, iar ingerarea jurnalelor a revenit la normal. Mulţumesc pentru răbdare.

2. 22 octombrie 2026 la 10:13 UTCpostmortem

   ## Impactul clientului In perioada 15 octombrie 2026 la 11:20 pm UTC si aproximativ 15 octombrie 2026 la 11:45 pm UTC, unii clienti din regiunea de Est a SUA au avut intarzieri in ingestie de roboti in UiPath Orchestrator. Jurnalele robotului nu au fost actualizate în perioada afectată. Impactul a durat aproximativ 20 de minute. ## Root cause În timpul incidentului, au fost observate 2 din cele 13 cazuri de service care manipulau ingestie de roboţi care nu se conectau la serviciul de ingestie de evenimente. Doar cererile de servicii de ingestie de evenimente au eşuat şi numai în aceste două cazuri. Acest lucru a cauzat unele cereri de ingestie robot de a nu finaliza cu succes, ceea ce a dus la datele de jurnal întârziate pentru clienții afectați. Cauza principală a motivului pentru care doar aceste două cazuri și-au pierdut conectivitatea la serviciul de ingestie a evenimentului nu a fost determinată în timpul incidentului. Echipa sa angajat la o revizuire post-incident de jurnale din cazurile afectate pentru a identifica cauza de bază. Credem că este o problemă de infrastructură nedeclarată din partea furnizorului nostru de cloud. ## Detectie Problema a fost detectată printr-o alertă automată la aproximativ 11:33 pm UTC la 15 octombrie 2026 și confirmată prin telemetrie care arată excepții de la cele două cazuri de serviciu afectate. ## Response După detectare, telemetria a confirmat că doar două cazuri de servicii generau excepții. Respondenţii au eliminat cele două cazuri nesănătoase din serviciu, iar cazurile de înlocuire au început automat. În aproximativ 20 de minute de la prima alertă de aproximativ 11:53 p.m. O repornire mai largă a tuturor cazurilor de servicii a fost luată în considerare, dar nu a fost efectuată, deoarece echipa a stabilit că nu ar trebui să continue fără a înțelege mai întâi cauza rădăcină. ## Follow up 1. O revizuire post-incidentă a jurnalelor din cazurile de servicii afectate a arătat că problema a fost legată de infrastructură, și urmărim cu furnizor de infrastructură cloud pentru mai multe detalii. 2. O actualizare va fi postată dacă investigaţia va da rezultate suplimentare.

Traducere automată din actualizarea oficială a incidentului.

1. 14 octombrie 2026 la 07:26 UTCmonitoring

   Începând cu ora 6:50 UTC am avut o întrerupere globală care a afectat încărcarea aplicațiilor și a aplicațiilor codate pentru toate regiunile, cu excepția Indiei și a Regatului Unit. Outage a fost rezolvată și serviciile sunt pe deplin operaționale. Impact: Niciun impact continuu al utilizatorului.

2. 14 octombrie 2026 la 07:43 UTCresolved

   Începând cu ora 6:50 UTC am avut o întrerupere globală care a afectat încărcarea aplicațiilor și a aplicațiilor codate pentru toate regiunile, cu excepția Indiei și a Regatului Unit. Outage a fost rezolvată și serviciile sunt pe deplin operaționale. Impact: Niciun impact continuu al utilizatorului.

3. 23 octombrie 2026 la 12:08 UTCpostmortem

   ## Impactul clientului Între 06:38 UTC și 07:21 UTC la 14 octombrie 2026, o parte din cererile adresate aplicațiilor UiPath, aplicațiilor codificate și soluțiilor care depind de acestea au eșuat în unsprezece regiuni: Europa, Statele Unite, Comunitate, Japonia, Singapore, Australia, Canada, Coreea de Sud, Elveția, EAU și mediul american întârziat. Regiunile India și Regatul Unit nu au fost afectate. Aproximativ 2% din cereri au eșuat în general, între 0,6 și 5 la sută în funcție de regiune. Utilizatorii afectați au văzut aplicații care nu reușesc să încarce, solicită erori de retur al serverului sau răspunsuri lente. În regiunile în care capsulele de serviciu trebuiau repornite, aplicațiile nu puteau fi contactate timp de aproximativ opt minute. Timpul de răspuns a revenit la normal în fiecare regiune până la 07:40 UTC. Majoritatea utilizatorilor de aplicații deja publicate au observat puțin sau nimic. Definițiile aplicației sunt cached în browser timp de până la 24 de ore, datele aplicației provin de la Data Service și Orchestrator mai degrabă decât această bază de date, iar serviciul a continuat să utilizeze conexiunile de baze de date pe care le deținea deja. Cererile care nu au reușit au fost cele care au avut nevoie de o nouă conexiune la o bază de date: deschiderea designerului sau a listei de aplicații, încărcarea unei aplicații care nu a fost încă cached, descărcarea documentelor și a imaginilor stocate în aplicații și salvarea sau publicarea. ## Root cause La 06:38 UTC, în timp ce accesarea bazei de date a fost creată pentru o nouă implementare regională, parola utilizatorului bazei de date pe care serviciul Apps îl utilizează a fost modificată. Acest utilizator este împărtășit de clusterele de baze de date de producție ale tuturor regiunilor afectate, astfel încât modificarea aplicată tuturor acestora în același timp. Serviciile de funcţionare deţineau încă parola anterioară şi nu mai puteau deschide noi conexiuni de baze de date. Regiunile din India și Regatul Unit nu utilizează această acreditare și nu au fost afectate. Schimbarea a fost menită să creeze un utilizator separat al bazei de date pentru noua regiune. În schimb, parola utilizatorului existent pe care toate regiunile îl împart a fost schimbată. Procesul nostru de schimbare pentru acreditarea bazei de date nu a separat în mod clar crearea unei noi credibilităţi de modificarea unuia existent şi nu a necesitat o verificare a numărului de grupuri şi regiuni pe care le-ar afecta o schimbare credibilă. Împreună cu un singur utilizator de baze de date care a fost partajat între regiuni, aceasta a permis o schimbare destinată unei regiuni să provoace o pană de curent în mai multe regiuni. ## Detectie Monitorizarea noastră internă a ridicat prima alertă la 06:41 UTC, la trei minute după primele eșecuri, și alerte pentru fiecare regiune afectată urmată de 06:46 UTC. La 06:50 UTC, inginerul de gardă a confirmat că fiecare grup de producție a fost refuzat de baza sa de date și a început procesul incidentului. ## Response La 07:05 UTC parola anterioară a fost restaurată și eșecuri de autentificare oprite peste tot. Majoritatea regiunilor s-au reconectat automat. În regiunile care nu au făcut acest lucru, capsulele de serviciu au fost repornite sau redistribuite: SUA a întârziat la 07:21 UTC și Elveția până la 07:30 UTC. Cerere de eșecuri oprit la 07:21 UTC, timpii de răspuns au fost din nou la momentul inițial de 07:40 UTC, și am continuat monitorizarea până la incidentul a fost rezolvată la 07:43 UTC. ## Follow up Pentru a preveni acest lucru să se întâmple din nou, suntem: - Introducerea unei proceduri definite pentru crearea și rotirea acreditărilor bazei de date, cu o revizuire prealabilă a situației care prevede că clusterele și regiunile împărtășesc acreditarea, precum și o introducere în scenă care este verificată într-o regiune înainte de a fi aplicată pe scară mai largă. - Trecerea la separat, cel mai puțin privilegiate utilizatori de baze de date pentru fiecare regiune, astfel încât o schimbare într-o regiune nu poate afecta o alta. - Declararea automată a unui incident și paginarea proprietarilor de baze de date atunci când aceeași eroare de bază de date este detectată în mai multe regiuni în loc să se bazeze pe escaladarea manuală a alertelor regionale individuale. - Activarea serviciilor pentru a ridica acreditări de baze de date actualizate fără o repornire, și pentru a reconecta mai repede după o eroare de autentificare.

Traducere automată din actualizarea oficială a incidentului.

1. 13 octombrie 2026 la 14:03 UTCinvestigating

   Investigăm în prezent o pană de curent care afectează serviciile UiPath Cloud în mai multe regiuni. Utilizatorii nu pot accesa serviciile găzduite în regiunile afectate. Următoarea actualizare: Informații suplimentare vor fi partajate pe măsură ce acestea devin disponibile.

2. 13 octombrie 2026 la 14:37 UTCinvestigating

   Continuăm să investigăm această problemă.

3. 13 octombrie 2026 la 14:42 UTCinvestigating

   A fost implementată o soluţie şi monitorizăm rezultatele. Problema a fost limitată la Document Înțelegerea, Computer Vision, Semantic Proxy, Autopilot Studi, IXP. Vom împărtăși o altă actualizare odată ce serviciile au recuperat complet.

4. 13 octombrie 2026 la 15:10 UTCinvestigating

   A fost implementată o soluţie şi monitorizăm rezultatele.

5. 13 octombrie 2026 la 15:19 UTCresolved

   Acest incident a fost rezolvat în urma reînnoirii certificatului SSL expirat care a afectat mai multe servicii dependente de ML, inclusiv IXP, Înțelegerea Documentului, Viziunea Computer, Proxy Semantic și Autopilot pentru Dezvoltatori. Recuperarea serviciilor a progresat în regiunile afectate, iar alertele automatizate au fost configurate pentru a ajuta la detectarea expirării certificatului în avans și pentru a preveni perturbări similare în viitor. Vă mulţumesc pentru răbdare şi înţelegere.

6. 26 octombrie 2026 la 03:17 UTCpostmortem

   ## Impactul clientului Între orele 13:37 și 14:40 UTC la 13 octombrie 2026, clienții din mai multe regiuni nu au putut utiliza documentele nestructurate IXP, comunicațiile IXP Minerit și înțelegerea documentelor. Computer Vision și Autopilot pentru Dezvoltatori caracteristici care depind de aceleași servicii de învățare mașină, de asemenea, a eșuat. Clienţii afectaţi au văzut cereri eşuând cu "500 Eroare de server intern" sau cu time-out, proiecte IXP care nu s-ar deschide, şi activităţi de vizualizare computerizată care nu funcţionează automatizări. Serviciul a fost întrerupt aproximativ o oră. Nu s-au pierdut date despre clienţi. ## Root Cause Incidentul a fost cauzat de un certificat de securitate expirat folosit pentru a stabili legături sigure cu aceste servicii. Certificatul este reînnoit printr-un proces automatizat. Acest proces nu a mai fost executat cu succes și eșecurile nu au ridicat o alertă, astfel încât certificatul nu a fost înlocuit înainte de expirarea acestuia. Legăturile sigure cu serviciile afectate au fost respinse de la 13:37 UTC. ## Detectie Monitorizarea automată a început alerta cu privire la erori și lipsa traficului la 13:40 UTC, iar incidentul a fost declarat la 13:54 UTC. Certificatul expirat a fost identificat la ora 14:00 UTC, iar prima actualizare a paginii de stare a fost postată la ora 14:03 UTC. Nicio alertă nu a avertizat că certificatul se apropia de expirare, iar eșecurile repetate ale reînnoirii automatizate nu au fost raportate echipei proprii, astfel încât problema a fost detectată doar după ce clienții au fost afectați. ## Response La 14:06 UTC echipa a confirmat că certificatul a expirat deoarece reînnoirea automată a fost în criză. La 14:18 UTC a fost emis un nou acreditare pentru procesul de reînnoire. Reînnoirea a fost începută manual la 14:19 UTC și s-a încheiat la 14:33 UTC, iar până la 14:37 UTC s-a verificat dacă fiecare obiectiv cu care se confruntă clientul a fost notificat pentru a servi certificatul reînnoit. Traficul a revenit la niveluri normale cu aproximativ 14:40 UTC. După o perioadă de monitorizare, incidentul a fost rezolvat la 15:19 UTC. ## Follow-Up Pentru a preveni incidente similare în viitor, facem următoarele îmbunătățiri: - Alertă cu mult înainte de oricare dintre aceste certificate se apropie de expirare. - Anunţă echipa deţinătoare de fiecare dată când reînnoirea automată eşuează. - Adăugați controale care alertează imediat ce conexiunile securizate la aceste servicii nu reușesc. - Consolidarea dreptului de proprietate asupra procesului de reînnoire a certificatului și acreditările pe care se bazează.

Traducere automată din actualizarea oficială a incidentului.

1. 13 octombrie 2026 la 10:32 UTCinvestigating

   Investigăm problema în care jurnalele de execuţie nu apar în Orchestrator. ne străduim să determinăm întreaga sferă de aplicare și cauza rădăcină.

2. 13 octombrie 2026 la 10:57 UTCresolved

   Această problemă a fost rezolvată. Jurnalele de execuţie robot sunt sincronizate şi sunt vizibile în Orchestrator din nou pentru orchestratorul japonez. Mulţumesc pentru răbdare.

3. 22 octombrie 2026 la 13:25 UTCpostmortem

   ## Impactul clientului Între aproximativ 07:00 UTC pe 9 octombrie 2026 și 10:45 UTC pe 13 octombrie 2026, aproximativ 6% din intrările în jurnal robot pentru clienții din regiunea Japoniei nu au apărut în Orchestrator. Execuţia postului şi toate celelalte funcţionalităţi ale orchestratorului nu au fost afectate. Înregistrările lipsă au devenit vizibile în orchestrator după ce s-a rezolvat problema. ## Root cause Jurnalele robotului sunt plasate pe o coadă împărțită în 32 de partiții, iar un serviciu de ingestie citește fiecare partiție și stochează jurnalele pentru Orchestrator. Pe 9 octombrie, serviciul de ingestie din regiunea Japoniei a încetat să mai citească din 2 din cele 32 de partiții fără a raporta o eroare. Jurnalele acestor partiții au fost păstrate în coadă, dar nu au fost stocate, astfel încât nu au apărut în Orchestrator. Monitorizarea noastră a verificat serviciul în ansamblu, nu fiecare partiție, astfel încât problema nu a fost detectată automat. ## Detectie Problema a fost detectată prin rapoartele clienţilor. Am declarat un incident la 10:13 UTC pe 13 octombrie și am postat o notificare pe pagina de stare la 10:32 UTC. ## Response Am reluat serviciul de ingestie la aproximativ 10:41 UTC şi a reluat citirea tuturor partiţiilor. Jurnalele păstrate la coadă au fost apoi prelucrate și au devenit vizibile în orchestrator. Incidentul a fost rezolvat la 10:57 UTC. ## Follow up * Adăugăm monitorizarea care ne alertează atunci când orice partiție unică încetează să fie citită, astfel încât acest tip de problemă este detectat în câteva minute.

Traducere automată din actualizarea oficială a incidentului.

1. 7 octombrie 2026 la 21:34 UTCinvestigating

   Investigăm rapoarte despre o pană de curent care afectează eşecurile de creare a sarcinilor HITL pentru Maestro în SUA. Impact: Utilizatorii nu pot crea sarcini HITL. Următoarea actualizare: Echipele noastre lucrează pentru a înțelege cauza și domeniul de aplicare și va partaja actualizări ca disponibile.

2. 8 octombrie 2026 la 01:30 UTCidentified

   Am identificat cauza unei întreruperi care afectează crearea de sarcini HITL pentru Maestro în SUA şi lucrăm la atenuarea problemei. Impact: Utilizatorii nu pot crea sarcini HITL. Următoarea actualizare: Echipele noastre lucrează pentru a atenua problema și vor partaja actualizările ca disponibile.

3. 8 octombrie 2026 la 03:28 UTCmonitoring

   Suntem de rulare fix pentru o pană de impact HITL crearea de sarcini pentru Maestros cu HITL sarcină cronometre SLA configurate în SUA și sunt de lucru pentru a atenua problema. Impact: Utilizatorii pot fi în imposibilitatea de a crea sarcini HITL în cadrul Maestros cu sarcină HITL SLA configurate. Următoarea actualizare: Echipele noastre lucrează pentru a atenua problema și vor partaja actualizările ca disponibile.

4. 8 octombrie 2026 la 04:29 UTCresolved

   Fix pentru problema de impact crearea de sarcini HITL pentru Maestro cu HITL sarcin cronometre SLA configurate în SUA a fost complet rulat. Crearea de sarcini HITL a revenit la normal.

5. 26 octombrie 2026 la 03:16 UTCpostmortem

   ## Impactul clientului La 2026-10-05 între orele 9:30 UTC - 2026-10-07 3.30 AM UTC, Maestro BPMN și clienți de caz folosind noduri HITL cu un Task Timer configurat a văzut eșecuri ale cazurilor lor de depanare și producție în etapa HITL, cu 4xx . Au fost identificate aproximativ 30 de astfel de cazuri în rândul clienților din SUA și Europa, care au fost blocate fără niciun rezultat. ## Root cause Configurarea unei sarcini SLA necesită un obiect care să includă criteriile de început și de sfârșit, cronometrul SLA și rezultatul încălcării SLA. Clientii configura ca pe designerul Maestro pe nodul HITL. Rezultatul a fost menţinut din greşeală neobligatoriu pe suprafaţa de proiectare, chiar dacă o configuraţie SLA fără un rezultat nu este persistată şi nu are sens de afaceri. Echipa suport Centrul de acțiune a adăugat o validare pentru a arunca o cerere proastă (400) în cazul unui obiect SLA non nul cu un rezultat lipsă. Acest lucru a afectat clienții care au adăugat criteriile Start/End pe nod, dar nu au configurat un rezultat. Instanţele care au funcţionat anterior au eşuat cu 400 şi nu au putut relua ## Detectie Un client a raportat problema la Maestro Engineering IMM, care a ridicat-o intern cu echipa. Echipa Maestro a investigat acest eşec şi a observat un număr tot mai mare de eşecuri pentru USI şi alţi câţiva chiriaşi prin intermediul jurnalelor, care i-au condus să angajeze echipa Centrului de Acţiune. ## Response Echipa Maestro a primit un raport al problemei de la client prin e-mail, au făcut o investigaţie iniţială şi au identificat o posibilă regresie, în urma căreia, Centrul de Acţiune a fost angajat IMM-ul, problema reprodusă pe medii mai joase, o revenire a funcţiei aplicate şi testate, şi s-a rostogolit în toate regiunile afectate. S-a rezolvat cu toate cazurile rejudecate intern şi reluate. ## Follow up 1. Adăugați validare pentru acest scenariu pe toate suprafețele de bază de coduri de serviciu încrucișate pentru a asigura revizuirea umană 2. Adăugați testele de monitorizare și integrare necesare pentru a detecta această problemă mai repede

Traducere automată din actualizarea oficială a incidentului.

1. 7 octombrie 2026 la 17:37 UTCinvestigating

   Investigăm rapoarte de încetinire intermitentă și erori care afectează un subset de organizații din regiunea est-americană de Automatizare Cloud. Utilizatorii afectaţi pot vedea pagini în Orchestratorul UI nu reuşesc să încarce (de exemplu, pagina Jobs care returnează "O eroare a avut loc"), iar operaţiunile robotice, cum ar fi tranzacţiile la coadă şi sesiunea, pot începe intermitent time out. Vom oferi o actualizare de îndată ce mai multe informații sunt disponibile.

2. 7 octombrie 2026 la 18:13 UTCmonitoring

   Am aplicat o creştere a capacităţii infrastructurii de baze de date afectate din regiunea est-americană, iar ratele de eroare şi latenţa au revenit la niveluri normale. Vom oferi o actualizare de îndată ce mai multe informații sunt disponibile.

3. 7 octombrie 2026 la 19:06 UTCresolved

   Avem problema în regiunea est-americană și ratele de eroare și latența au revenit la niveluri normale.

4. 14 octombrie 2026 la 11:42 UTCpostmortem

   ## Impactul clientului Între orele 13:00 UTC și 18:15 UTC la 7 octombrie 2026, clienții din regiunea SUA au experimentat erori intermitente și răspunsuri lente în Orchestrator. Utilizatorii afectaţi pot fi văzut pagini Orchestrator nu reuşesc să încarce, de exemplu pagina Jobs returning Alte servicii UiPath care depind de Orchestrator pot fi, de asemenea, văzut răspunsuri mai lente sau erori în această perioadă. ## Root cause Câteva operaţiuni de orchestrare utilizate frecvent fiecare s-au bazat pe o resursă comună de scurtă durată în baza de date, inclusiv verificarea stării de rutină pe care o efectuează fiecare robot care rulează. Pe măsură ce volumul de activitate robotică concomitentă în această regiune a crescut, cererile au început să stea la coadă pentru a avea acces la acea resursă comună în loc să-și finalizeze activitatea. Efectul a fost mai degrabă selectiv decât o încetinire generală: operațiunile care au utilizat această resursă au fost întârziate, în timp ce altele au continuat să funcționeze normal. Deoarece procesorul de baze de date, memoria și utilizarea de stocare au rămas în limite normale, monitorizarea de rutină a capacității nu a indicat o problemă. ## Detectie Monitorizarea noastră automată a detectat degradarea în aproximativ 35 de minute de la începerea impactului asupra clientului, iar inginerii noştri au identificat disputa care stă la baza evenimentului. Deoarece aceasta a fost mai degrabă o problemă de dispută decât o lipsă de capacitate, și toți indicatorii de capacitate au fost normale, creșterea capacității de baze de date nu a fost de așteptat să-l rezolve, iar echipa a investigat alternative înainte de aplicarea acesteia. Această evaluare a întârziat atenuarea. ## Response Echipa noastră de inginerie a crescut capacitatea bazei de date afectate. Timpii de răspuns și ratele de eroare au revenit la normal imediat, și am continuat monitorizarea pentru a confirma serviciul a fost stabilă înainte de închiderea incidentului. * 13:00 : Ratele de eroare și timpii de răspuns încep să crească pentru clienții din regiunea SUA. * 13:36: Monitorizarea automată detectează degradarea și notifică echipa de inginerie de gardă. : Inginerii investighează. Toți indicatorii de capacitate standard de baze de date * 17:29: Un incident formal este declarat și echipa de răspuns completă este angajată. 17:38 O notificare publică este publicată pe [Statusul UiPath](http://status.uipath.com/) \ (Investigat\). * 17:31 * 18:00 : Ratele de eroare, timpii de răspuns și cererea de latență reveni la nivelurile normale. * 18:11 : Pagina de stare este actualizată la Monitoring & Client impact se termină. * 19:06 : Incidentul este închis după monitorizarea continuă confirmă că serviciul este stabil. ## Follow up Pentru a preveni acest lucru să se întâmple din nou, suntem: * Schimbarea operaţiunilor afectate astfel încât acestea să nu mai depindă de resursele comune. Acest lucru a fost lansat la toate sistemele afectate și a redus în mod substanțial condiția care a cauzat incidentul. * Activarea monitorizării detaliate a bazei de date pe aceste sisteme, astfel încât această clasă de dispută este vizibilă în timp ce aceasta se întâmplă mai degrabă decât după aceea. * Îmbunătăţirea vigilenţei noastre, astfel încât o degradare autentică de acest gen să poată fi diferenţiată în mod clar de variaţiile de rutină, de autocorectare, şi să fie escaladată mai repede.

Traducere automată din actualizarea oficială a incidentului.

1. 6 octombrie 2026 la 17:50 UTCinvestigating

   Investigăm rapoarte ale unei întreruperi a impactului asupra funcţionalităţii sau simptomului utilizatorului pentru orchestrator în Europa. Impact: Utilizatorii se pot aștepta la întârzieri pentru ingerarea jurnalelor robotului și/sau căutarea/display-ul jurnalelor. Niciun jurnal nu va fi pierdut. Următoarea actualizare: Echipele noastre lucrează pentru a înțelege cauza și domeniul de aplicare și va partaja actualizări ca disponibile.

2. 6 octombrie 2026 la 18:28 UTCidentified

   Am identificat cauza unei întreruperi a ingestiei de jurnale robotice pentru Orchestrator în Europa. Impact: Utilizatorii se pot aștepta la întârzieri pentru ingerarea jurnalelor robotului și/sau căutarea/display-ul jurnalelor. Niciun jurnal nu va fi pierdut. Următoarea actualizare: Echipele noastre lucrează pentru a înțelege cauza și domeniul de aplicare și va partaja actualizări ca disponibile.

3. 6 octombrie 2026 la 18:43 UTCmonitoring

   Am redus problema impactului ingestiei de busteni roboti pentru orchestrator în Europa. Impact: Utilizatorii se pot aștepta la întârzieri pentru ingerarea jurnalelor robotului și/sau căutarea/display-ul jurnalelor. Niciun jurnal nu va fi pierdut. Următoarea actualizare: Echipele noastre lucrează pentru a înțelege cauza și domeniul de aplicare și va partaja actualizări ca disponibile.

4. 6 octombrie 2026 la 18:44 UTCresolved

   Am redus problema impactului ingestiei de busteni roboti pentru orchestrator în Europa. Impact: Utilizatorii se pot aștepta la întârzieri pentru ingerarea jurnalelor robotului și/sau căutarea/display-ul jurnalelor. Niciun jurnal nu va fi pierdut. Următoarea actualizare: Echipele noastre lucrează pentru a înțelege cauza și domeniul de aplicare și va partaja actualizări ca disponibile.

5. 7 octombrie 2026 la 11:08 UTCpostmortem

   ## Impactul clientului Pe , între aproximativ 15:45 UTC și 18:45 UTC, clienții găzduiți în Europa, Australia și Japonia nu au putut vedea jurnalele recente ale roboților în Orchestrator. Jurnalele scrise în timpul ferestrei de impact nu au apărut în punctele de vedere Jobs and Logs sau prin intermediul API Robot Logs, iar jurnalele mai vechi de aproximativ 03:00 UTC în acea zi au fost disponibile doar intermitent. Fereastra de impact a fost diferită pe regiune: - Australia: aproximativ 15:45 UTC la 18:35 UTC - Europa: aproximativ 16:35 UTC - 18:00 UTC - Japonia: aproximativ 16:45 UTC - 18:30 UTC Execuția postului, cozile, declanșatoarele și toate celelalte funcționalități ale orchestratorului nu au fost afectate. Nu s-au pierdut jurnale robotice. Jurnalele produse în timpul ferestrei de impact au continuat să fie colectate și au devenit vizibile din nou odată ce problema a fost atenuată. ## Root cause Efectuam o actualizare programată a serviciului de cercetare Elastică care stochează jurnalele robotului Orchestrator. Actualizarea utilizează o abordare albastră/verde: un nou cluster este creat alături de cel existent, datele sunt restaurate în ea de la o rezervă, conducta care ingerează noi busteni este pornit pe ea, și numai atunci este traficul trecut peste. În regiunile afectate, comutatorul de trafic a fost aprobat de inginerul care rulează upgrade-ul înainte de restaurarea datelor și de ingestie-a terminat, care este o abatere de la procedura noastră de actualizare. Aceasta a fost o eroare umană. Ca urmare, Orchestratorul citea jurnalele roboților dintr-un grup care nu conținea încă date recente, în timp ce noile jurnale continuau să fie colectate, dar nu erau indexate încă pe cererile de servire a clusterului. Eroarea nu a fost prinsă deoarece instrumentul nostru de implementare se bazează pe operator pentru a verifica caracterul complet al datelor și nu aplică ordinul între restabilirea datelor și comutatorul de trafic. ## Detectie Monitorizarea noastră sintetică, care se execută continuu de locuri de muncă de testare și verifică faptul că jurnalele lor sunt returnate, jurnalele lipsă detectate în regiunile afectate și alerte ridicate. Echipa noastră de inginerie a corelat alertele cu upgrade-ul în curs de dezvoltare, a declarat un incident și a publicat o notificare pagina de stare. ## Response Echipa noastră de ingineri a returnat traficul către clusterele anterioare de cercetare Elastică din toate cele trei regiuni, care au restabilit imediat accesul la toate jurnalele robotului, inclusiv cele produse în timpul ferestrei de impact. Am confirmat recuperarea prin monitorizare sintetică în fiecare regiune afectată și am continuat monitorizarea înainte de marcarea incidentului rezolvat la aproximativ 18:45 UTC. Actualizarea noilor grupuri continuă în fundal. Traficul va fi mutat la ei numai după restabilirea datelor este completă și ingestie este confirmat a fi la zi. ## Follow up Pentru a preveni acest lucru să se întâmple din nou, suntem: - Schimbarea conductei de implementare astfel încât comutatorul de trafic să nu poată funcţiona până când datele restaurează şi ingerează noul grup sunt verificate ca fiind complete. - Adăugarea unui pas automat de răsturnare la conducta, astfel încât traficul poate fi returnat la grupul anterior în câteva minute în cazul în care o problemă este detectată după un comutator.

Traducere automată din actualizarea oficială a incidentului.

1. 6 octombrie 2026 la 12:38 UTCidentified

   Observăm performanţele degradate pentru serviciile din EAU

2. 6 octombrie 2026 la 12:43 UTCinvestigating

   În prezent investigăm această problemă.

3. 6 octombrie 2026 la 14:01 UTCidentified

   Am identificat problema ca fiind o problemă de rutare a rețelei cu un furnizor de servicii terț, care afectează conectivitatea pentru serviciile noastre găzduite în EAU. Colaborăm cu furnizorul nostru din amonte cu privire la rezoluție și vom actualiza progresele înregistrate aici.

4. 6 octombrie 2026 la 14:22 UTCidentified

   Continuăm să lucrăm la o soluție pentru această problemă.

5. 6 octombrie 2026 la 14:51 UTCmonitoring

   Monitorizăm conectivitatea și vom actualiza această pagină după confirmarea stabilității.

6. 6 octombrie 2026 la 15:09 UTCmonitoring

   Continuăm să monitorizăm orice alte probleme.

7. 6 octombrie 2026 la 17:09 UTCresolved

   Incidentul a fost rezolvat.

8. 21 octombrie 2026 la 05:36 UTCpostmortem

   ## Impactul clientului Între 12:38 PM UTC și 2:51 PM UTC, un subset de clienți din regiunea EAU au suferit eșecuri la accesarea serviciilor de cloud UiPath. Incidentul a durat aproximativ 2 ore şi 13 minute. Serviciile afectate au inclus accesul la **cloud.uipath.com**, **cont.uipath.com** Servicii găzduite în EAU. Clienții pot fi întâlnit timeouts, autentificare eșuată, conexiuni de resetare, sau erori de server. ## Root cause Cauza principală a fost o eroare de rutare a rețelei regionale la un furnizor de infrastructură terț. Un subset de căi de rețea de ieșire din regiunea UAN la anumite rețele externe Noile tentative de conectare de la serviciile afectate nu au primit răspunsuri, ceea ce a dus la expirarea termenului. Echipa noastră de ingineri a exclus configurarea serviciilor UiPath, politica la nivel de aplicaţii şi capacitatea de conexiune de ieşire ca cauze. Furnizorul de infrastructură a recunoscut o problemă cunoscută care afectează mai mulți clienți pe aceeași cale de rețea. ## Detectie Problema a fost detectată prin monitorizare automată. Până la aproximativ 12:40 p.m. ## Response Până la 1:20 pm UTC, echipa noastră de inginerie a confirmat că eșecul a fost limitat la trasee de rețea specifice, în timp ce alte destinații au rămas accesibile. Validarea a exclus modificările de rutare UiPath-side, modificările configurației de livrare a conținutului, politica la nivel de aplicație și problemele legate de capacitatea de conectare. S-a deschis un caz de sprijin de mare severitate cu furnizorul de infrastructură terț. La 1:50 pm UTC, furnizorul a recunoscut o problemă cunoscută care afectează mai mulți clienți. Echipa noastră a continuat monitorizarea recuperării de pe căile de rețea afectate și verificarea sănătății serviciilor pe măsură ce traficul a revenit. La 2:51 pm UTC, verificările de recuperare au confirmat că traficul UiPath prin căile afectate de livrare a conținutului a revenit la niveluri normale. Controalele automate de sănătate și indicatorii de servicii au confirmat recuperarea, iar serviciile din UAN au fost operaționale. ## Follow up 1. Urmărim acţiunile corective confirmate ale furnizorului de infrastructură şi analiza cauzelor profunde pentru eşecul rutei regionale. 2. Revizuim dependențele de servicii în afara regiunii afectate pentru a consolida reziliența împotriva unor perturbări similare ale rețelei terțe.

Traducere automată din actualizarea oficială a incidentului.

1. 2 octombrie 2026 la 16:23 UTCinvestigating

   De la aproximativ 15:05 UTC, unii clienți din regiunea SUA pot vedea locuri de muncă care rulează pe Cloud Roboți durează mai mult decât de obicei pentru a începe, sau să rămână în statul în așteptare. Locuri de muncă pe roboți proprii nu sunt afectate, și nici nu sunt alte regiuni. Am găsit cauza probabilă și sunt de lucru pentru a restabili procesarea normală a muncii. Locurile de muncă aflate deja la coadă nu se pierd și vor fi prelucrate după rezolvarea problemei. Vom posta o altă actualizare în 60 de minute.

2. 2 octombrie 2026 la 16:34 UTCmonitoring

   Am aplicat un fix pentru problema care întârzie locurile de muncă pe Cloud Roboți în regiunea SUA, iar locurile de muncă încep din nou în mod normal. Locurile de muncă întârziate sunt acum procesate. Suntem de monitorizare pentru a vă asigura că serviciul rămâne stabil și va posta o altă actualizare în 60 de minute.

3. 2 octombrie 2026 la 16:51 UTCmonitoring

   După continuarea lucrărilor pe această temă, locurile de muncă pentru Cloud Robots din regiunea SUA încep în mod normal. Locurile de muncă care au fost întârziate mai devreme sunt prelucrate. Continuăm să monitorizăm serviciul şi vom posta o altă actualizare după rezolvarea problemei.

4. 2 octombrie 2026 la 17:03 UTCresolved

   Această problemă a fost rezolvată. Între 15:05 și 16:39 UTC, locurile de muncă pe Cloud Roboți din regiunea SUA au fost lente pentru a începe sau a rămâne în statul în așteptare. Locurile de muncă încep în mod normal de la 16:39 UTC, iar locurile de muncă care au fost întârziate în această perioadă au fost acum prelucrate. Ne cerem scuze pentru întrerupere.

5. 14 octombrie 2026 la 14:20 UTCpostmortem

   ## Impactul clientului De la 15:00 la 16:38 UTC la 2026-10-02, locurile de muncă Cloud Robots din regiunea SUA au durat mai mult decât de obicei pentru a începe, până la 22 de minute în jurul orei 16:20 UTC. Orchestratorul a rămas disponibil, niciun loc de muncă nu a fost pierdut, nicio altă regiune nu a fost afectată. Un număr mic de clienți au primit o eroare de limită temporară privind noile observații în timp ce locurile lor de muncă anterioare așteptau. ## Detectie Alerte automate trase la 15:07 UTC, la şapte minute după impact. Controalele din regiunea SUA au eșuat de la aproximativ 15:32 UTC și a început răspunsul incidentului. ## Root cause La 14:55 UTC fluxul de lucru al unui client a început să depună locuri de muncă la aproximativ 20 de ori rata normală. Serviciul care admite locuri de muncă menține o numărătoare per client de numerar în baza de date și actualizează-l sub un sistem de baze de date de blocare pe fiecare loc de muncă începe și se încheie. La această rată coada de blocare pentru recordul clientului a crescut până la actualizări temporizate. Actualizările de așteptare au ocupat piscina comună de lucrători care începe locuri de muncă pentru toți clienții din regiune, astfel încât fiecare locuri de muncă ale clienților a așteptat în spatele lor. Mecanismul menit să izoleze încărcătura unui client a devenit blocajul. ## Response Echipa a identificat calea de intrare supraîncărcată şi volumul de muncă din spatele ei. O primă schimbare de configurație la 15:46 UTC a vizat înregistrarea greșită și nu a avut niciun efect. Modificarea corectă la 16:10 UTC a scutit tipul de loc de muncă al clientului de la blocarea bazei de date și a intrat în vigoare la aproximativ 16:20 UTC. Timpii de pornire au scăzut de la aproximativ 13 secunde la sub o secundă și backlog-ul de aproximativ 5200 de locuri de muncă drenate în 18 minute. Iov a început la 16:38 UTC. Declanşatorul clientului a fost oprit cu clientul la ora 16:40 UTC. ## Follow up Limitarea ratei blocate în baza de date este înlocuită cu un mecanism de limitare a ratei de performanță în memorie, astfel încât sarcina unui client nu poate bloca locul de muncă pentru alții. Modificarea este completă, testată în pre-producție la aceeași sarcină, și în curs de rulare.

Traducere automată din actualizarea oficială a incidentului.

1. 2 octombrie 2026 la 00:13 UTCinvestigating

   Investigăm în prezent o întrerupere care afectează portalul Insights din regiunea EAU. Utilizatorii din această regiune pot fi în imposibilitatea de a accesa portalul sau pot experimenta sarcini de pagină eșuate. Echipa noastră lucrează activ pentru a identifica cauza și a restabili serviciul. Vom oferi o altă actualizare de îndată ce vom avea mai multe informații.

2. 2 octombrie 2026 la 00:36 UTCidentified

   Am identificat o cale de atenuare și începem o revenire în regiunea EAU. Utilizatorii pot continua să experimenteze probleme intermitente de acces cu portalul Insights în timp ce această activitate este în curs de desfășurare. Vom furniza o altă actualizare odată ce rollback este completă.

3. 2 octombrie 2026 la 00:41 UTCmonitoring

   Portalul Insights din regiunea EAU se încarcă acum cu succes după revenirea noastră. Continuăm să monitorizăm serviciul pentru a confirma stabilitatea și vom furniza o actualizare finală odată ce suntem siguri că problema este pe deplin rezolvată.

4. 2 octombrie 2026 la 00:51 UTCresolved

   Portalul Insights din regiunea EAU operează acum în mod normal după răsturnare. Am validat funcționalitate portal cheie și a confirmat serviciul rămâne sănătos. Acest incident este acum rezolvat.

5. 5 octombrie 2026 la 22:58 UTCpostmortem

   ## Impactul clientului Pe 1 octombrie 2026**, serviciul UiPath **Insights** din regiunea **UAE** nu a fost disponibil. De la aproximativ **23:40 UTC la 1 octombrie până la 00:39 UTC la 2 octombrie**, utilizatorii nu au putut încărca Tablouri de bord Insights: cererile au eșuat cu o eroare după aproximativ 10 secunde. Solicitările de a oferi perspective pentru noii chiriaşi din regiune au eşuat. Întreruperea a durat aproximativ ** 59 minute**. Alte servicii UiPath din regiunea EAU și Insights din toate celelalte regiuni nu au fost afectate. Nu s-au pierdut date despre clienţi. ## Root Cause Căderea a fost cauzată de o schimbare **configurare** care a fost expediată într-o versiune programată Insights. Modificarea a ridicat versiunea ** minimală TLS \(Transport Layer Security\) ** privind obiectivele de aplicare ale Insights în regiunea EAU de la TLS 1.2 la **TLS 1.3**, ca parte a unui efort de întărire a securității. Poarta UiPath care direcţionează traficul clienţilor către Insights se conectează la aceste criterii de evaluare pe TLS 1.2. Odată ce obiectivele finale au încetat să mai accepte TLS 1.2, poarta nu mai putea deschide o conexiune sigură cu acestea. Clientul solicită timp și erori returnate, chiar dacă aplicația Insights însăși a rămas sănătoasă. Modificarea aplicată numai regiunii EAU, motiv pentru care nu a fost afectată nicio altă regiune. ## Detectie Problema a fost detectată de **Monitorizarea sintetică automată a lui UiPath**, care testează continuu disponibilitatea Insights din mai multe locații. Primul control medical eşuat a fost înregistrat la 23:40 UTC. Alerte automate trase în câteva minute, și echipa de inginerie de gardă a început investigarea. ## Response Echipa de inginerie a confirmat că pană a afectat doar Insights în regiunea EAU. Aplicația a fost difuzate în mod normal, dar nici un trafic client a fost ajunge la ea. Echipa a urmărit eșecul la pasul de conexiune securizată între poarta de acces și Insights, și a legat-o de setarea TLS aplicată de lansare. La aproximativ **00:38 UTC**, echipa a restaurat versiunea TLS minimă anterioară \ (TLS 1.2\) pe obiectivele afectate. Controalele de sănătate sintetice au început să treacă imediat, și de **00:41 UTC** toate verificările de Insights în regiunea EAU au fost sănătoase. Echipa a continuat monitorizarea pentru a confirma stabilitatea deplină. ## Follow-Up Pentru a preveni incidente similare în viitor, luăm următoarele măsuri: * ** Scoateți schimbarea TLS de la lansare**, astfel încât implementarea viitoare să nu-l re-aplice, până când poarta susține TLS 1.3 se termină. * **Validați modificările de securitate a conexiunii împotriva porții** într-un mediu pre-producție înainte ca acestea să fie aplicate producției.

Traducere automată din actualizarea oficială a incidentului.

1. 1 octombrie 2026 la 18:57 UTCinvestigating

   Începând cu 1 octombrie, la aproximativ 1:30 PM UTC, unii agenți, inclusiv agenți cu cod redus și agenți codați, au început să se confrunte cu eșecuri în toate regiunile atunci când se utilizează gemini-3.1-pro-previzualizare și gpt-4o-2024-05-13. Aceste modele pot fi, de asemenea, indisponibile pentru selecție în timpul proiectării agentului. Investigăm în mod activ și lucrăm la un fix.

2. 1 octombrie 2026 la 19:05 UTCidentified

   Am identificat problema și se desfășoară o fix. Agenţii care folosesc modelele afectate pot continua să experimenteze eşecuri, iar modelele pot rămâne indisponibile pentru selecţie în timpul proiectării agentului, în timp ce desfăşurarea se încheie.

3. 1 octombrie 2026 la 19:46 UTCresolved

   Am revenit la schimbarea care a cauzat această problemă și am confirmat că modelele afectate sunt disponibile din nou. Unii agenţi pot continua să prezinte eşecuri intermitente în timp ce în cazuri reîmprospătează. Continuăm să monitorizăm proiectarea şi execuţia agentului pentru gemini-3.1 pro-previzualizare şi gpt-4o-2024-05-13.

4. 7 octombrie 2026 la 10:15 UTCpostmortem

   ## Impactul clientului La 1 octombrie 2026, de la 14:31 la 19:40 UTC, agenții configurați cu unele modele lingvistice mari, inclusiv Gemini 3.1 Pro Preview și GPT-4o (2024-05-13), nu au reușit să înceapă în toate regiunile, cu o eroare în care modelul nu este disponibil. Aceleaşi modele lipseau din lista de modele în timp ce proiectau agenţi. Agenţii care utilizează alte modele nu au fost afectaţi. ## Root cause Un steag a fost răsturnat, ceea ce a determinat serviciul de agenți să înceapă trimiterea unui cod de operare pentru a modela cererile de descoperire. Acest lucru a dus la lista modelelor care au servit la acea operațiune specifică, spre deosebire de lista model de agenți de bază. Lista modelului de operaţiune a fost iniţial însămânţată din configuraţia Bring Your Own Model (BYOM) de modele supraridabile, care în mod crucial pentru agenţi nu au avut paritate cu lista completă de modele susţinute în serviciul agenţilor. Auditul intern a arătat că aceasta a fost o eroare și nu un decalaj intenționat. De-a lungul timpului, acest decalaj nu a fost niciodată abordat și după schimbarea pavilionului, agenții deja configurați cu oricare dintre modelele afectate ar eșua din cauza absenței lor din lista returnată. ## Detectie Un client a raportat problema, și a fost escaladat la inginerii noștri la 16:44 UTC. Monitorizarea noastră nu a alertat, deoarece această eroare indică, de obicei, probleme de organizare sau de configurare de nivel agent. ## Response Inginerii au urmărit defecțiunile la schimbarea configurației și l-au returnat la 19:01 UTC. Revert a intrat în vigoare în următoarele minute, iar ultimul eșec a avut loc la 19:40 UTC. ## Follow up 1. Modelele de liste vor fi aliniate înainte ca această schimbare să fie refăcută. 2. Schimbăm modul în care această eroare este clasificată astfel încât o platformă-pike alertează inginerii noștri.

Traducere automată din actualizarea oficială a incidentului.

1. 1 octombrie 2026 la 18:17 UTCinvestigating

   Incepand cu 1 octombrie la ora 12:00 PM UTC, utilizatorii comunitatii din Europa pot experimenta esecuri in agentii LowCode care folosesc aplicatii de actiune locale solutii. Am confirmat că impactul este limitat la utilizatorii comunitari din Europa. Investigăm în mod activ problema, determinăm amploarea eşecurilor şi lucrăm la o soluţie.

2. 1 octombrie 2026 la 18:25 UTCidentified

   Am identificat problema care cauzează eșecuri în agenții cu cod redus care utilizează aplicații de acțiune locală-soluție pentru utilizatorii comunitari din Europa. Returnăm modificările anterioare şi continuăm să monitorizăm recuperarea. Vom oferi o altă actualizare odată ce rollback este completă sau dacă avem informații suplimentare pentru a partaja.

3. 1 octombrie 2026 la 20:08 UTCresolved

   Am confirmat că reluarea a fost finalizată și că problema care afectează agenții cu cod redus care utilizează aplicații de acțiune locală-soluție pentru utilizatorii comunitari din Europa a fost rezolvată. Serviciile s-au recuperat şi închidem acest incident.

4. 7 octombrie 2026 la 14:28 UTCpostmortem

   ## Impactul clientului La 1 octombrie 2026, de la 10:50 la 19:50 UTC, unii utilizatori de Web Studio din Europa nu au putut depana agenți care numesc procesele Orchestrator (RPA, agenți, etc.) sau aplicații de acțiune din aceeași soluție. Apelul a eșuat cu o eroare "negăsită." Agenţii publici şi locurile de muncă de producţie nu au fost afectate. ## Root cause O actualizare Web Studio a schimbat modul în care resursele de soluţie sunt localizate în timpul depanarii. Lipsea un set care menţine comportamentul anterior, aşa că debug rulează căutat pentru resursele soluţiei în spaţiul personal de lucru al utilizatorului în loc de dosarul de depanare. ## Detectie Testele automate au alertat inginerii noştri la 16:43 UTC. Apartamentul de testare de la un capăt la altul se execută o dată la două ore și alertarea are loc numai după 3 eșecuri consecutive ale încercării. Problema a fost, de asemenea, raportată dintr-un mediu al clienților. ## Response După identificarea cauzei rădăcinii, s-a început o răsturnare la ora 18:00 UTC și a fost în vigoare la ora 19:50 UTC. Această durată a inclus un eșec de desfășurare care a trebuit să fie rejudecată, care a durat 50 de minute. O versiune corectată care include setarea a fost implementată pe 2 octombrie la ora 13:00 UTC. ## Follow up 1. Setarea este acum parte a liniei de cod principal, astfel încât viitoarele versiuni includ. 2. Îmbunătățim alertele și suita de testare la sfârșit pentru a prinde regresii mai devreme.

Traducere automată din actualizarea oficială a incidentului.

1. 1 octombrie 2026 la 16:32 UTCresolved

   Între 14:23 și 16:04 UTC la 1 octombrie 2026, unele cereri de ștergere a articolelor din serviciile UiPath Automation Cloud din regiunea australiană au eșuat cu erorile "440 Not Found." Serviciile afectate includ Orchestrator, Înțelegerea documentelor, Centrul AI și Serviciul de date. Alte operațiuni, cum ar fi vizualizarea, crearea și actualizarea articolelor, au funcționat în mod normal. Cauza a fost o schimbare de configurare la rutarea cererii noastre. L-am rulat înapoi și serviciul este complet restaurat.

2. 7 octombrie 2026 la 10:15 UTCpostmortem

   ## Impactul clientului Intre 1 octombrie 2026 la 2:23 pm UTC si 4:04 pm UTC, un subset de clienti cu experienta **404 Not Found** erori pentru unele cereri UiPath Automation Cloud in Australia. Incidentul a durat o oră şi 41 de minute. Cererile afectate au inclus ştergerea operaţiunilor şi unele verificări ale conexiunii roboţilor. Serviciile afectate includ Orchestrator, Înțelegerea documentelor, Centrul AI și Serviciul de date. Locuri de muncă robot care numit Orchestrator poate fi eșuat, și clienții pot avea nevoie pentru a relua orice locuri de muncă robot care nu a reușit în timpul acestei ferestre. Toate celelalte operațiuni nu au fost afectate. ## Root cause O schimbare de configurație de rutare a fost aplicată regiunii Australia cu un set incomplet de operațiuni sprijinite din cauza unui timeout în conducta de lansare. Ştergerea operaţiunilor lipseau din configuraţie, aşa că acele cereri au fost respinse la nivelul de rutare cu **404 Not Found** înainte de a ajunge la serviciile de bază. ## Detectie Monitorizarea automată de la un capăt la altul a detectat problema prin alertarea cu privire la defecțiunile controalelor serviciilor de înțelegere a documentelor. Echipa noastră de inginerie a folosit apoi date interne de monitorizare pentru a confirma modelul mai larg de eșecuri în cadrul serviciilor afectate. ## Response În cursul anchetei, datele de monitorizare au arătat că cererile rutate prin regiunea Australiei se întorceau **404 Nu au fost găsite** erori, în timp ce cererile rutate prin alte regiuni nu au fost afectate. Analiza a identificat faptul că ora de începere a creşterii răspunsului **404 Negăsit** a fost corelată cu momentul în care a intrat în vigoare configurarea traseului. Echipa a revenit configurația de rutare la versiunea de lucru anterioară. După retur, monitorizarea a arătat că numărul erorilor scade în aproximativ trei minute, iar serviciul a fost restaurat complet până la 1 octombrie 2026 la 4:04 pm UTC. ## Follow up 1. Îmbunătățește alertele pe strat de rutare privind modificările de bază 4xx 2. Detectează configuraţiile de rutare aplicate parţial înainte ca acestea să intre în vigoare

Traducere automată din actualizarea oficială a incidentului.

1. 1 octombrie 2026 la 13:21 UTCinvestigating

   Echipa noastră lucrează activ la un fix pentru performanţele degradate care afectează Orchestratorul din regiunea SUA. Vom împărtăși actualizările pe măsură ce se înregistrează progrese.

2. 1 octombrie 2026 la 14:06 UTCidentified

   În prezent este în curs de desfăşurare o fixare pentru performanţele degradate care afectează Orchestratorul şi Centrul de Acţiune din regiunea SUA. Vor urma noi actualizări.

3. 1 octombrie 2026 la 14:24 UTCmonitoring

   A fost implementat un fix pentru performanţele degradate care afectează Orchestratorul şi Centrul de Acţiune din regiunea SUA. Echipa noastră monitorizează în mod activ rezultatele pentru a confirma că problema este pe deplin rezolvată.

4. 1 octombrie 2026 la 17:58 UTCmonitoring

   A fost implementat un fix pentru performanţele degradate care afectează Orchestratorul şi Centrul de Acţiune din regiunea SUA. Continuăm să monitorizăm performanța sistemului și stabilitatea pentru a confirma că problema este pe deplin rezolvată. Alte actualizări vor fi furnizate pe măsură ce devin disponibile mai multe informații.

5. 1 octombrie 2026 la 19:03 UTCresolved

   Performanţele degradate care afectează Orchestratorul şi Centrul de Acţiune din regiunea SUA au fost rezolvate. Performanţele sistemului au rămas stabile după fixarea implementată şi vom continua monitorizarea standard.

6. 5 octombrie 2026 la 06:40 UTCpostmortem

   ## Impactul clientului Între aproximativ 11:00 UTC și 13:40 UTC la 1 octombrie 2026, clienții din regiunea SUA au observat timpi de răspuns mai lent Orchestrator și temporizări intermitente. Roboților le-a luat mai mult timp să înceapă să lucreze, să proceseze elementele din coadă și să citească activele, iar unele dintre aceste cereri au eșuat. Alte servicii UiPath care se bazează pe Orchestrator au fost, de asemenea, afectate în timp ce Orchestratorul a fost degradat, și poate au văzut răspunsuri mai lente sau erori. ## Root cause Un orchestrator a stabilit implementarea a inclus o modificare a modului în care capacitatea de calcul este rezervată și scalată pentru serviciile noastre. Schimbarea a fost menită să utilizeze infrastructura noastră mai eficient, dar a redus capacitatea de procesare disponibilă Orchestratorului. În perioadele aglomerate scalarea noastră automată nu a sporit capacitatea aşa cum era de aşteptat, astfel încât serviciul nu a putut ţine pasul cu cererea. ## Detectie Monitorizarea noastră internă a detectat încetinirea după actualizare. Primul nostru plan a fost de a lansa o actualizare corectată prin procesul nostru standard de eliberare, care durează mai multe ore. Când au început să apară rapoartele clienţilor, am deschis un incident şi ne-am mutat într-o situaţie mai rapidă. ## Response Echipa noastră de inginerie a aplicat setările de capacitate anterioare direct la serviciile afectate, fără a aștepta actualizarea corectată. Timpul de răspuns a revenit la normal la aproximativ 13:40 UTC, și am continuat monitorizarea pentru a confirma serviciul a fost stabilă. ## Follow up Pentru a preveni acest lucru să se întâmple din nou, suntem: - Restaurarea permanentă a setărilor de capacitate anterioare și revizuirea eventualelor modificări ale capacității față de sarcina de nivel de producție înainte de lansare. - Îmbunătăţirea modului în care evaluăm impactul asupra clienţilor în timpul degradărilor, astfel încât aceştia să fie escaladaţi la un incident mai devreme. - Facindu-l mai rapid pentru a rula înapoi capacitatea și schimbările de configurare atunci când afectează clienții.

Traducere automată din actualizarea oficială a incidentului.