Istoricul incidentelor Uipath

1. 3 septembrie 2026 la 15:34 UTCinvestigating

   În prezent investim problema

2. 3 septembrie 2026 la 15:39 UTCidentified

   Problema a fost identificată și au fost puse în aplicare măsurile adecvate de atenuare a riscurilor.

3. 3 septembrie 2026 la 15:47 UTCmonitoring

   Problema a fost rezolvată cu succes, iar serviciul a fost restabilit complet. Serviciul funcționează normal în acest moment.

4. 3 septembrie 2026 la 16:17 UTCresolved

   Problema a fost rezolvată cu succes, iar serviciul a fost restabilit complet. Serviciul funcționează normal în acest moment.

Traducere automată din actualizarea oficială a incidentului.

1. 4 septembrie 2026 la 17:48 UTCresolved

   Tabloul de bord Insights din Looker a experimentat o problemă care a împiedicat ultimele alergări Maestro, să apară în tabloul de bord Regiuni afectate: SUA, SEA, IND, CA, AUE, JP, UK Cronologie incident Start: 2 septembrie 2026 la ora 20:00 UTC Rezolvat: 4 septembrie 2026 la ora 16:30:00 UTC Problema a fost rezolvată în prezent, iar tabloul de bord Insights afişează ultimele date ale Maestro Run.

Traducere automată din actualizarea oficială a incidentului.

1. 1 septembrie 2026 la 13:49 UTCinvestigating

   Investigăm rapoarte ale digitizării şi extragerii performanţelor degradate pentru înţelegerea documentelor şi IXP în SUA. Impact: Utilizatorii pot experimenta încetinirea și eșecul operațiunilor de punere în aplicare a înțelegerii documentelor. Echipele noastre lucrează pentru a identifica cauza și vor împărtăși mai multe detalii pe măsură ce ancheta progresează.

2. 1 septembrie 2026 la 14:07 UTCmonitoring

   Am identificat problema și am aplicat o atenuare. Serviciile sunt returnate la starea de sănătate și monitorizăm serviciile.

3. 1 septembrie 2026 la 15:06 UTCresolved

   Această problemă a fost rezolvată pe deplin, iar serviciile sunt stabile acum. Vom posta mai multe detalii despre incident la pagina de stare în curând.

Traducere automată din actualizarea oficială a incidentului.

1. 31 august 2026 la 16:55 UTCinvestigating

   În prezent investigăm problema.

2. 31 august 2026 la 17:07 UTCidentified

   Am identificat problema și am pus în aplicare fix necesar

3. 31 august 2026 la 18:24 UTCmonitoring

   Problema a fost atenuată, iar serviciul este în prezent operațional. Vom continua să monitorizăm îndeaproape sănătatea serviciilor și să luăm măsuri suplimentare, dacă este necesar.

4. 31 august 2026 la 19:39 UTCresolved

   Problema a fost atenuată, iar serviciul este în prezent operațional. Vom continua să monitorizăm îndeaproape sănătatea serviciilor și să luăm măsuri suplimentare, dacă este necesar.

Traducere automată din actualizarea oficială a incidentului.

1. 28 august 2026 la 15:41 UTCidentified

   Problema a fost identificată, iar echipa lucrează activ la implementarea unui fix. Ne aşteptăm ca desfăşurarea să înceapă în următoarele ore.

2. 28 august 2026 la 17:27 UTCmonitoring

   Am identificat cauza principală a performanţei degradate şi suntem în curs de desfăşurare a unui fix în următoarele ore. Acesta afectează întrebările legate în cazul în care utilizatorul nu are acces la dosarul original. Suprafaţa API nu este afectată. Exportul prin intermediul CSV poate fi utilizat ca mijloc de lucru. Se vor furniza actualizări suplimentare pe măsură ce ne îndreptăm către rezoluție.

3. 28 august 2026 la 17:39 UTCidentified

   Am identificat cauza principală a performanţei degradate şi suntem în curs de desfăşurare a unui fix în următoarele ore. Acesta afectează întrebările legate în cazul în care utilizatorul nu are acces la dosarul original. Suprafaţa API nu este afectată. Exportul prin intermediul CSV poate fi utilizat ca mijloc de lucru. Se vor furniza actualizări suplimentare pe măsură ce ne îndreptăm către rezoluție.

4. 28 august 2026 la 20:00 UTCidentified

   Fix este în curs de aplicare. Vom furniza o altă actualizare în scurt timp după ce implementarea va fi finalizată în toate regiunile afectate.

5. 28 august 2026 la 22:57 UTCresolved

   Fixarea a fost implementată cu succes în toate regiunile și am validat că problema este rezolvată. Serviciul funcţionează conform aşteptărilor.

6. 3 septembrie 2026 la 08:49 UTCpostmortem

   ## Impactul clientului Intre 28 august 2026 la 3:23 pm UTC si 28 august 2026 la 10:57 pm UTC, un subset de clienti au experimentat erori atunci cand au deschis panourile de detalii ale punctului coada in Orchestrator. Calea afectată a returnat o pagină 404 pentru cozile Linked atunci când utilizatorul NU a avut acces la dosarul original în care au fost create elementele. Impactul a afectat doar interacțiunile Orchestrator UI și s-a extins în toate regiunile care rulează versiunea software afectată. Accesul la interfaţa de programare a orchestratorului nu a fost afectat, iar exportul datelor din coadă către CSV a fost disponibil ca o soluţie. Durata totală a fost de aproximativ 7 ore. ## Root cause Incidentul a fost cauzat de o regresie în interfaţa de utilizator Orchestrator pentru cozi conectate accesate din alte foldere. Regresia nu a manipulat corect fluxul de detalii legate-queue atunci când utilizatorul solicitant nu a avut acces la dosarul original, ceea ce a cauzat panoul de detalii a punctului de coadă la ruta la o pagină 404 în loc de afișarea informațiilor preconizate. ## Detectie Problema a fost detectată printr-o alertă automată de incident pentru partea frontală a orchestratorului la 28 august 2026 la 3:23 pm UTC. ## Response La 3:31 pm UTC pe 28 august 2026, echipa noastră de inginerie a descris problema ca fiind clientii care nu pot accesa panourile de detalii ale punctului de coada din cauza unei regresii. La 3:41 pm UTC, o actualizare a stării publice a confirmat faptul că cauza principală a fost identificată, că a fost implementată o fixare și că accesul la interfața de programare a aplicațiilor nu a fost afectat. La 5:27 pm UTC, domeniul de aplicare a fost redus la cozi legate în cazul în care utilizatorul nu a avut acces la dosarul original. La 5:29 pm UTC, echipa a stabilit că fix inițial nu a abordat pe deplin scenariul afectat, și a fost dezvoltat un fix corectat. La 5:30 pm UTC, scenariul afectat a fost reprodus și fixa corectată a fost validată local. La 5:39 pm UTC, o actualizare pagina de stare documentat CSV export ca un workaround. Punerea în aplicare a stabilităţii corectate a continuat în toate regiunile afectate. La 10:50 pm UTC, fix a fost confirmat desfășurat peste tot. La 10:57 pm UTC, incidentul a fost marcat rezolvat şi pagina de stare a fost actualizată pentru a confirma că serviciul funcţiona conform aşteptărilor. ## Follow up Acțiunile formale de monitorizare sunt urmărite prin procesul de revizuire post-incidență inițiat la rezoluție. ## Action items - Extinderea cazurilor noastre de testare automatizată pentru a include acest scenariu, și alte scenarii similare legate de obiecte legate sau scenarii încrucişate. - Asigurarea că putem opri în siguranță orice modificări prin intermediul unui steag pentru un timp de răspuns mai rapid.

