Uipath driftsforstyrrelser

1. 28. oktober 2026 kl. 10.04 UTCinvestigating

   Vi undersøger en øget forsinkelse og forsinkelser i jobudførelsen inden for orkestertjenesten i Europa-regionen. Vores team arbejder aktivt på at identificere årsagen og vil give yderligere opdateringer, efterhånden som flere oplysninger bliver tilgængelige.

2. 28. oktober 2026 kl. 10.28 UTCmonitoring

   Spørgsmålet er blevet mildnet, og vi overvåger tjenesten for at sikre stabilitet.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 27. oktober 2026 kl. 16.39 UTCresolved

   Den 27. oktober 2026, mellem 14: 35 og 16: 08 UTC, dokument forståelse i Europa-regionen oplevede en delvis afbrydelse påvirker generative udvinding, generative klassificering og autvalifikation. Den grundlæggende årsag var en forbindelse problem med en tredjepart lagerudbyder. Forbindelsen blev genoprettet, og vi har bekræftet, at udvinding og klassificering har fungeret normalt siden 16: 08 UTC.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 26. oktober 2026 kl. 14.04 UTCidentified

   Vi er i øjeblikket ved at undersøge et problem, der påvirker tilgængeligheden af indsigt og automatisering ops-tjenester. Vores team er aktivt at vurdere situationen for at identificere den underliggende årsag og bestemme de nødvendige skridt til at genoprette normale operationer. Yderligere opdateringer vil blive leveret, efterhånden som flere oplysninger bliver tilgængelige.

2. 26. oktober 2026 kl. 15.35 UTCidentified

   Problemet med Automation Ops er blevet løst. Vi venter i øjeblikket på, at spørgsmålet om Insights service bliver løst. Yderligere opdateringer vil blive delt, efterhånden som de bliver tilgængelige.

3. 26. oktober 2026 kl. 17.09 UTCidentified

   Insights service i Singapore, Japan, Schweiz, Canada, Indien, Storbritannien, Europa, USA, UAE, Sydkorea & Australien regionen er fast, og vi anvender fix på andre regioner

4. 26. oktober 2026 kl. 18.27 UTCresolved

   Spørgsmålet er løst, og alle tjenester fungerer nu normalt.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 27. oktober 2026 kl. 10.13 UTCresolved

   Den 26. oktober 2026, mellem 10: 20 og 17: 30 UTC, Automation Cloud Robots (VM) oplevede en delvis afbrydelse påvirker maskinoperationer. I dette vindue, handlinger såsom start, stop, eller levering VM-maskiner ikke har afsluttet, og job planlagt på disse maskiner kan være blevet forsinket eller forfalsket. Årsagen var en forkert konfiguration af tilladelser på en delmængde af de underliggende infrastrukturressourcer. Vores team identificerede problemet, korrigerede konfigurationen og bekræftede, at maskinoperationer har fungeret normalt siden 17: 30 UTC. Vi gennemgår, hvordan fejlkonfigurationen blev indført, og tilføjer kontroller for at forhindre en gentagelse. Der kræves ingen handling på din side. Hvis du stadig ser mislykkede eller fast job fra dette vindue, bedes du prøve dem igen, og kontakt support, hvis problemet fortsætter.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 23. oktober 2026 kl. 21.35 UTCresolved

   Mellem 20: 42 og 21: 19 UTC den 23. oktober oplevede nogle Orchestrator kunder i Europa langsomme svar og periodiske fejl. Dette omfattede robot opkald for at få aktiver, proces kø poster og rapportere jobstatus. Nogle job uden opsyn kan have slået fejl i denne periode. Årsagen var en pludselig stigning i belastningen, der nåede databasens ressourcegrænser. Vi har tilføjet databasekapacitet, og performance har været normal siden 21: 19 UTC. Kunder hvis job mislykkedes i dette vindue kan være nødt til at genstarte dem.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 22. oktober 2026 kl. 12.59 UTCinvestigating

   Vi har identificeret et problem, der påvirker IXP for kunder i Australien regionen. Siden 10: 24 UTC, anmoder om, at bruge Gemini 2.5 Flash model er svigtende i regionen. Andre modeller påvirkes ikke. Kundedata behandles fortsat kun i Australien. Vi arbejder med Google for at gendanne service

2. 22. oktober 2026 kl. 14.19 UTCmonitoring

   Et fix er blevet indsat og tjenesten er ved at komme sig. Vi overvåger systemet for at sikre fuld genopretning. Yderligere opdateringer vil blive delt snart

3. 22. oktober 2026 kl. 14.33 UTCinvestigating

   Efter den første bedring er tjenesten blevet forringet igen. Vi undersøger og arbejder hen imod en beslutning. Vi vil levere yderligere opdateringer, når de bliver tilgængelige.

4. 22. oktober 2026 kl. 15.42 UTCinvestigating

   Vi har kontaktet Google Support, og de er begyndt at undersøge på deres ende. Vi bliver ved med at overvåge og dele opdateringer.

5. 22. oktober 2026 kl. 17.56 UTCmonitoring

   Vi observerer forbedringer på Gemini 2.5 Flash trafik. Vi overvåger en mulig rettelse fra Google.

6. 22. oktober 2026 kl. 21.02 UTCresolved

   Emnet er løst fra Google.

7. 26. oktober 2026 kl. 03.20 UTCpostmortem

   Kundeeffekt Mellem 22 oktober 2026 på 10: 24 am UTC og 22 oktober 2026 på 6: 04 pm UTC, dokument behandling anmodninger, der brugte Gemini 2.5 Flash i Australien regionen mislykkedes med kapacitetsfejl. Virkningen varede omkring 7 timer og 40 minutter. En undergruppe af kunder, der anvendte dokumentekstraktionsarbejdsgange i regionen, blev påvirket. Under et midlertidigt in-region fallback forsøg, nogle udvinding anmodninger inddrives kort, men ord- niveau tildeling og genereret sidetekst blev nedbrudt indtil fallback også begyndte at svigte. # Root cause Den grundlæggende årsag var en leverandør-side regionale netværk afbrydelse under samtidig vedligeholdelse. Dette forårsagede alvorlig båndbredde væltning i udbyderens model- servering miljø, som forhindrede backend-systemer i at indlæse de modeldata, der er nødvendige for at tjene Gemini 2.5 Flash og Gemini 3.5 Flash anmodninger pålideligt i den berørte region. # Detection Problemet blev opdaget ved automatiseret alarmering, der identificerede rate- begrænsende fejl på Gemini 2.5 Flash i Australien-regionen. Vores ingeniørhold bekræftede via telemetri, at de berørte anmodninger fejlede konsekvent og begyndte at koordinere et svar. # Response Ved 1: 40 UTC, vi dirigerede påvirket Gemini 2,5 Flash trafik til Gemini 3,5 Flash inden for samme region for at bevare data residency. Første telemetri viste ingen kapacitetsfejl efter denne ændring, men ved 2: 10 UTC, Gemini 3.5 Flash var også returnere kapacitet fejl, så faldet var ikke længere levedygtigt. Kl. 02: 05 UTC, vi justerede relaterede dokument behandling stier så tildeling og side-tekst generering ville bruge den samme in-region fallback; denne justering afsluttet på ca. 02: 09 UTC. Efter fallback også mislykkedes, vi vendt routing ændring, og ved 4: 28 UTC trafik var tilbage på den forventede Gemini 2,5 Flash sti. Kl. 5: 38 UTC, telemetri viste forbedre Gemini 2,5 Flash succesrater. Fra kl. 18.04 blev der ikke observeret yderligere kapacitetsfejl, og efterfølgende anmodninger lykkedes. # Follow up 1. Udfyld den reserverede modelkapacitetsvurdering for den berørte region ved hjælp af de observerede trafikmønstre 2. Evaluere gentry og backoff adfærd i dokumentbehandling klienter for at reducere gentry forstærkning under udbyderside kapacitetssvigt.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 15. oktober 2026 kl. 12.27 UTCinvestigating

   Siden ca. 11: 17 UTC har kunder i flere regioner oplevet problemer med UiPath Agenter og Solutions Management. Nye job kan forblive i afventende status, og løbende agenter kan opleve forsinkelser ved behandling eskaleringer eller venter på værktøjsresultater. Vi undersøger sagen og arbejder hen imod en beslutning.