Traducere automată din actualizarea oficială a incidentului.

1. 27 august 2026 la 17:16 UTCinvestigating

   Investigăm rapoarte ale jurnalelor roboţilor dispăruţi din regiunea SUA. Echipele noastre lucrează pentru a identifica cauza și vor împărtăși mai multe detalii pe măsură ce ancheta progresează.

2. 27 august 2026 la 18:53 UTCidentified

   Am identificat că ingestiea roboţilor a fost întârziată. Jurnalele roboţilor ajung la date în direct şi noi monitorizăm recuperarea.

3. 27 august 2026 la 20:31 UTCmonitoring

   Jurnalele se populează în timp real și vom continua monitorizarea aplicației.

4. 27 august 2026 la 21:57 UTCresolved

   Problema a fost rezolvată şi jurnalele sunt populate conform aşteptărilor.

Traducere automată din actualizarea oficială a incidentului.

1. 25 august 2026 la 09:41 UTCidentified

   Am identificat o problemă care afectează funcția de desfășurare a soluțiilor în Studio Web din regiunea Japoniei, unde implementarea soluțiilor ar putea da faliment. Un fix a fost pregătit şi va fi lansat în scurt timp. Vom furniza actualizări suplimentare pe măsură ce vor fi disponibile mai multe informații.

2. 25 august 2026 la 09:47 UTCmonitoring

   Fixarea a fost implementată cu succes în regiunea Japoniei, iar problema a fost atenuată. Monitorizăm îndeaproape serviciul pentru a ne asigura că implementarea soluţiei continuă să funcţioneze conform aşteptărilor şi va oferi actualizări suplimentare, după cum este necesar.

3. 25 august 2026 la 10:12 UTCresolved

   Problema a fost rezolvată, iar implementarea soluţiilor în Studio Web funcţionează conform aşteptărilor din Japonia. Nu s-a observat niciun alt impact.

Traducere automată din actualizarea oficială a incidentului.

1. 25 august 2026 la 03:58 UTCinvestigating

   Investigăm o problemă care afectează clienții care utilizează Insights în regiunea Singapore, unde tablourile de bord pot să nu încarce și să afișeze erori de pauză. Echipele noastre lucrează la identificarea cauzei profunde și vor oferi actualizări suplimentare pe măsură ce devin disponibile mai multe informații.

2. 25 august 2026 la 04:37 UTCmonitoring

   Problema a fost atenuată şi monitorizăm îndeaproape serviciul Insights din regiunea Singapore pentru a ne asigura că tablourile de bord continuă să se încarce, aşa cum ne aşteptam.

3. 25 august 2026 la 04:53 UTCresolved

   Problema a fost rezolvată, iar serviciul Insights din regiunea Singapore funcționează conform așteptărilor. Nu s-a observat niciun alt impact.

4. 4 septembrie 2026 la 11:46 UTCpostmortem

   ## Impactul clientului Între 25 august 2026 la 3:42 am UTC și 25 august 2026 la 4:53 am UTC, clienții care utilizează Insights în regiunea Singapore au suferit eșecuri la încărcarea tablourilor de bord Insights. Utilizatorii afectaţi au văzut pagini de bord time out sau nu se încarcă, iar erorile serverului au fost observate pentru cererile de servicii conexe. Impactul principal a fost accesul la tabloul de bord Insights, inclusiv hărți și alerte. Un serviciu de backend aferent a returnat și erori de server în timpul incidentului, dar accesul la tabloul de bord a fost recuperat înainte de rezoluția finală. ## Root cause Incidentul a fost atribuit unei întreruperi regionale a serviciilor Microsoft în Singapore care afectează infrastructura utilizată de serviciul Insights. În timpul întreruperii, serviciul Insights nu a putut servi în mod fiabil cererile de bord, ceea ce a dus la timeouts cerere și erori de server. Nu s-au făcut schimbări de partea noastră. Serviciul s-a recuperat pe măsură ce perturbarea regională Microsoft a fost rezolvată, iar Microsoft a raportat ulterior o problemă de serviciu regional din Singapore pe pagina sa de stare. Microsoft a solicitat o analiză oficială a cauzelor profunde pentru a confirma mecanismul specific de eșec și a identifica orice măsuri suplimentare de prevenire sau atenuare. ## Detectie Monitorizarea automata a sanatatii serviciului Insights a detectat problema la 25 august 2026 la 3:42 am UTC. Impactul clientului a fost confirmat pe puntea de răspuns la scurt timp după detectare. ## Response La 25 august 2026 la 3:58 am UTC, am postat o actualizare a stării publice, observând că tablourile de bord Insights din regiunea Singapore ar putea să nu încarce și să afișeze erori de temporizare. În timpul răspunsului, echipa noastră de inginerie a verificat erorile de server în monitorizarea automată, a încercat să acceseze diagnosticarea serviciilor, și a început o procedură de recuperare pe infrastructura de bază. La 25 august 2026 la 4:01 am UTC, serviciul Insights s-a recuperat în timp ce procedura de recuperare era în curs, iar încărcarea tabloului de bord a fost validată în mai multe conturi de testare. La 25 august 2026 la 4:37 am UTC, am mutat incidentul la monitorizare după confirmarea bordurilor încărcate cu succes. Un serviciu de suport aferent recuperat la 25 august 2026 la 4:49 am UTC, iar incidentul a fost marcat rezolvat la 25 august 2026 la 4:53 am UTC. ## Follow up 1. Solicitați o analiză a cauzelor profunde de la Microsoft pentru perturbarea regională din Singapore care afectează problema de încărcare a tablourilor de bord.