2. 15. oktober 2026 kl. 13.04 UTCmonitoring

   Spørgsmålet er blevet afhjulpet. Vi overvåger de berørte tjenester på tværs af regioner for at sikre stabilitet og bekræfte, at jobstart og løsning implementeringer fungerer normalt.

3. 15. oktober 2026 kl. 13.22 UTCresolved

   Denne hændelse er blevet løst. Mellem 11: 15 og 12: 45 UTC den 15. oktober, en intern konfiguration problem forhindret nogle begivenheder fra at blive leveret mellem UiPath tjenester på tværs af flere regioner. Problemet blev løst ved at trække ændringen tilbage, og nye aktiviteter behandles normalt. Noget arbejde, der er påbegyndt eller i gang under dette vindue, kan kræve opmærksomhed: - Agents: Agents venter på Action Center opgaver eller automatisering værktøj resultater kan forblive fast. Jobs startet fra Orkestrator kan også forekomme fast eller tid ud. - Maestro: Processer, der venter på brugeropgaver, kan ikke være genoptaget efter opgavens afslutning. - Apps: Kø element status kan være forældet, og handlinger udløst af kø element afslutning kan ikke have kørt. - Autopilot for alle: Samtaler, der venter på automatisering resultater kan forblive gået i stå. - Document Forståelse og Context Grounding: Automationer og agenter venter på udvinding, validering eller indeksering kan forblive suspenderet. - Integrationstjeneste: Forbindelsesbegivenheder kan ikke have udløst de forventede processer eller meddelelser. - Løsninger og Studio Web: Løsning installeringer, uninstalls, publications, implementeringer, og valideringer initieret under dette vindue kan have svigtet eller timet ud. Genoplivning af disse operationer kan løse problemet. Vi undskylder forstyrrelsen og takker dig for din tålmodighed.

4. 21. oktober 2026 kl. 06.47 UTCpostmortem

   * * Kundepåvirkning * * Den 15. oktober 2026, fra 11: 15 til 12: 50 UTC (ca. 1 time og 35 minutter), nogle begivenheder udvekslet mellem UiPath cloud-tjenester ikke blev leveret. Kunder i alle kommercielle cloud-regioner blev påvirket. Under dette vindue: - Nye agenter kan blive i afventende status. running agenter venter på et værktøj resultat, en menneskelig eskalering, dokument udvinding, eller kontekst jordforbindelse kan ikke genoptages. - Konversationsagenter og Autopilot for alle samtaler, der startede en automation måske ikke har fået sit resultat. - Maestro proces tilfælde venter på en brugeropgave måske ikke har bevæget sig fremad efter opgaven blev afsluttet, og processer udløst af Integration Service stik begivenheder måske ikke er startet. - Apps, der viser eller reagerer på kø element status kunne vise forældede oplysninger. - Løsning installationer, uninstalls, publishs, og installationer kunne mislykkes eller time ud. - Nogle bruger, gruppe og mappe ændringer foretaget i vinduet måske ikke har formeret sig til alle tjenester. Arbejdet startede efter 12: 50 UTC blev ikke påvirket. Robot job udførelse, køer, og udløsere håndteres inde Orchestrator holdt arbejde normalt. * * Rodårsag * * Vi flyttede leveringen af intern service konfiguration til en ny mekanisme, en ændring beregnet til at have ingen indvirkning på kunderne. Da denne ændring blev anvendt på begivenhedsservice, manglede den konfiguration, den producerede, en krævet værdi. Uden det, service behandlet flere produkter integreringer som slukket og lydløst stoppet levere deres begivenheder. Da ændringen nåede alle produktionsregioner på samme tid, blev alle regioner berørt. * * Detection * * Spørgsmålet blev opdaget kl. 11: 51 UTC, ca. 35 minutter efter virkningen begyndte, da overvågningen af agentjob stadig var i afventning af status. Rapporter om løsning implementeringer timing ud fulgt, og en hændelse blev erklæret på 12: 12 UTC. * * Svar * * Efter den første detektion kl. 11: 51 UTC blev konfigurationsændringen identificeret og en rollback blev startet kl. 12: 00 UTC. En første rollback på 12: 14 UTC ikke helt genoprette levering. Holdet stoppede derefter den nye konfiguration leveringsproces og restaurerede den tidligere konfiguration. Event levering begyndte at inddrive på 12: 40 UTC, og fuld inddrivelse på tværs af alle regioner blev bekræftet på 12: 50 UTC. Hvor det er muligt, genspillede vi savnede begivenheder, så det berørte arbejde kunne fortsætte. * * Opfølgning * * 1. Den nye konfiguration leveringsproces er blevet sat på pause for den berørte tjeneste og vil holde pause indtil konfigurationen er genereret korrekt. 2. Validér konfiguration produceret af den nye leveringsmekanisme for de krævede værdier, før den anvendes på ethvert miljø. 3. Rul ændringer til konfiguration levering gradvist på tværs af regioner i stedet for til alle regioner på én gang. 4. Forbedre vores overvågning til at opdage inden for få minutter, når begivenheder ophører med at blive leveret til et produkt integration, der normalt modtager dem. 5. Forbedre vores evne til at inddrive og genlevere begivenheder, der er savnet under en afbrydelse.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 15. oktober 2026 kl. 12.03 UTCresolved

   Nogle kunder i den amerikanske region oplevede forsinkelser i robotlog indtagelse, med øget aktivitet observeret mellem ca. 11: 20 og 11: 45 UTC. Problemet er løst, og log indtagelse er vendt tilbage til normal. Tak for din tålmodighed.

2. 22. oktober 2026 kl. 10.13 UTCpostmortem

   Kundeeffekt Mellem ca. 15 oktober 2026 kl 11: 20 UTC og ca. 15 oktober 2026 kl 11: 45 UTC oplevede nogle kunder i den amerikanske østregion forsinkelser i robotlog indtagelse i UiPath Orchestrator. Robot logfiler var ikke opdateret i den berørte periode. Anslaget varede omkring 20 minutter. # Root cause I løbet af hændelsen blev 2 af de 13 servicetilfælde, der håndterer robot log indtagelse observeret ikke at forbinde til hændelsen indtagelse service. Kun anmodninger til begivenheden indtagelse service mislykkedes, og kun på disse to tilfælde. Dette forårsagede nogle robot log indtagelse anmodninger om ikke at fuldføre med succes, hvilket resulterer i forsinkede logdata for berørte kunder. Den grundlæggende årsag til, at kun disse to tilfælde mistede forbindelse til hændelsen indtagelse service ikke blev bestemt under hændelsen. Holdet forpligtet til en post-hændelse gennemgang af logfiler fra de berørte tilfælde for at identificere den underliggende årsag. Vi mener, det er et urapporteret infrastrukturproblem fra vores cloud-udbyder. # Detection Spørgsmålet blev opdaget via en automatiseret alarm på omkring 11: 33 UTC den 15. oktober 2026, og bekræftet gennem telemetri viser undtagelser fra de to berørte servicetilfælde. # Response Efter afsløringen bekræftede telemetri, at kun to tjenesteinstanser frembragte undtagelser. Responders fjernet disse to usunde tilfælde fra service, og udskiftning tilfælde startede automatisk. Inden for ca. 20 minutter efter den første indberetning - ca. 11: 53 UTC - telemetri indikerede nyttiggørelse og syntetiske kontrol blev bestået. En bredere genstart af alle servicetilfælde blev overvejet, men ikke udført, da holdet besluttede, at det ikke skulle fortsætte uden først at forstå årsagen. # Follow up 1. En post-hændelse gennemgang af logfiler fra de berørte servicetilfælde afslørede problemet var infrastruktur relateret, og vi følger op med ud cloud infrastruktur udbyder for flere detaljer. 2. En opdatering vil blive offentliggjort, hvis undersøgelsen giver yderligere resultater.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 14. oktober 2026 kl. 07.26 UTCmonitoring

   Start med 6: 50 UTC har vi oplevet en global afbrydelse, der har påvirket indlæsning af apps og kodede apps alle regioner undtagen Indien og Storbritannien. Udbrud er blevet løst, og tjenesterne er fuldt operationelle. Påvirkning: Ingen igangværende brugerpåvirkning.