Traducere automată din actualizarea oficială a incidentului.

1. 25 august 2026 la 03:44 UTCinvestigating

   Investigăm o problemă care afectează clienții care utilizează funcționalitatea extinsă a OCR în serviciul de înțelegere a documentelor din regiunea Singapore. Echipele noastre lucrează la identificarea cauzei profunde și vor oferi actualizări suplimentare pe măsură ce devin disponibile mai multe informații.

2. 25 august 2026 la 04:04 UTCmonitoring

   Problema a fost atenuată şi monitorizăm îndeaproape serviciul pentru a ne asigura că acesta va continua să funcţioneze conform aşteptărilor. Vom furniza actualizări suplimentare pe măsură ce vor fi disponibile mai multe informații.

3. 25 august 2026 la 04:59 UTCresolved

   Problema a fost rezolvată, iar serviciul funcționează conform așteptărilor. Nu s-a observat niciun alt impact.

4. 27 august 2026 la 03:42 UTCpostmortem

   ## Impactul clientului La 25 august 2026, cererile extinse de OCR în serviciul de înțelegere a documentelor au eșuat cu 500 de coduri de stare în regiunea Singapore timp de aproximativ 33 de minute, între 03:08 și 03:41 UTC. Cauza a fost o întrerupere a serviciului regional Microsoft în Singapore. Toate celelalte funcții de înțelegere a documentelor nu au fost afectate și nicio altă regiune nu a fost afectată. ## Root cause Eșecul a fost atribuit unei întreruperi regionale a serviciilor Microsoft în Singapore care afectează resursele utilizate de capacitatea extinsă a OCR. Nu s-au făcut modificări de partea noastră, iar Microsoft și-a actualizat pagina de stare pentru a reflecta o problemă regională din Singapore. O analiză oficială a cauzei a fost solicitată de la Microsoft. ## Detectie O alertă automată pentru serviciul de înțelegere a documentelor tras la 25 august 2026 la 3:13 am UTC. Alerta a fost recunoscută cu promptitudine, iar incidentul a fost declarat un impact al clientului în câteva minute. ## Response Inginerul de gardă a cercetat impactul asupra regiunii Singapore. Respondenţii au exclus o actualizare recentă a serviciilor ca cauză, întrucât aceeaşi actualizare a fost implementată în alte regiuni fără impact comparabil, ceea ce a indicat un eşec al dependenţei regionale în afara infrastructurii noastre. Deoarece eșecul a apărut într-un serviciu Microsoft în amonte, nu a fost disponibilă nicio acțiune de atenuare sau necesară pe partea UiPath. Cererile au început din nou să aibă succes la 03:41 UTC pe măsură ce dependența de Microsoft și-a revenit. Respondenții au susținut incidentul deschis pentru a verifica recuperarea susținută: zece minute de trafic curat au fost confirmate la 03:51 UTC, incidentul a trecut la monitorizare la 04:04 UTC și a fost rezolvat la 04:59 UTC după menținerea stabilității fără alte defecțiuni. ## Follow up 1. Am solicitat o analiză a cauzelor profunde de la Microsoft pentru perturbarea regională din Singapore care afectează dependențele extinse ale OCR, inclusiv modul în care recurența poate fi prevenită.

Traducere automată din actualizarea oficială a incidentului.

1. 24 august 2026 la 10:43 UTCidentified

   Am identificat cauza unei probleme care afectează un număr mic de clienți care utilizează UiPath Apps autori din serviciul Web Studio în mai multe regiuni. Echipele noastre sunt pregătite cu un fix, iar desfăşurarea este pe cale să înceapă în regiunile afectate. Vom continua să monitorizăm implementarea și să oferim actualizări suplimentare pe măsură ce fixarea produce efecte.

2. 24 august 2026 la 11:30 UTCmonitoring

   Fixarea a fost implementată cu succes în toate regiunile afectate, iar problema a fost atenuată. Monitorizăm îndeaproape serviciul pentru a ne asigura că fixul continuă să funcţioneze conform aşteptărilor şi că va oferi actualizări suplimentare, după cum este necesar.

3. 24 august 2026 la 11:55 UTCresolved

   Problema a fost rezolvată, iar serviciul funcționează conform așteptărilor. Nu s-a observat niciun alt impact.

4. 1 septembrie 2026 la 11:47 UTCpostmortem

   ## Impactul clientului Între 19 august 2026 la 2:33 pm UTC și 24 august 2026 la 11:30 am UTC, un subset de clienți nu a putut încărca UiPath Apps proiecte de autor de la Studio Web. Clienții afectați s-au confruntat cu indisponibilitatea completă a proiectelor Apps mai degrabă decât cu încetinire sau performanță degradată. Impactul a fost limitat la un set mic de clienți, al căror serviciu Apps a fost găzduit în regiunea Japonia. Durata totală a impactului asupra clienţilor a fost de aproximativ 4 zile şi 21 ore. ## Root cause Cauza principală a fost o nepotrivire a implementării între Studio Web și UiPath Apps. La 19 august 2026, Studio Web a primit o actualizare programată în regiunea UE, care a inclus o actualizare a cadrului. Actualizarea corespunzătoare UiPath Apps care conține actualizarea cadrului nu a fost încă implementată în unitatea de scară Japonia. O actualizare a aplicațiilor anterioare, care era deja compatibilă cu noua versiune-cadru, a fost trimisă în toate regiunile, cu excepția Japoniei, unde implementarea a fost amânată din motive independente. Prin urmare, regiunea Japonia încă mai conducea o versiune mai veche a Aplicațiilor care nu era compatibilă cu pagina web a Studioului actualizată. ## Detectie Problema a fost raportată de un client prin intermediul echipei de cont UiPath la 24 august 2026 la 9:36 am UTC. Un incident a fost deschis la 10:21 am UTC, și un incident pagina de stare publică a fost declarat într-un minut. Monitorizarea automată existentă nu a detectat problema deoarece validează combinaţiile de implementare corespunzătoare; îmbunătăţirea detecţiei configuraţiilor mixte face parte din planul nostru de urmărire. ## Response În câteva minute de la deschiderea incidentului, am identificat nepotrivirea de implementare ca fiind cauza principală și am decis să accelerăm implementarea actualizării Aplicațiilor UiPath corespunzătoare către toate regiunile afectate, aliniind aplicațiile cu versiunea Studio Web deja servită clienților afectați. La 10:43 am UTC, am postat o actualizare a stării publice care confirma că cauza a fost identificată și că fix a fost implementat. La ora 10:52 am UTC, implementarea a fost în curs de desfășurare pentru restul regiunilor, mai multe regiuni fiind deja finalizate. La 11:30 am UTC, am confirmat că fix a fost implementat în toate regiunile afectate și a marcat incidentul atenuat. La 11:55 am UTC, după ce monitorizarea nu a mai arătat niciun impact, incidentul a fost rezolvat. ## Follow up 1. Adăugați alertarea automată privind telemetria de producție pentru a detecta defecțiunile de încărcare Aplicații corelate cu versiunea Studio Web fiind servită. 2. Punerea în aplicare a monitorizării sintetice care încarcă în mod regulat un proiect Apps autor de la Studio Web prin intermediul configuraţiilor reprezentative ale clienţilor şi alerte privind eşecul. 3. Reglați secvențierea lansării pentru modificările bine cuplate Studio Web și Aplicații, astfel încât actualizările de aplicații dependente să fie pe deplin implementate în toate regiunile înainte ca noua experiență Studio Web să ajungă la traficul clienților.

Traducere automată din actualizarea oficială a incidentului.

1. 21 august 2026 la 12:37 UTCmonitoring

   S-a pus în aplicare o fixare a chestiunii care afectează clasificarea și extragerea documentelor pentru înțelegerea documentelor în SUA și în prezent monitorizăm rezultatele.

2. 21 august 2026 la 13:36 UTCresolved

   Problema care afectează clasificarea și extracția documentelor pentru înțelegerea documentelor în regiunea SUA a fost rezolvată. După o perioadă de monitorizare, serviciul este confirmat sănătos și funcționează normal.

3. 27 august 2026 la 03:46 UTCpostmortem

   ## Impactul clientului În perioada 21 august 2026 la 11:05 am UTC și 21 august 2026 la 12:18 pm UTC, un subset de clienți au experimentat operațiuni de înțelegere a documentelor eșuate, inclusiv clasificarea documentelor, extracția și digitalizarea. Durata estimată a întreruperii parțiale a fost de 48 minute. Impactul s-a limitat la clienții care utilizează înțelegerea documentelor în regiunea SUA. ## Root cause Incidentul a fost cauzat de configurarea bazei de date de stocare a documentelor de înțelegere care a intrat într-un stat defect în timpul unei operațiuni preventive de scară-up a bazei de date. Majorarea a fost iniţiată după ce baza de date s-a apropiat de limita de stocare. În timpul operațiunii, baza de date secundară nu a putut fi scalată, încercarea de îndepărtare din configurația derulării a eșuat, iar furnizorul platformei de baze de date a trebuit să rupă legătura de replicare. Acest lucru a lăsat configurarea eșuării într-o stare temporar indisponibilă, determinând serviciile de stocare și de funcționare care depind de această bază de date să eșueze cererile. ## Detectie Incidentul a fost detectat printr-o alertă automată pentru serviciile de înțelegere a documentelor, care a fost recunoscută la 21 august 2026 la 12:10 pm UTC. ## Response Înainte de declararea incidentului de impact al clientului, baza de date primară de scară-up a fost finalizată și sprijinul furnizorului platformei de baze de date a fost angajat pentru problema bazei de date secundare. Dupa ce configuratia de derulare s-a stricat, am explorat redirectionarea conexiunii de service dar nu am putut identifica o cale sigura, imediata pentru a face acest lucru dat fiind configuratia curenta a serviciului. Serviciul a fost restaurat prin ștergerea bazei de date secundare nesănătoase și recrearea configurației eșuării. Până la 21 august 2026 la 12:37 pm UTC, fix a fost implementat și monitorizarea a fost în curs de desfășurare. La 1:36 pm UTC, monitorizarea a confirmat serviciul a fost sănătos, iar incidentul a fost marcat rezolvat. ## Follow up 1. Solicita o analiza cauza radacina de la furnizorul platformei de baze de date pentru a determina de ce baza de date secundara nu a putut fi scalata si de ce remedierea configuratiei ecuover necesita replicarea de rupere. 2. Actualizarea limitelor de alertă şi rutare a bazei de date, astfel încât alertele să fie atribuite şi acţionate mai devreme, inclusiv un avertisment de severitate inferioară la 75% din utilizarea lor şi o alertă de severitate mai mare la 85% din utilizare.

Traducere automată din actualizarea oficială a incidentului.

1. 19 august 2026 la 16:34 UTCinvestigating

   Investigăm o problemă care ar putea afecta unii clienți care utilizează Claude Sonnet 4.6 în agenții din regiunea SUA. Echipa noastră de inginerie este activ de lucru pentru a înțelege problema și va împărtăși actualizări suplimentare ca mai multe informații devine disponibile.

2. 19 august 2026 la 16:40 UTCmonitoring

   Am redus problema. Echipa noastră de inginerie este activă dimineața și va împărtăși actualizări suplimentare ca mai multe informații devine disponibile.

3. 19 august 2026 la 16:42 UTCmonitoring

   Am redus problema. Echipa noastră de inginerie monitorizează în mod activ și va împărtăși actualizări suplimentare pe măsură ce mai multe informații devin disponibile.

4. 19 august 2026 la 16:55 UTCresolved

   Problema a fost rezolvată.