2. 14. oktober 2026 kl. 07.43 UTCresolved

   Start med 6: 50 UTC har vi oplevet en global afbrydelse, der har påvirket indlæsning af apps og kodede apps alle regioner undtagen Indien og Storbritannien. Udbrud er blevet løst, og tjenesterne er fuldt operationelle. Påvirkning: Ingen igangværende brugerpåvirkning.

3. 23. oktober 2026 kl. 12.08 UTCpostmortem

   Kundeeffekt Mellem 06: 38 UTC og 07: 21 UTC den 14. oktober 2026, en del af anmodninger til UiPath Apps, Kodede Apps, og løsninger, der afhænger af dem mislykkedes i elleve regioner: Europa, USA, Fællesskabet, Japan, Singapore, Australien, Canada, Sydkorea, Schweiz, UAE, og den forsinkede amerikanske miljø. Regionerne Indien og Det Forenede Kongerige blev ikke berørt. Omkring 2 procent af anmodninger mislykkedes samlet, mellem 0,6 og 5 procent afhængigt af regionen. Berørte brugere så programmer undlader at indlæse, anmodninger returserver fejl, eller langsomme svar. I regioner, hvor servicebælgene skulle genstartes, var Apps uopnåelig i op til otte minutter. Responstiderne var normale i alle regioner kl. 07: 40 UTC. De fleste brugere af allerede kørende offentliggjorte apps bemærket lidt eller ingenting. App definitioner er cached i browseren i op til 24 timer, app data kommer fra Data Service og Orchestrator snarere end denne database, og tjenesten holdt ved hjælp af databasen forbindelser, det allerede holdt. De anmodninger, der mislykkedes, var dem, der havde brug for en ny databaseforbindelse: åbning af designeren eller applisten, indlæsning af en app, der endnu ikke er cachet, downloading af dokumenter og billeder gemt i Apps, og gemme eller publicere. # Root cause På 06: 38 UTC, mens databaseadgang blev oprettet til en ny regional implementering, kodeordet for databasen bruger, at Apps service bruger blev ændret. Denne bruger er delt af produktionsdatabaseklynger i alle berørte regioner, så ændringen anvendes på dem alle på én gang. De løbende tjenester stadig holdt den tidligere adgangskode og kunne ikke længere åbne nye databaseforbindelser. Regionerne i Indien og Det Forenede Kongerige anvender ikke denne kreditværdighed og blev ikke påvirket. Ændringen skulle skabe en separat databasebruger for den nye region. I stedet blev kodeordet for den eksisterende bruger, som alle regioner deler, ændret. Vores ændringsproces for database legitimationsoplysninger ikke klart adskiller skabe en ny kredit fra at ændre en eksisterende, og det ikke kræver en kontrol af, hvor mange klynger og regioner en kreditmæssig ændring ville påvirke. Kombineret med, at en enkelt databasebruger deles på tværs af regioner, muliggjorde dette en ændring, der skulle gøre det muligt for en region at forårsage en multiregional afbrydelse. # Detection Vores interne overvågning rejste den første alarm kl. 06: 41 UTC, tre minutter efter de første fejl, og indberetninger for hver berørt region efterfulgt af 06: 46 UTC. Kl. 06: 50 UTC bekræftede maskinmesteren, at alle produktionsklynger blev afvist af sin database og startede hændelsesprocessen. # Response På 07: 05 UTC den tidligere adgangskode blev restaureret og autentificering fejl stoppet overalt. De fleste regioner blev automatisk tilsluttet igen. I de regioner, der ikke gjorde det, blev servicebælgene genindsat eller omindsat: Forsinket US kl. 07: 21 UTC og Schweiz kl. 07: 30 UTC. Forespørgsler fejl stoppet på 07: 21 UTC, responstider var tilbage til baseline ved 07: 40 UTC, og vi fortsatte overvågning indtil hændelsen blev løst på 07: 43 UTC. # Follow up For at forhindre dette i at ske igen, er vi: - Indførelse af en defineret procedure for oprettelse og roterende database legitimationsoplysninger, med en præ-ændring gennemgang, at stater, som klynger og regioner deler den kreditværdige, og en iscenesat udrulning, der verificeres i en region, før det anvendes mere bredt. - Flytter til at adskille, mindst-privilegium database brugere for hver region, så en ændring i en region ikke kan påvirke en anden. - Automatisk erklære en hændelse og søge i databasen ejere, når den samme database fejl er opdaget i flere regioner på én gang, i stedet for at stole på manuel eskalering fra individuelle regionale indberetninger. - Aktivering af tjenester til at hente opdaterede database legitimationsoplysninger uden en genstart, og til at genforbinde hurtigere efter en autentificering fiasko.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 13. oktober 2026 kl. 14.03 UTCinvestigating

   Vi er i øjeblikket ved at undersøge en afbrydelse påvirker UiPath Cloud tjenester på tværs af flere regioner. Brugerne er ude af stand til at få adgang til tjenester, der er hostet i de berørte regioner. Næste opdatering: Yderligere oplysninger vil blive delt som det bliver tilgængeligt.

2. 13. oktober 2026 kl. 14.37 UTCinvestigating

   Vi fortsætter med at undersøge dette spørgsmål.

3. 13. oktober 2026 kl. 14.42 UTCinvestigating

   Et fix er blevet gennemført, og vi overvåger resultaterne. Spørgsmålet var begrænset til dokument forståelse, Computer Vision, semantisk proxy, Autopilot Studi, IXP. Vi vil dele en anden opdatering, når tjenesterne fuldt ud er kommet sig.

4. 13. oktober 2026 kl. 15.10 UTCinvestigating

   Et fix er blevet gennemført, og vi overvåger resultaterne.

5. 13. oktober 2026 kl. 15.19 UTCresolved

   Denne hændelse er blevet løst efter fornyelse af udløbet SSL certifikat, der berørte flere ML- afhængige tjenester, herunder IXP, Document Forståelse, Computer Vision, Semantic Proxy og Autopilot for udviklere. Service recovery har udviklet sig på tværs af de berørte regioner, og automatiserede indberetninger er blevet konfigureret til at hjælpe med at opdage certifikat udløb på forhånd og forhindre lignende forstyrrelser i fremtiden. Tak for Deres tålmodighed og forståelse.