5. 31 august 2026 la 12:41 UTCpostmortem

   ## Impactul clientului Între 19 august 2026 la 1:36 pm UTC și 19 august 2026 la 3:53 pm UTC, un subset de clienți au primit erori atunci când utilizează Claude Sonnet 4.6 în agenți. Impactul a durat aproximativ 2 ore şi 17 minute. Impactul a fost asupra clienților care utilizează agenți din regiunea SUA. De asemenea, s-au observat erori pentru Claude Opus 4.6 și Claude Opus 4.5, care sunt utilizate la un volum mai mic. --- ## Root Cause Ca parte a unei migraţii planificate a infrastructurii, am mutat serviciul de platformă care direcţionează cererile agenţilor către un nou sistem de livrare a configuraţiei, regiune cu regiune. Noua sursă de configurare lipsea intrările de rutare pentru trei modele Claude Sonnet 4.6, Claude Opus 4.6, și Claude Opus 4.5. Fără aceste intrări, serviciul nu ar putea rezolva o destinație valabilă pentru cererile adresate acestor modele și le-ar respinge cu erori. Alte modele nu au fost afectate și au continuat să servească în mod normal pe tot parcursul. --- ## Detectie Problema a fost detectată prin escaladarea clienţilor la 19 august 2026 la ora 2:55 p.m. Echipa noastră de ingineri a cercetat problema modelelor specifice Claude şi a început investigaţia. Comunicarea privind statutul public a început la ora 15:08 UTC. Monitorizarea noastră de alertă se bazează pe ratele agregate de eroare. Deși aproape toate cererile adresate celor trei modele afectate au eșuat, aceste modele au reprezentat o mică parte din traficul total din regiune, astfel încât semnalul agregat nu a depășit pragurile noastre de alertă și problema nu a fost ridicată automat. Acesta este decalajul de detectare abordat în cadrul monitorizării de mai jos. --- ## Response La 3:25 pm UTC, sursa de configurare incompletă a fost identificată ca fiind cauza și a început o fixare. La ora 3:47 pm UTC, implementarea fix a fost în curs de desfășurare, iar serviciul a fost monitorizat în mod activ pe măsură ce schimbarea s-a derulat. Prin 3:59 pm UTC, jurnalele de serviciu au confirmat că problema a fost atenuată, iar la ora 16:00 UTC rata de eroare a fost confirmată la 0%. Incidentul a fost redus la 4:40 pm UTC, iar rezoluţia completă a fost declarată la 4:55 pm UTC după monitorizarea continuă şi confirmarea clienţilor că serviciul funcţiona conform aşteptărilor. --- ## Follow-Up Migrația infrastructurii a fost finalizată în toate regiunile și configurația rutei se trage acum dintr-o singură sursă, eliminând neconcordanța care a cauzat acest incident, astfel încât nu poate să reapară. Se introduc controale automate pentru a verifica în permanență fiecare model sprijinit în fiecare regiune, astfel încât un model indisponibil este detectat și alertat imediat, inclusiv în regiunile cu trafic redus.

Traducere automată din actualizarea oficială a incidentului.

1. 18 august 2026 la 17:54 UTCinvestigating

   Investigăm rapoarte privind o pană care afectează eşecurile evaluărilor de expresie legate de parametrii de realizare a sarcinilor HITL pentru Orchestratronul Argentic în rândul utilizatorilor comunităţii din Europa. Impact: Utilizatorii ar putea fi în imposibilitatea de a finaliza sarcinile HITL Următoarea actualizare: Echipele noastre lucrează pentru a înțelege cauza și domeniul de aplicare și va partaja actualizări ca disponibile.

2. 18 august 2026 la 20:31 UTCidentified

   Am identificat cauza unei întreruperi a evaluărilor de expresie a impactului legate de parametrii de realizare a sarcinilor HITL pentru orchestrarea agentică în utilizatorii comunitari din Europa. Impact: Utilizatorii vor experimenta eșecuri atunci când au expresii folosind parametrul de ieșire a sarcinii HITL. Următoarea actualizare: Echipele noastre lucrează pentru a înțelege cauza și domeniul de aplicare și va partaja actualizări ca disponibile.

3. 18 august 2026 la 21:45 UTCidentified

   Am identificat fix și rezoluția este în curs de desfășurare. Următoarea actualizare: Echipele noastre lucrează la fix și vor partaja actualizări ca disponibile.

4. 18 august 2026 la 22:53 UTCmonitoring

   Am implementat fix și sunt monitorizarea rezoluției. Următoarea actualizare: Echipele noastre monitorizează rezoluția și vor partaja actualizările disponibile.

5. 18 august 2026 la 23:25 UTCresolved

   Pana a fost rezolvată şi Orchestraţia Agentică este complet operaţională. Impact: Niciun impact continuu al utilizatorului.

Traducere automată din actualizarea oficială a incidentului.

1. 18 august 2026 la 12:08 UTCidentified

   Am identificat cauza principală a unei probleme în Studio Web unde ecranul de configurare a resurselor pentru schimbarea atributelor resurselor nu se încarcă. Suntem implementarea unui fix.

2. 18 august 2026 la 13:05 UTCidentified

   Desfăşurarea stabilităţii este în desfăşurare. Vom furniza actualizări suplimentare pe măsură ce implementarea progresează.

3. 18 august 2026 la 14:06 UTCidentified

   Fixarea a fost verificată și este introdusă în toate regiunile rămase. Monitorizăm desfăşurarea şi recuperarea. Mulţumesc pentru răbdare.

4. 18 august 2026 la 17:03 UTCidentified

   Lansarea înregistrează progrese în ceea ce privește regiunile rămase. Continuăm să monitorizăm desfăşurarea. Mulţumesc pentru răbdare.

5. 18 august 2026 la 18:12 UTCmonitoring

   Lansarea înregistrează progrese în ceea ce privește regiunile rămase. Continuăm să monitorizăm desfăşurarea. Mulţumesc pentru răbdare.

6. 18 august 2026 la 19:05 UTCresolved

   Lansarea este finalizată și problema ar trebui rezolvată.

Traducere automată din actualizarea oficială a incidentului.

1. 18 august 2026 la 05:32 UTCinvestigating

   Investigăm o problemă care afectează conturile comunitare în care entităţile nou create pot dura aproximativ o oră să apară în Studio Web. Nu se pierd date, iar entitățile existente nu sunt afectate.

2. 18 august 2026 la 06:48 UTCinvestigating

   Continuăm să investigăm problema și lucrăm la identificarea cauzei profunde și la restabilirea timpului normal de procesare.

3. 18 august 2026 la 08:44 UTCinvestigating

   Continuăm să investigăm problema care afectează un subset de chiriaşi din Europa, Statele Unite şi Japonia, unde entităţile nou create pot dura mai mult decât se aşteaptă să apară în Studio Web. Nu se pierd date, iar entitățile existente nu sunt afectate.

4. 18 august 2026 la 09:37 UTCidentified

   Am identificat cauza și lucrăm la o rezoluție a problemei care afectează un subset de chiriași din Europa, Statele Unite și Japonia. Mulţumesc pentru răbdare.

5. 18 august 2026 la 11:19 UTCmonitoring

   Problema a fost atenuată şi ne aşteptăm ca timpul de procesare să revină la normal în scurt timp. Monitorizăm îndeaproape recuperarea. Mulţumesc pentru răbdare.

6. 18 august 2026 la 11:57 UTCresolved

   Problema a fost rezolvată, iar timpul de procesare a revenit la normal. Mulţumesc pentru răbdare.

7. 27 august 2026 la 03:51 UTCpostmortem

   ## Impactul clientului Între 18 august 2026 la 5:11 am UTC și 18 august 2026 la 11:57 am UTC, noile entități create într-un subset de chiriași UiPath Cloud ar putea dura mai mult decât se așteptau să apară în Studio Web. La momentul evaluării inițiale, entitățile nou create apăreau cu o întârziere de aproximativ o oră. Clienţii din Europa, SUA şi Japonia au fost afectaţi. Crearea de entități în sine a continuat cu succes, nu s-au pierdut date și entitățile existente nu au fost afectate. ## Root cause Problema a fost cauzată de un volum neobișnuit de mare de cereri de creare de active de la un chiriaș. Aceste cereri au generat mai multe evenimente decât serviciul nostru de backend entity-indexing ar putea procesa în același ritm, creând un backlog în coada de procesare a evenimentelor. Deoarece Studio Web se bazează pe acest serviciu pentru a afișa noi entități create, noi entități au apărut doar după ce registrul a fost procesat. ## Detectie Problema a fost identificată de echipa noastră de inginerie prin procesarea de către entitate de alertă latență, și un incident a fost declarat la 5:11 am UTC la 18 august 2026. Până la 5:23 am UTC, analiza a confirmat că ultima entitate procesată a fost cu aproximativ o oră în urmă. ## Response La 5:32 am UTC, am postat o actualizare inițială a clienților notarea vizibilității întârziate pentru entitățile nou create în Studio Web. Până la ora 6:07 am UTC, investigaţia a identificat un trafic neobişnuit de ridicat de creare de active de la un chiriaş, iar la ora 7:03 am UTC, am ajustat resursele bazei de date pentru serviciul afectat pentru a ajuta la prelucrarea recuperării. La 7:59 am UTC, sursa volumului mare cerere a încetat să mai trimită cereri, iar coada a început să se scurgă. La 9:59 am UTC, am început un proces de sincronizare a datelor pentru chiriașul afectat, și la 10:31 am UTC, am eliminat evenimentele problematice din coadă astfel încât procesarea normală ar putea prinde mai repede. Adâncimea cozii a scăzut de la 95.000 de articole la 8:34 am UTC la 1.000 de articole la 11:44 am UTC. Incidentul a fost redus la 11:19 am UTC după prelucrarea recuperat în mod substanțial, și a rezolvat la 11:57 am UTC după timpul de procesare a revenit la normal. ## Follow up Sincronizarea datelor redeclanşate pentru chiriaşul afectat şi monitorizarea ingestiei până când datele chiriaşului sunt confirmate consistente. Îmbunătățește gestionarea entității în platforma de indexare, astfel încât backlog-ul să nu se adune în acest ritm.

Traducere automată din actualizarea oficială a incidentului.

1. 14 august 2026 la 21:24 UTCidentified

   We have identified the cause of the degraded performance impacting Orchestrator in US region and are working on mitigation. Impact: Users may experience delayed loads and views on Orchestrator Robot logs. Additional updates will be provided as we move toward resolution.

2. 14 august 2026 la 23:22 UTCresolved

   The issue has been resolved and Orchestrator Robot logs performance has returned to expected levels after degraded performance impacted Robot logs to load in US region. Impact: No ongoing user impact.

3. 28 august 2026 la 16:55 UTCpostmortem

   ## Customer impact Between August 14, 2026 at 8:54 pm UTC and August 15, 2026 at 2:09 AM UTC, a subset of customers in the US region experienced significant slowness in the Orchestrator Jobs and Logs pages, and robot logs appeared later than expected in the logs view. Performance had substantially recovered by 11:22 PM UTC on August 14, with full recovery confirmed with affected customers at 2:09 AM UTC on August 15. Automation execution was not affected, jobs continued to be scheduled and to run normally throughout. No log data was lost. Logs continued to be recorded and became visible once the system caught up. Requests did not fail, so no errors were surfaced, pages were slow to load and recent activity appeared missing or delayed. No other region was impacted. ## Root cause Orchestrator stores and retrieves robot logs using a dedicated search and storage system. Routine maintenance on that system causes data to be redistributed internally across the cluster. Our analysis indicates that a redistribution larger than anticipated consumed capacity that would otherwise have served customer requests, slowing both the retrieval of existing logs and the processing of new ones. This accounts for the majority, but not the entirety, of the slowdown observed, and analysis of the remaining contributing factor is continuing. Capacity returned to normal without intervention, at which point log visibility and page performance recovered. ## Detection The issue was surfaced through customer reports of slow Jobs and Logs pages in the US region. ## Response We posted a status update confirming that we were investigating degraded Orchestrator performance in the US region. Our engineering team scoped the impact to the US region and narrowed the slowdown to the log storage and search layer. The degradation stemmed from capacity contention that eased as the redistribution completed, and responders monitored the system through recovery. Page performance and log visibility returned to expected levels over the course of the evening, and recovery was subsequently confirmed with affected customers at 2:09 AM UTC on August 15. ## Follow up 1. We are adding monitoring and alerting on the response times customers experience and on the delay between a robot log being generated and becoming visible, so that degradation of this kind is detected proactively. 2. We are documenting an operational procedure that gives our on-call engineers defined steps to reduce customer impact during this class of degradation. 3. We are changing how routine maintenance on the log storage system is scheduled and paced in the US region so that it does not affect customer-facing performance. 4. We are increasing spare capacity in the log storage system so that internal data movement has room to complete without competing with customer requests.