6. 26. oktober 2026 kl. 03.17 UTCpostmortem

   # Customer Impact Mellem 13: 37 og 14: 40 UTC den 13. oktober 2026, kunder på tværs af flere regioner var ude af stand til at bruge IXP ustrukturerede dokumenter, IXP Communications Mining og dokument forståelse. Computer Vision og Autopilot til udviklere funktioner, der afhænger af de samme machine learning tjenester også mislykkedes. Påvirkede kunder så anmodninger mislykkes med "500 Intern Server Fejl" svar eller tid ud, IXP-projekter, der ikke ville åbne, og Computer Vision aktiviteter mislykkes i at køre automatiseringer. Tjenesten blev afbrudt i cirka 1 time. Ingen kundedata blev tabt. # Root Cause Hændelsen skyldtes et udløbet sikkerhedscertifikat, der blev anvendt til at etablere sikre forbindelser til disse tjenester. Certifikatet fornys automatisk. Denne proces blev ikke længere gennemført med succes, og fejlene rejste ingen alarm, så certifikatet blev ikke erstattet, før det udløb. Sikre forbindelser til de berørte tjenester blev afvist fra 13: 37 UTC. # Detection Automatisk overvågning begyndte at advare om fejl og manglende trafik på 13: 40 UTC, og hændelsen blev erklæret på 13: 54 UTC. Det udløbet certifikat blev identificeret på 14: 00 UTC, og den første status side opdatering blev sendt på 14: 03 UTC. Ingen alarm advarede om, at certifikatet var ved at udløbe, og de gentagne svigt i den automatiserede fornyelse blev ikke rapporteret til ejeren team, så problemet blev først opdaget, når kunderne blev påvirket. # Response Kl. 14.06 UTC bekræftede holdet, at certifikatet var udløbet, fordi den automatiserede fornyelse var mislykkedes. Kl. 14: 18 UTC blev der udstedt en ny kredit til fornyelsesprocessen. Fornyelsen blev startet manuelt kl. 14: 19 UTC og afsluttet kl. 14: 33 UTC, og ved 14: 37 UTC var alle kundevendte endepunkter blevet verificeret for at tjene det fornyede certifikat. Trafikken tilbage til normale niveauer med ca. 14: 40 UTC. Efter en periode med overvågning, hændelsen blev løst på 15: 19 UTC. # Follow - Up For at forebygge lignende hændelser i fremtiden foretager vi følgende forbedringer: - Advar i god tid før disse certifikater udløber. - Underret ejeren, når den automatiske fornyelse mislykkes. - Tilføj kontrol, der alarm, så snart sikre forbindelser til disse tjenester mislykkes. - Styrke ejerskabet af certifikatfornyelsesprocessen og de akkreditiver, den bygger på.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 13. oktober 2026 kl. 10.32 UTCinvestigating

   Vi undersøger problemet, hvor robot henrettelse logs ikke dukker op i Orchestrator. vi arbejder på at bestemme det fulde omfang og rod årsag.

2. 13. oktober 2026 kl. 10.57 UTCresolved

   Dette spørgsmål er blevet løst. Robot udførelse logs er synkronisering og er synlige i Orchestrator igen for Japan Orchestrator. Tak for din tålmodighed.

3. 22. oktober 2026 kl. 13.25 UTCpostmortem

   Kundeeffekt Mellem ca. 07: 00 UTC den 9 okt 2026 og 10: 45 UTC den 13 okt 2026, omkring 6% af robot log poster for kunder i Japan regionen ikke vises i Orkestrator. Job udførelse og alle andre Orchestrator funktionalitet blev ikke påvirket. Manglende poster blev synlige i Orchestrator efter udstedelsen blev rettet. # Root cause Robot logs er placeret på en kø opdelt i 32 partitioner, og en indtagelse service læser hver partition og gemmer logs til Orchestrator. Den 9. oktober stoppede indtagelse service i Japan region læsning fra 2 af de 32 partitioner uden at rapportere en fejl. Logge på disse partitioner blev holdt i køen, men ikke gemt, så de ikke vises i Orkestrator. Vores overvågning tjekkede tjenesten som helhed, ikke hver partition, så problemet blev ikke opdaget automatisk. # Detection Spørgsmålet blev opdaget gennem kunderapporter. Vi erklærede en hændelse på 10: 13 UTC den 13. oktober og sendt en status side meddelelse på 10: 32 UTC. # Response Vi genstartet indtagelse service på omkring 10: 41 UTC, og det genoptaget læsning alle partitioner. De logfiler, der blev holdt i køen blev derefter behandlet og blev synlig i Orchestrator. Hændelsen blev løst kl. 10.57 UTC. # Follow up * Vi tilføjer overvågning, der advarer os, når en enkelt partition stopper med at blive læst, så denne form for problem er opdaget inden for få minutter.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 7. oktober 2026 kl. 21.34 UTCinvestigating

   Vi er ved at undersøge rapporter om et udfald, der påvirker HITL 's fejlskabelse af opgaver for Maestro i USA. Indvirkning: Brugerne kan være ude af stand til at oprette ITL-opgaver. Næste opdatering: Vores hold arbejder på at forstå årsagen og omfanget og vil dele opdateringer som tilgængelig.

2. 8. oktober 2026 kl. 01.30 UTCidentified

   Vi har identificeret årsagen til et udfald, der påvirker oprettelsen af HITL-opgaver for Maestro i USA og arbejder på at afbøde problemet. Indvirkning: Brugerne kan være ude af stand til at oprette ITL-opgaver. Næste opdatering: Vores hold arbejder på at afbøde problemet og vil dele opdateringer som tilgængelig.

3. 8. oktober 2026 kl. 03.28 UTCmonitoring

   Vi ruller ud fix for en udfald påvirker HITL opgave skabelse for Maestros med HITL opgave SLA timere konfigureret i USA og arbejder på at afbøde problemet. Impact: Brugere kan være ude af stand til at oprette HITL opgaver i Maestros med HITL opgave SLA timere konfigureret. Næste opdatering: Vores hold arbejder på at afbøde problemet og vil dele opdateringer som tilgængelig.

4. 8. oktober 2026 kl. 04.29 UTCresolved

   Fixet for det problem, der påvirker HITL-opgaveoprettelsen for Maestro med HITL-opgave SLA-timere konfigureret i USA er blevet fuldt rullet ud. HITL 's oprettelse af opgaver er blevet normal igen.

5. 26. oktober 2026 kl. 03.16 UTCpostmortem

   Kundeeffekt På 2026- 10- 05 mellem 9,30 PM UTC - 2026- 10- 07 3,30 AM UTC, Maestro BPMN og Case kunder, der bruger HITL knudepunkter med en konfigureret Task Timer så fejl i deres debug og produktion tilfælde på HITL-stadiet, med 4xx. Omkring 30 sådanne tilfælde på tværs af kunder i USA og Europa blev identificeret, som blev blokeret uden arbejde. # Root cause Ved at opstille en opgave kræver SLA et objekt, herunder start- og slutkriterierne, tidspunktet for SLA og resultatet af SLA-bruddet. Kunder konfigurere det på Maestro designer på HITL node. Resultatet blev fejlagtigt holdt ikke-obligatorisk på designoverfladen, selv om en SLA-konfiguration uden resultat ikke er vedholdende og ikke giver business mening. The Action Center backend team havde tilføjet en validering for at kaste en dårlig anmodning (400) i tilfælde af en ikke null SLA objekt med et manglende resultat. Dette endte med at påvirke kunder, der havde tilføjet Start / End kriterier på node, men ikke konfigureret et resultat. Tilfælde, der tidligere kørte mislykkedes med 400s, og var ude af stand til at genoptage # Detection En kunde rapporterede spørgsmålet til Maestro Engineering SME, der rejste det internt med holdet. Maestro teamet undersøgte denne fiasko, og observerede et stigende antal fejl for USI, og et par andre lejere via logfiler, der førte dem til at engagere Action Center team. # Response Maestro teamet modtog rapport om problemet fra kunden via e-mail, og de gjorde nogle indledende undersøgelse og identificerede en potentiel regression, hvorefter, Action Center SME var engageret, spørgsmålet reproduceres på lavere miljøer, en rollback af funktionen anvendt og testet, og rullet ud til alle berørte regioner. Den blev løst med, at alle tilfælde blev genprøvet internt og genoptaget. # Follow up 1. Tilføj validering for dette scenario på tværs af alle cross service codebase overflader for at sikre menneskelig gennemgang 2. Tilføj nødvendige overvågning og integration test på plads for at opdage dette problem hurtigere

Automatisk oversat fra den officielle hændelsesopdatering.

1. 7. oktober 2026 kl. 17.37 UTCinvestigating

   Vi undersøger rapporter om periodisk langsommelighed og fejl, der påvirker en delmængde af organisationer i East US region af Automation Cloud. Berørte brugere kan se sider i Orchestrator UI undlader at indlæse (for eksempel, Jobs side vender tilbage "En fejl er sket"), og robot operationer såsom kø transaktioner og session starter kan periodisk time ud. Vi vil give en opdatering, så snart mere information er tilgængelig.

2. 7. oktober 2026 kl. 18.13 UTCmonitoring

   Vi har anvendt en kapacitetsforøgelse på den berørte database infrastruktur i det østlige USA region og fejlrater og latency vendt tilbage til normale niveauer. Vi vil give en opdatering, så snart mere information er tilgængelig.

3. 7. oktober 2026 kl. 19.06 UTCresolved

   Vi har problemet i den østamerikanske region, og fejlprocenter og latenstid er vendt tilbage til normale niveauer.

4. 14. oktober 2026 kl. 11.42 UTCpostmortem

   Kundeeffekt Mellem ca. 13: 00 UTC og 18: 15 UTC den 7. oktober 2026, kunder i den amerikanske region oplevede intermitterende fejl og langsomme svar i Orkestrator. Berørte brugere kan have set Orchestrator sider undlader at indlæse, for eksempel Jobs side vender tilbage "En fejl er sket", og robot operationer såsom kø transaktioner og session starter kan have periodisk timet ud. Andre UiPath-tjenester, der afhænger af Orchestrator kan også have set langsommere svar eller fejl i denne periode. # Root cause Flere hyppigt anvendte Orchestrator operationer hver baseret på en delt kortlivede ressource inde i databasen, herunder den rutinemæssige status kontrol, at hver kørende robot udfører. Da mængden af sideløbende robot aktivitet i denne region voksede, anmodninger begyndte queuing for adgang til den fælles ressource i stedet for at fuldføre deres arbejde. Virkningen var selektiv snarere end en generel afmatning: de operationer, der anvendte denne ressource, blev forsinket, mens andre fortsatte med at køre normalt. Da databasens processor, hukommelse og opbevaring brug alle forblev inden for normale intervaller, rutinemæssig kapacitetsovervågning ikke indikere et problem. # Detection Vores automatiserede overvågning opdagede nedbrydningen inden for ca. 35 minutter efter kundens påvirkning begynder, og vores ingeniører identificerede den underliggende påstand under begivenheden. Da dette var et stridsproblem snarere end en mangel på kapacitet, og alle kapacitetsindikatorer var normale, forventedes det ikke, at den øgede databasekapacitet ville løse det, og gruppen undersøgte alternativer, før den blev anvendt. Denne vurdering forsinkede afbødningen. # Response Vores ingeniørhold øgede kapaciteten i den berørte database. Responstider og fejlrater vendte tilbage til normal straks, og vi fortsatte overvågning for at bekræfte, at tjenesten var stabil, før du lukker hændelsen. * 13: 00: Fejlhastigheder og svartider begynder at stige for kunder i den amerikanske region. * 13: 36: Automatisk overvågning registrerer nedbrydningen og underretter on- call engineering team. * 13: 36 - 17: 29: Ingeniører undersøge. Alle standard databasekapacitetsindikatorer - processor, hukommelse og lagring - forbliver inden for normale intervaller i hele, så årsagen er ikke tydeligt fra rutinemæssig overvågning. * 17: 29: En formel hændelse er erklæret og fuld respons team er engageret. 17: 38 Der offentliggøres en offentlig meddelelse om [UiPath Status] (http: / / status.uipath.com /)\ (Efterforsker\). * 17: 31 - 17: 43: Yderligere databasekapacitet er afsat til den berørte region. * 18: 00: Fejlhastigheder, svartider og anmodning latency tilbage til normale niveauer. * 18: 11: Status siden er opdateret til Overvågning & Kundens effekt slutter. * 19: 06: hændelsen er lukket efter kontinuerlig overvågning bekræfter, at tjenesten er stabil. # Follow up For at forhindre dette i at ske igen, er vi: * Ændring af de berørte operationer, så de ikke længere afhænger af den fælles ressource. Dette er blevet rullet ud til alle berørte systemer og har væsentligt reduceret den tilstand, der forårsagede hændelsen. * Aktivering detaljeret database overvågning på disse systemer, så denne klasse af striden er synlig, mens det sker snarere end bagefter. * Forbedring af vores alarmering, så en ægte nedbrydning af denne type er klart adskiller sig fra rutine, selvkorrigerende variation, og eskaleres hurtigere.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 6. oktober 2026 kl. 17.50 UTCinvestigating

   Vi undersøger rapporter om en udfald påvirker [påvirket funktionalitet eller brugersymptom] for Orchestrator i Europa. Indvirkning: Brugerne kan forvente forsinkelser for indtagelse af robot logs og / eller søgning / visning af logfiler. Ingen logfiler vil gå tabt. Næste opdatering: Vores hold arbejder på at forstå årsagen og omfanget og vil dele opdateringer som tilgængelig.

2. 6. oktober 2026 kl. 18.28 UTCidentified

   Vi har identificeret årsagen til en afbrydelse, der påvirker indtagelse af robotstammer til Orchestrator i Europa. Indvirkning: Brugerne kan forvente forsinkelser for indtagelse af robot logs og / eller søgning / visning af logfiler. Ingen logfiler vil gå tabt. Næste opdatering: Vores hold arbejder på at forstå årsagen og omfanget og vil dele opdateringer som tilgængelig.

3. 6. oktober 2026 kl. 18.43 UTCmonitoring

   Vi har afbødet problemet med indtagelse af robotstammer til orkestrator i Europa. Indvirkning: Brugerne kan forvente forsinkelser for indtagelse af robot logs og / eller søgning / visning af logfiler. Ingen logfiler vil gå tabt. Næste opdatering: Vores hold arbejder på at forstå årsagen og omfanget og vil dele opdateringer som tilgængelig.

4. 6. oktober 2026 kl. 18.44 UTCresolved

   Vi har afbødet problemet med indtagelse af robotstammer til orkestrator i Europa. Indvirkning: Brugerne kan forvente forsinkelser for indtagelse af robot logs og / eller søgning / visning af logfiler. Ingen logfiler vil gå tabt. Næste opdatering: Vores hold arbejder på at forstå årsagen og omfanget og vil dele opdateringer som tilgængelig.