1. 18 august 2026 la 10:58 UTCresolved

   O furtună de cereri privind o caracteristică de model rar utilizată în IXP Communications Mining a cauzat o buclă de retrimitere pentru a bloca cererile sincrone în API-ul IXP mai larg. Acest lucru a cauzat cereri de eșec cu 500 de muncitori au fost ocupați cu cereri de lungă durată. Creșterea automată a atins rapid capacitatea maximă și rezoluția sa a fost făcută doar prin aplicarea unui fix de cod care a introdus termene stricte la cererea API contribuitoare. Furtuna a început în jurul orei 15:10 UTC și a detectat un UTC 15:15 prin alarme automate. Rezoluția a fost confirmată în jurul orei 18:15 UTC. Incidentul a fost inițial atribuit în mod greșit numai clientului care a făcut furtuna cererilor, dar mai târziu s-a descoperit că a avut un impact asupra unei game mai largi de utilizatori. Impactul total limitat la o mână de utilizatori din SUA.

2. 18 august 2026 la 21:25 UTCpostmortem

   ## Impactul clientului La 12 august 2026, între aproximativ 15:10 și 18:15 UTC, utilizatorii de comunicații miniere (IXP) din regiunea Statelor Unite au suferit eșecuri intermitente ale cererii. Incidentul s-a limitat la una dintre unităţile de desfăşurare ale regiunii, unde utilizatorii de pe el au văzut eşecuri în explozii de cinci până la zece minute, până la 5 [7% din cererile lor eşuând cu erori de 5xx la maxim. Între explozii serviciul a funcționat în mod normal, rejudecate cereri în general a reușit, și nu au fost pierdute date. ## Root Cause O furtună de cereri pentru o caracteristică API rar utilizată care calculează predicții la cerere-învățare mașină coincide cu reconversia repetată a modelului solicitat. Fiecare recalificare invalidată predicții cache, transformarea fiecărei cereri într-un calcul de mai multe minute. API nu a acordat nici o limită de timp cu privire la perioada în care o cerere ar putea aștepta acest calcul, astfel încât aceste solicitări de lungă durată au ocupat progresiv toate capacitățile de procesare a cererilor, ceea ce a dus la eșecul cererilor. Scalarea automată a atins rapid capacitatea maximă și nu a putut compensa. ## Detectie Monitorizarea automată a detectat defecțiunile la 15:15 UTC, la aproximativ cinci minute după ce a început impactul, și a chemat inginerul de gardă. Incidentul a fost atribuit iniţial doar clientului care a generat furtuna cererii, dar rapoartele clienţilor şi investigaţiile ulterioare au arătat că un set mai larg de utilizatori au fost afectaţi în timpul exploziilor de eşec. ## Response Inginerul de gardă a urmărit eşecurile aşteptării nestingherite în calea predicţiei la cerere. Capacitatea de serviciu a fost restabilită în mod repetat prin înlocuirea automată a instanţelor în timp ce s-a dezvoltat o fixare de cod. Fixarea este un termen strict pentru solicitarea care contribuie, astfel încât nu reușește rapid fără a afecta alte cereri, și a fost desfășurat în regiunea afectată la aproximativ 18:00 UTC, iar rezoluția a fost confirmată la 18:15 UTC. ## Follow-Up 1. Fixarea strictă de timeout și încărcare a fost făcută permanentă și eliberată tuturor regiunilor (completată 13 august 2026). 2. Evaluaţi limitele per client la calculul predicţiei la cerere, astfel încât utilizarea unui singur client să nu degradeze API-ul comun.

Traducere automată din actualizarea oficială a incidentului.

1. 10 august 2026 la 14:11 UTCinvestigating

   Investigăm performanţe degradate care afectează serviciile Front-End în înţelegerea documentelor în regiunea GXP East SUA. Impact: Utilizatorii pot observa timeout-uri atunci când accesează UI în GXP SUA. Următoarea actualizare: Actualizări suplimentare vor fi furnizate pe măsură ce devin disponibile mai multe informații.

2. 10 august 2026 la 14:25 UTCresolved

   Problema a fost rezolvată și performanța Serviciului Front-End în Înțelegerea Documentului a revenit la nivelurile preconizate după ce performanța degradată a afectat IU în regiunea GXP East SUA. Impact: Niciun impact continuu al utilizatorului.

3. 19 august 2026 la 06:14 UTCpostmortem

   ## Impactul clientului Intre 10 august 2026 la 13:21 UTC si 10 august 2026 la 14:03 UTC, un subset de clienti au experimentat performante degradate si temporizari atunci cand au accesat interfata de utilizator Document Înţelegerea, care ofera experienta de proiectare-timp, in regiunea intarziata din SUA. Automatizările de procesare a documentelor nu au fost afectate. ## Root cause În timpul unei desfăşurări manuale dintr-o construcţie preexistentă a serviciului din spatele interfeţei de utilizator "Document Înţelegere a documentelor" către regiunea americană întârziată, procesul nostru de desfăşurare a realocat identificatorul versiunii pentru serviciul implementat. Interfața de înțelegere a documentelor impune ca resursele sale de sprijin să fie disponibile sub același identificator de versiune ca și serviciul implementat. Deoarece procesul de implementare a schimbat acest identificator, interfața nu a putut localiza resursele necesare, ceea ce a făcut-o să devină inaccesibilă sau în pauză. ## Detectie Am devenit conștienți de momentele în care a fost finalizată implementarea, prin verificarea manuală ca parte a listei de implementare manuală. A urmat o alertă automată, declanşată la 13:28 UTC la 10 august 2026. ## Response După identificarea motivului pentru eșecul implementării manuale, echipa noastră de inginerie a început să implementeze o actualizare corectată cu resursele necesare disponibile. În acelaşi timp, echipa de operaţiuni a fost angajată pentru a efectua o răsturnare manuală a desfăşurarii. Reversul a fost finalizat la 14:03 UTC, restabilind accesul la experiența de proiectare-timp. La 14:11 UTC, am publicat o actualizare a stării publice care indică performanţele degradate şi eventualele termene în interfaţa de utilizator Document Înţelegere pentru regiunea întârziată SUA. Până la 14:15 UTC, actualizarea corectată a fost finalizată și interfața a fost confirmată ca fiind implementată cu o nouă versiune corectă și de lucru. La 14:25 UTC, incidentul a fost marcat rezolvat și pagina de stare publică a fost actualizată pentru a confirma că performanța interfeței de înțelegere a documentelor a revenit la nivelurile preconizate. ## Follow up 1. Suntem reducerea timpului necesar pentru a restabili o versiune anterioară a serviciului, astfel încât recuperarea de la o implementare eșuată este mai rapidă. 2. Îmbunătățim procesul de implementare manuală pentru a preveni o situație viitoare, prin validarea existenței resurselor necesare ca condiție prealabilă.