5. 7. oktober 2026 kl. 11.08 UTCpostmortem

   Kundeeffekt På, mellem ca. 15: 45 UTC og 18: 45 UTC, kunder hostet i Europa, Australien og Japan var ude af stand til at se de seneste robot logs i Orchestrator. Logs skrevet under slagvinduet ikke vises i Jobs og Logs visninger eller gennem Robot Logs API, og logfiler ældre end ca. 03: 00 UTC den dag var kun tilgængelige periodisk. Anslagsvinduet varierede fra region til region: - Australien: ca. 15: 45 UTC til 18: 35 UTC - Europa: ca. 16: 35 UTC til 18: 00 UTC - Japan: ca. 16: 45 UTC til 18: 30 UTC Job udførelse, køer, udløsere og alle andre Orchestrator funktionalitet blev ikke påvirket. Ingen robot logs blev tabt. Logge produceret under slagvinduet fortsatte med at blive indsamlet og blev synlig igen, da problemet blev afbødet. # Root cause Vi foretog en planlagt opgradering af Elasticsearch tjenesten, der gemmer Orchestrator robot logs. Opgraderingen bruger en blå / grøn tilgang: en ny klynge er skabt sammen med den eksisterende, dataene er genoprettet i det fra en backup, rørledningen, der indtager nye logs er startet på det, og først da er trafikken skiftet over. I de berørte regioner, trafik switch blev godkendt af den ingeniør, der kører opgraderingen, før data retablering og indtagelse catch- up havde afsluttet, hvilket er en afvigelse fra vores opgradering procedure. Det var en menneskelig fejl. Som et resultat, Orchestrator var at læse robot logs fra en klynge, der endnu ikke indeholder nyere data, mens nye logs fortsatte med at blive indsamlet, men endnu ikke var indekseret på klyngen servering anmodninger. Fejlen blev ikke fanget, fordi vores implementering værktøj er afhængig af operatøren til at kontrollere data fuldstændighed og ikke håndhæve ordren mellem data gendannelse og trafik switch. # Detection Vores syntetiske overvågning, som løbende kører test job og kontrollerer, at deres logfiler returneres, opdaget manglende logfiler i de berørte regioner og rejst advarsler. Vores ingeniørhold korrelerede varslerne med in- progress opgraderingen, erklærede en hændelse og offentliggjorde en statusside meddelelse. # Response Vores ingeniørhold vendte trafikken tilbage til de tidligere Elasticsearch klynger i alle tre regioner, som straks genoprettet adgang til alle robot logs, herunder dem, der produceres under slagvinduet. Vi bekræftede bedring gennem syntetisk overvågning i alle berørte regioner og fortsatte overvågning før markering hændelsen løst omkring 18: 45 UTC. Opgraderingen af de nye klynger fortsætter i baggrunden. Trafikken vil først blive flyttet til dem, når data gendannelse er færdig og indtagelse er bekræftet at være up to date. # Follow up For at forhindre dette i at ske igen, er vi: - Ændring af deployeringsrørledningen, så trafikkontakten ikke kan køre, før data gendannelse og log indtagelse på den nye klynge er verificeret som komplet. - Tilføjelse af et automatisk rollback-trin til rørledningen, så trafikken kan returneres til den forrige klynge inden for få minutter, hvis et problem opdages efter en kontakt.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 6. oktober 2026 kl. 12.38 UTCidentified

   Vi observerer forringet ydeevne for tjenester i UAE

2. 6. oktober 2026 kl. 12.43 UTCinvestigating

   Vi undersøger i øjeblikket dette spørgsmål.

3. 6. oktober 2026 kl. 14.01 UTCidentified

   Vi har identificeret problemet som et netværksrouting problem med en tredjeparts tjenesteudbyder, der påvirker forbindelse til vores tjenester hostet i De Forenede Arabiske Emirater. Vi arbejder med vores opstrømsleverandør om opløsning og vil opdatere fremskridt her.

4. 6. oktober 2026 kl. 14.22 UTCidentified

   Vi fortsætter med at arbejde på en løsning på dette problem.

5. 6. oktober 2026 kl. 14.51 UTCmonitoring

   Vi overvåger forbindelsen og vil opdatere denne side, når stabiliteten er bekræftet.

6. 6. oktober 2026 kl. 15.09 UTCmonitoring

   Vi fortsætter med at overvåge for yderligere spørgsmål.

7. 6. oktober 2026 kl. 17.09 UTCresolved

   Hændelsen er løst.

8. 21. oktober 2026 kl. 05.36 UTCpostmortem

   Kundeeffekt Mellem 12: 38 PM UTC og 2: 51 PM UTC, en delmængde af kunder i UAE-regionen oplevede fejl, når adgang til UiPath cloud-tjenester. Hændelsen varede omkring 2 timer og 13 minutter. Påvirkede tjenester omfattede adgang til * * cloud.uipath.com * *, * * account.uipath.com * * Tjenester hostet i UAE. Kunder kan have mødt timeouts, mislykkedes godkendelse, nulstille forbindelser, eller server fejl. # Root cause Den grundlæggende årsag var en regional netværk routing fiasko på en tredjeparts infrastruktur udbyder. En delmængde af outbound netværk stier fra UAN regionen til specifikke eksterne netværk - herunder indhold levering netværk servering * * cloud.uipath.com * * og * * account.uipath.com * * - stoppet levere trafik. Nye udgående tilslutningsforsøg fra berørte tjenester fik ikke svar, hvilket førte til anmodninger om timeout. Vores engineering team udelukket UiPath service konfiguration, applikation- niveau politik, og udgående tilslutning kapacitet som årsager. Infrastrukturleverandøren anerkendte et kendt problem, der påvirker flere kunder på samme netvej. # Detection Spørgsmålet blev opdaget gennem automatiseret overvågning. Ved omkring 12: 40 pm UTC - ca. to minutter efter fejlen begyndte - undersøgelsen bekræftede, at nye forbindelser fra berørte UAN region tjenester til nøgle UiPath endepunkter var mislykket. # Response Ved 1: 20 UTC, vores ingeniør team bekræftede, at fejlen var begrænset til specifikke udgående netværksstier, mens andre destinationer forblev tilgængelige. Validering udelukket UiPath- side routing ændringer, indhold levering konfigurationsændringer, application- level politik, og udgående forbindelse kapacitet spørgsmål. En stor støttesag blev indledt med den tredjeparts infrastrukturudbyder. Kl. 1: 50 UTC anerkendte udbyderen et kendt problem, der påvirker flere kunder. Vores team fortsatte overvågning opsving fra de berørte netværk stier og kontrollere service sundhed som trafikken vendte tilbage. Kl. 02: 51, UTC, gendannelseskontrol bekræftede, at UiPath trafik gennem de berørte indhold leveringsveje var vendt tilbage til normale niveauer. Automatiseret sundhedskontrol og service målinger bekræftet opsving, og Services i UAN var operationelle. # Follow up 1. Vi forfølger infrastrukturudbyderens bekræftede korrigerende handling og grundlæggende årsag analyse for den regionale routing fiasko. 2. Vi gennemgår outbound service afhængigheder i den berørte region for at styrke modstandsdygtigheden mod lignende tredjeparts netværk forstyrrelser.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 2. oktober 2026 kl. 16.23 UTCinvestigating

   Da omkring 15: 05 UTC, nogle kunder i den amerikanske region kan se job, der kører på Cloud Robots tage længere end normalt at starte, eller ophold i afventende tilstand. Jobs på dine egne robotter er ikke påvirket, og det er andre regioner heller ikke. Vi har fundet den sandsynlige årsag og arbejder på at genoprette normal jobbehandling. De arbejdspladser, der allerede er i kø, går ikke tabt og vil blive behandlet, når spørgsmålet er løst. Vi sender en ny opdatering inden for 60 minutter.

2. 2. oktober 2026 kl. 16.34 UTCmonitoring

   Vi har anvendt et fix for det problem, at forsinkede job på Cloud Robots i den amerikanske region, og job starter normalt igen. Forsinkede job behandles nu. Vi overvåger, at tjenesten forbliver stabil og vil sende en ny opdatering inden for 60 minutter.

3. 2. oktober 2026 kl. 16.51 UTCmonitoring

   Efter yderligere arbejde med spørgsmålet begynder job på Cloud Robots i den amerikanske region nu normalt. De tidligere forsinkede job er under behandling. Vi fortsætter med at overvåge tjenesten og vil sende endnu en opdatering, når problemet er løst.

4. 2. oktober 2026 kl. 17.03 UTCresolved

   Dette spørgsmål er blevet løst. Mellem 15: 05 og 16: 39 UTC var job på Cloud Robots i den amerikanske region langsomme til at starte eller blive i den afventende stat. Jobbene har været startet normalt siden 16: 39 UTC, og job, der blev forsinket i løbet af denne tid, er nu blevet behandlet. Vi undskylder forstyrrelsen.