Traducere automată din actualizarea oficială a incidentului.

1. 8 august 2026 la 11:54 UTCidentified

   We have identified the cause of the outage impacting Uipath Apps is facing outage in Delayed US region and are working on a fix. Impact: Users may continue to be unable to access Uipath Apps and solutions dependent on Uipath Apps. Team is working on service restoration.

2. 8 august 2026 la 13:01 UTCidentified

   Team is working on service restoration. We will update the status once mitigation is completed.

3. 8 august 2026 la 14:14 UTCidentified

   Team has identified an issue with an underlying resource and is actively working to restore service.

4. 8 august 2026 la 15:30 UTCidentified

   Team has made progress to fix underlying resource issue and is actively working to restore service.

5. 8 august 2026 la 15:32 UTCmonitoring

   Mitigation has been applied and performance is improving for the issue. We are monitoring closely to ensure stability.

6. 8 august 2026 la 16:01 UTCresolved

   The mitigation has remained stable, and performance has returned to expected levels. We have confirmed service restoration for UiPath Apps in the Delayed US region and are marking this incident as resolved.

7. 12 august 2026 la 10:14 UTCpostmortem

   ## Customer impact Between 11:20 am UTC and 2:54 pm UTC on August 8, 2026, a subset of customers in the Delayed US region experienced failures accessing UiPath Apps and solutions that depend on UiPath Apps. Customers may have seen UiPath Apps unavailable or intermittent request failures. The impact lasted approximately 3 hours and 34 minutes. ## Root cause The incident was caused by database connection saturation following scheduled maintenance performed by our database provider. As application services scaled up, they created additional database connections, which caused new connection attempts to fail and resulted in connection reset errors in UiPath Apps. ## Detection Automated alerts detected the issue at 11:24 am UTC on August 8, 2026. Application telemetry showed failures beginning at approximately 11:20 am UTC. ## Response At 11:00 am UTC, scheduled maintenance began automatically. At 11:20 am UTC, requests began failing. At 11:24 am UTC, automated alerts were triggered, and the team began investigating. At 12:24 pm UTC, database capacity was scaled up as a mitigation. At 1:13 pm UTC, application services were restarted to reduce saturated connection usage and refresh database connections. Connection levels remained elevated, and the database automatically scaled at 1:22 pm UTC and at 2:36 pm UTC. Following these mitigation efforts, request failures stopped at 2:54 pm UTC. At 3:33 pm UTC, the mitigation was confirmed to be stable, and performance was improving. Full recovery was confirmed at 4:01 pm UTC after performance returned to expected levels. ## Follow up 1. Obtain and review the database provider's root cause analysis explaining what caused the connection issue following their maintenance activity. 2. Implement an application-side limit on database connection creation to prevent connection saturation. 3. We are reviewing the automatic scaling behavior that amplified connection volume during the incident and address any contributing factors.

1. 6 august 2026 la 21:14 UTCresolved

   Between 06-08-2026 10:00 UTC and 06-08-2026 13:00 UTC, some organizations in the US region were unable to complete document ingestion. A small number of search requests in the same region were also slow or timed out. The issue was caused by a capacity constraint affecting ingestion processing in US. Normal performance was restored at 13:00 UTC. We have monitored the affected environments since recovery and confirm the issue is fully mitigated. Ingestion requests that failed during this window were not retried automatically and will need to be re-submitted. No action is required for search.

2. 13 august 2026 la 15:12 UTCpostmortem

   ## Customer impact Between August 6, 2026 at 10:00 am UTC and 1:00 pm UTC, some organizations in the US region were unable to complete document ingestion in **UiPath Context Grounding**. A small number of search requests in the same region were also slow or timed out. **Action required:** please re-submit the affected ingestion requests. Ingestion retries a failing request automatically for a limited number of attempts. Once those attempts are exhausted the request is marked failed and is not retried again, so affected documents will not appear in your index until the request is submitted again. Failed requests are listed in the ingestion history for each index. No action is required for search. Those requests were affected only while the issue was ongoing, and subsequent searches completed normally. --- ## Root cause A sudden increase in concurrent document ingestion triggered a high number of simultaneous document validation steps, which created a capacity bottleneck on the underlying infrastructure resource beyond its scaling capacity. Once that resource was saturated, ingestion operations began exceeding their time limits and failing. Automatic retries of the failed operations added further load, which sustained the condition. Search requests served by the same resource were delayed behind the same contention. --- ## Detection Automated alerts were flagged as the condition developed, and an automated infrastructure resource capacity alert triggered at 10:37 am UTC brought it to the team's attention. --- ## Response - **10:03 am UTC** — Automated low severity alerts started coming in. - **10:37 am UTC** — Automated alert for resource capacity issue paged the team. - **12:23 pm UTC** — As a mitigation step the impacted resource's capacity was increased. - **12:57 pm UTC** — Ingestion and search operations stopped failing and response times returned to normal. --- ## Follow-up - **The fix is deployed.** The validation step has been reimplemented to enforce the same limits at a small fraction of the previous cost, so this level of concurrent ingestion now sits well within available capacity. It was released to the affected US region on August 7, ahead of schedule, and reaches all remaining regions by early September. - **We are improving how quickly we detect issues like this.** We are adding monitoring that tracks whether document ingestion is completing successfully for customers, so problems are identified and acted on directly rather than inferred from underlying system alerts. This will be in place across all regions by the end of August.