5. 14. oktober 2026 kl. 14.20 UTCpostmortem

   Kundeeffekt Fra 15: 00 til 16: 38 UTC den 2026- 10- 02, Cloud Robots job i den amerikanske region tog længere end normalt at starte, op til 22 minutter på toppen omkring 16: 20 UTC. Orchestrator var ledig, intet job gik tabt, ingen andre områder blev berørt. Et lille antal kunder modtog en midlertidig grænse fejl på nye indlæg, mens deres tidligere job ventede. # Detection Automatiserede alarmer affyret klokken 15: 07 UTC, syv minutter efter kollisionen begyndte. Kontrol i den amerikanske region mislykkedes fra omkring 15: 32 UTC og hændelsen reaktion startede. # Root cause Kl. 14: 55 UTC begyndte en kundes workflow at indsende job til omkring 20 gange den normale pris. Den service, der indrømmer job holder en per-kunde concurrency tæller i databasen og opdaterer det under en database lås på hver job start og ende. På det tempo lock kø for kundens rekord voksede indtil opdateringer timet ud. De ventende opdateringer besatte den fælles pulje af arbejdstagere, der starter job for alle kunder i regionen, så hver kundes job ventede bag dem. Mekanismen, der skulle isolere en kundes last, blev flaskehalsen. # Response Holdet identificerede den overbelastede adgangsvej og arbejdsbyrden bag den. En første konfiguration ændring på 15: 46 UTC rettet den forkerte rekord og havde ingen effekt. Den korrekte ændring kl. 16: 10 UTC fritog denne kundes jobtype fra databaselåsen og trådte i kraft kl. 16: 20 UTC. Starttiderne faldt fra omkring 13 sekunder til under et sekund, og efterslæbet på omkring 5200 job drænet på 18 minutter. Jobstart var normalt kl. 16.38 UTC. Kundens udløser blev slukket med kunden omkring 16: 40 UTC. # Follow up Database- låst hastighedsbegrænsning erstattes af in-memory høj performance hastighedsbegrænsning mekanisme, så en kundes belastning kan ikke blokere job starter for andre. Ændringen er komplet, testet i præproduktion ved samme belastning, og bliver rullet ud.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 2. oktober 2026 kl. 00.13 UTCinvestigating

   Vi er i øjeblikket ved at undersøge en afbrydelse, der påvirker Insights portalen i De Forenede Arabiske Emirater. Brugere i denne region kan være ude af stand til at få adgang til portalen eller opleve fejlslagne sidebelastninger. Vores team arbejder aktivt på at identificere årsagen og genoprette tjenesten. Vi vil give en anden opdatering, så snart vi har flere oplysninger.

2. 2. oktober 2026 kl. 00.36 UTCidentified

   Vi har identificeret en afbødende vej og er ved at starte en rollback i De Forenede Arabiske Emirater. Brugerne kan fortsætte med at opleve intermitterende adgangsproblemer med Insights portalen, mens dette arbejde er i gang. Vi vil give en anden opdatering, når rollback er færdig.

3. 2. oktober 2026 kl. 00.41 UTCmonitoring

   Insights-portalen i UAE-regionen indlæses nu med succes efter vores rollback. Vi fortsætter med at overvåge tjenesten for at bekræfte stabiliteten og vil levere en endelig opdatering, når vi er sikre på, at problemet er helt løst.

4. 2. oktober 2026 kl. 00.51 UTCresolved

   The Insights portal i De Forenede Arabiske Emirater fungerer nu normalt efter rollback. Vi har valideret vigtige portal funktionalitet og bekræftet, at tjenesten forbliver sund. Denne hændelse er nu løst.

5. 5. oktober 2026 kl. 22.58 UTCpostmortem

   # Customer Impact Den * * Oktober 1, 2026 * *, UiPath * * Indsigt * * service i * * UAE region * * var ikke tilgængelig. Fra ca. * * 23: 40 UTC den 1. oktober til 00: 39 UTC den 2. oktober * *, kunne brugerne ikke indlæse Insights dashboards: anmodninger mislykkedes med en fejl efter omkring 10 sekunder. Anmodninger om at give Insights for nye lejere i regionen også mislykkedes. Afbrydelsen varede cirka * * 59 minutter * *. Andre UiPath-tjenester i De Forenede Arabiske Emirater og Insights i alle andre regioner blev ikke påvirket. Ingen kundedata blev tabt. # Root Cause Udbrud var forårsaget af en * * konfiguration ændring * *, der sendes i en skemalagt Insights udgivelse. Ændringen hævede * * minimum TLS\ (Transport Layer Security\) version * * på Insights applikation endepunkter i UAE-regionen fra TLS 1.2 til * * TLS 1.3 * *, som en del af en sikkerhedshærdning. Den UiPath gateway, der ruterne kundetrafik til Insights forbinder til disse slutpunkter over TLS 1.2. Når slutpunkterne holdt op med at acceptere TLS 1.2, kunne porten ikke længere åbne en sikker forbindelse til dem. Kunden anmoder timet ud og returnerede fejl, selv om Insights ansøgning selv forblev sund. Ændringen gjaldt kun for De Forenede Arabiske Emirater, og derfor blev ingen anden region berørt. # Detection Problemet blev opdaget af * * UiPath automatiseret syntetisk overvågning * *, som løbende tester Insights tilgængelighed fra flere steder. Den første fejlslagne helbredsundersøgelse blev registreret kl 23: 40 UTC. Automatiserede alarmer affyret inden for få minutter, og on-call ingeniørholdet begyndte at undersøge. # Response Teknikerholdet bekræftede, at udbruddet kun påvirkede Insights i De Forenede Arabiske Emirater. Ansøgningen kørte normalt, men ingen kunde trafik nåede det. Holdet sporede den manglende forbindelse mellem gateway og Insights og knyttede den til TLS-indstillingen, som udgivelsen anvendte. Ved ca. * * 00: 38 UTC * *, genoprettede holdet den tidligere minimum TLS version\ (TLS 1.2\) på de berørte endepunkter. Syntetisk sundhedskontrol begyndte at passere straks, og ved * * 00: 41 UTC * * alle Insights kontrol i De Forenede Arabiske Emirater region var sunde. Holdet holdt overvågning for at bekræfte fuld stabilitet. # Follow - Up For at undgå lignende hændelser i fremtiden tager vi følgende skridt: * * * Fjern TLS-ændringen fra udgivelsen * * så fremtidige installationer ikke gen- anvende det, indtil gateway understøtter TLS 1.3 ende til ende. * * * Validering af forbindelse - sikkerhedsændringer mod gateway * * i et præ-produktionsmiljø, før de anvendes på produktion.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 1. oktober 2026 kl. 18.57 UTCinvestigating

   Fra den 1. oktober ved ca. 1: 30 PM UTC, nogle agenter, herunder både lav-kode og kodede agenter, begyndte at opleve fejl på tværs af alle regioner, når du bruger gemini- 3,1-pro- preview og gpt- 4o-2024- 05-13. Disse modeller kan også være utilgængelige for udvælgelse under agent design. Vi undersøger og arbejder aktivt på et fix.

2. 1. oktober 2026 kl. 19.05 UTCidentified

   Vi har identificeret problemet og er ved at iværksætte et fix. Agenter, der bruger de berørte modeller, kan fortsætte med at opleve fejl, og modellerne kan forblive utilgængelige for udvælgelse under agent design, mens indsættelsen er afsluttet.

3. 1. oktober 2026 kl. 19.46 UTCresolved

   Vi har vendt den ændring, der forårsagede dette problem, og bekræftet, at de berørte modeller er tilgængelige igen. Nogle agenter kan fortsætte med at opleve intermitterende svigt, mens tilfælde genopfriske. Vi fortsætter med at overvåge agent design og udførelse for gemini- 3.1- pro- preview og gpt- 4o- 2024- 05- 13.

4. 7. oktober 2026 kl. 10.15 UTCpostmortem

   Kundeeffekt Den 1. oktober 2026, fra 14: 31 til 19: 40 UTC, agenter konfigureret med nogle store sprog modeller, herunder Gemini 3.1 Pro Preview og GPT- 4o (2024- 05- 13), undladt at starte i alle regioner, med en fejl om, at modellen ikke er tilgængelig. De samme modeller manglede på modellisten, mens de designede agenter. Agenter, der anvendte andre modeller, blev ikke påvirket. # Root cause Et feature flag blev vendt, hvilket fik Agent service til at begynde at sende en operation kode til model opdagelse anmodninger. Dette forårsagede listen over modeller tjente til at være denne specifikke operation i modsætning til base agenter model liste. Den per operation model liste blev oprindeligt seedd fra Bring Your Ewn Model (BYOM) konfiguration af overridable modeller, som afgørende for agenter ikke have paritet med den fulde liste over understøttede modeller i Agent service. Intern revision viste, at dette var en fejl og ikke et bevidst hul. Over tid dette hul blev aldrig behandlet, og efter flaget switch, agenter allerede konfigureret med nogen af de berørte modeller ville mislykkes på grund af deres fravær fra den returnerede liste. # Detection En kunde rapporterede om problemet, og det blev eskaleret til vores ingeniører på 16: 44 UTC. Vores overvågning ikke alarm, fordi denne fejl normalt peger på organisation eller agent niveau konfiguration spørgsmål. # Response Ingeniørerne sporede fejlene til konfigurationsændringen og vendte tilbage kl. 19: 01 UTC. Tilbagekaldelsen trådte i kraft i de følgende minutter, og den sidste fejl indtraf kl. 19: 40 UTC. # Follow up 1. Modellisterne vil blive justeret, før denne ændring foretages igen. 2. Vi ændrer hvordan denne fejl er klassificeret så en platformbred spike advarer vores ingeniører.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 1. oktober 2026 kl. 18.17 UTCinvestigating

   Fra den 1. oktober kl. 12: 00 UTC kan brugere i Europa opleve fejl i LowCode-agenter, der bruger løsninger-lokale Action Apps. Vi har bekræftet, at virkningen er begrænset til brugere i Europa. Vi undersøger aktivt problemet, bestemmer omfanget af fiaskoerne og arbejder på en rettelse.

2. 1. oktober 2026 kl. 18.25 UTCidentified

   Vi har identificeret problemet, der forårsager svigt i lavkode-agenter, der bruger løsninger-lokale handling apps for lokalsamfundets brugere i Europa. Vi vender tilbage til de tidligere ændringer og fortsætter med at overvåge opsvinget. Vi vil give en anden opdatering, når rollback er færdig, eller hvis vi har yderligere oplysninger at dele.

3. 1. oktober 2026 kl. 20.08 UTCresolved

   Vi har bekræftet, at rollback er afsluttet, og problemet med at påvirke low-code agenter, der bruger løsninger-lokale handling apps for lokalsamfundets brugere i Europa er blevet løst. Tjenesten er kommet sig, og vi lukker denne hændelse.

4. 7. oktober 2026 kl. 14.28 UTCpostmortem

   Kundeeffekt Den 1. oktober 2026, fra 10: 50 til 19: 50 UTC, nogle Studio Web-brugere i Europa kunne ikke debug agenter, der kalder Orkestrator processer (RPA, agenter, osv.) eller Action Apps fra samme løsning. Opkaldet mislykkedes med en "ikke fundet" fejl. Offentliggjorte agenter og produktionsjob blev ikke berørt. # Root cause En Studio Web opdatering ændrede hvordan løsning ressourcer er placeret under debugging. Det manglede en indstilling, der holder den tidligere adfærd, så debug kører ledt efter løsningens ressourcer i brugerens personlige arbejdsrum i stedet for debug mappe. # Detection Automatiserede end- to- end tests alarmerede vores ingeniører kl 16: 43 UTC. Den end-to-end test suite kører en gang hver 2 timer og advarsel kun sker efter 3 på hinanden følgende test svigt. Spørgsmålet blev også rapporteret fra et kundemiljø. # Response Efter at identificere roden årsag, en rollback blev startet kl 18: 00 UTC og var fuldt ud i kraft kl 19: 50 UTC. Denne varighed omfattede en deployering fiasko, der skulle afprøves igen, hvilket tog 50 minutter. En korrigeret version, der omfatter indstillingen blev indsat den 2. oktober kl 13: 00 UTC. # Follow up 1. Indstillingen er nu en del af hovedkodelinjen, så fremtidige udgivelser omfatter det. 2. Vi forbedrer varslingerne og slut- til- end test suite til at fange regressioner tidligere.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 1. oktober 2026 kl. 16.32 UTCresolved

   Mellem 14: 23 og 16: 04 UTC den 1 oktober 2026, nogle anmodninger om at slette elementer i UiPath Automation Cloud tjenester i Australien regionen mislykkedes med "404 Ikke Fundet" fejl. De berørte tjenester omfattede Orchestrator, Dokumentforståelse, AI Center og Data Service. Andre operationer, såsom visning, oprettelse og ajourføring af emner, der fungerede normalt. Årsagen var en konfiguration ændring til vores anmodning routing. Vi rullede det tilbage og tjenesten er fuldt restaureret.

2. 7. oktober 2026 kl. 10.15 UTCpostmortem

   Kundeeffekt Mellem den 1. oktober 2026 kl. 14: 23 UTC og kl. 16: 04 UTC oplevede en undergruppe af kunder * * 404 Ikke fundet * * fejl for nogle UiPath Automation Cloud anmodninger i Australien-regionen. Hændelsen varede 1 time og 41 minutter. Berørte anmodninger omfattede slette operationer og nogle Robot forbindelse kontrol. De berørte tjenester omfattede Orchestrator, Dokumentforståelse, AI Center og Data Service. Robot job, der kaldes Orchestrator kan have slået fejl, og kunder kan være nødt til at køre eventuelle Robot job, der mislykkedes i løbet af dette vindue. Alle andre operationer blev ikke påvirket. # Root cause En routing konfiguration ændring blev anvendt på Australien-regionen med et ufuldstændigt sæt af understøttede operationer på grund af en timeout i udslipsledningen. Slet operationer manglede i konfigurationen, så disse anmodninger blev afvist på routing lag med * * 404 Ikke Fundet * * før nå de underliggende tjenester. # Detection Automatiseret end-to-end overvågning opdagede problemet ved at advare om fejl ved dokument Forståelse service kontrol. Vores ingeniørhold brugte derefter interne overvågningsdata til at bekræfte det bredere mønster af fejl på tværs af berørte tjenester. # Response I løbet af undersøgelsen viste overvågningsdata, at anmodninger, der blev sendt gennem Australien regionen, vendte tilbage * * 404 Ikke fundet * * fejl, mens anmodninger, der blev sendt gennem andre regioner, var upåvirket. Analyse viste, at starttidspunktet for * * 404 Ikke fundet * * respons stigning var korreleret med det tidspunkt, hvor routing konfiguration kom i kraft. Holdet vendte routing konfiguration til den tidligere arbejdsversion. Efter tilbagefald, overvågning viste fejltællinger falder inden for omkring tre minutter, og tjenesten blev fuldt restaureret i oktober 1, 2026 kl 04: 04 UTC. # Follow up 1. Forbedre routing lag advarsler om 4xx baseline ændringer 2. Detektere delvist anvendte routing konfigurationer, før de får virkning

Automatisk oversat fra den officielle hændelsesopdatering.