Uipath driftsforstyrrelser

1. 3. september 2026 kl. 15.34 UTCinvestigating

   Vi undersøger i øjeblikket spørgsmålet

2. 3. september 2026 kl. 15.39 UTCidentified

   Spørgsmålet blev identificeret, og der blev truffet passende afbødende foranstaltninger for at løse det.

3. 3. september 2026 kl. 15.47 UTCmonitoring

   Spørgsmålet er blevet løst med succes, og tjenesten er blevet fuldstændig genoprettet. Tjenesten fungerer normalt på dette tidspunkt.

4. 3. september 2026 kl. 16.17 UTCresolved

   Spørgsmålet er blevet løst med succes, og tjenesten er blevet fuldstændig genoprettet. Tjenesten fungerer normalt på dette tidspunkt.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 4. september 2026 kl. 17.48 UTCresolved

   The Insights instrumentbræt i Looker oplevede et problem, der forhindrede den seneste Maestro kører, fra at dukke op i instrumentbrættet Importerede regioner: USA, SEA, IND, CA, AUE, JP, UK Tidslinje for hændelser Start: 2. september 2026 kl. 20: 00 UTC Opløst: 4. september 2026 kl. 16: 30: 00 UTC Problemet er i øjeblikket løst, og Insights dashboard viser de seneste Maestro køre data.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 1. september 2026 kl. 13.49 UTCinvestigating

   Vi undersøger rapporter om forringet ydeevne påvirker digitalisering og udvinding til Document Forståelse og IXP i USA. Indvirkning: Brugerne kan opleve langsommelighed og mislykkede dokumenter Forståelse af driftstid operationer. Vores hold arbejder på at identificere årsagen og vil dele flere detaljer, efterhånden som undersøgelsen skrider frem.

2. 1. september 2026 kl. 14.07 UTCmonitoring

   Vi har identificeret problemet og anvendt en afbødning. Tjenester vender tilbage til sund tilstand, og vi overvåger tjenesterne.

3. 1. september 2026 kl. 15.06 UTCresolved

   Dette spørgsmål er blevet løst fuldt ud, og tjenesterne er stabile nu. Vi vil sende flere detaljer om hændelsen til status side snart.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 31. august 2026 kl. 16.55 UTCinvestigating

   Vi undersøger i øjeblikket spørgsmålet.

2. 31. august 2026 kl. 17.07 UTCidentified

   Vi har identificeret problemet og gennemført den nødvendige rettelse

3. 31. august 2026 kl. 18.24 UTCmonitoring

   Spørgsmålet er blevet afhjulpet, og tjenesten er i øjeblikket i drift. Vi vil fortsat nøje overvåge tjenestens sundhed og om nødvendigt træffe yderligere foranstaltninger.

4. 31. august 2026 kl. 19.39 UTCresolved

   Spørgsmålet er blevet afhjulpet, og tjenesten er i øjeblikket i drift. Vi vil fortsat nøje overvåge tjenestens sundhed og om nødvendigt træffe yderligere foranstaltninger.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 28. august 2026 kl. 15.41 UTCidentified

   Spørgsmålet er blevet identificeret, og holdet arbejder aktivt på at implementere et fix. Vi forventer, at udsendelsen begynder i de kommende timer.

2. 28. august 2026 kl. 17.27 UTCmonitoring

   Vi har identificeret årsagen til den forringede ydeevne, og vi er i færd med at implementere et fix i de kommende timer. Det påvirker linkede forespørgsler, hvor brugeren ikke har adgang til den oprindelige mappe. API overflade er upåvirket. Eksport via CSV kan bruges som workaround. Yderligere opdateringer vil blive leveret som vi bevæger os mod opløsning.

3. 28. august 2026 kl. 17.39 UTCidentified

   Vi har identificeret årsagen til den forringede ydeevne, og vi er i færd med at implementere et fix i de kommende timer. Det påvirker linkede forespørgsler, hvor brugeren ikke har adgang til den oprindelige mappe. API overflade er upåvirket. Eksport via CSV kan bruges som workaround. Yderligere opdateringer vil blive leveret som vi bevæger os mod opløsning.

4. 28. august 2026 kl. 20.00 UTCidentified

   Fixet anvendes i øjeblikket. Vi vil give endnu en opdatering kort efter indsættelsen er afsluttet på tværs af alle berørte regioner.

5. 28. august 2026 kl. 22.57 UTCresolved

   Løsningen er blevet gennemført med succes i alle regioner, og vi har bekræftet, at problemet er løst. Tjenesten fungerer som forventet.

6. 3. september 2026 kl. 08.49 UTCpostmortem

   Kundeeffekt Mellem august 28, 2026 kl. 15: 23 UTC og august 28, 2026 kl. 10: 57 UTC oplevede en undergruppe af kunder fejl ved åbning af kø element detaljer paneler i Orchestrator. Den berørte sti returnerede en 404 side for LINKED køer, når brugeren ikke havde adgang til den oprindelige mappe, hvor elementerne blev oprettet. Virkningen påvirkede kun Orkestrator UI interaktioner og det spænder over alle regioner, der kører den berørte softwareversion. Adgangen til programgrænsefladen til Orchestrator blev ikke påvirket, og der var adgang til at eksportere kødata til CSV som arbejdsområde. 7 timer. # Root cause Hændelsen var forårsaget af en regression i Orchestrator brugergrænseflade for forbundne køer adgang fra andre mapper. Regressionen ikke korrekt håndtere linked- kø detaljer flow, når den anmodende bruger manglede adgang til den oprindelige mappe, hvilket forårsagede kø element detaljer panel til rute til en 404 side i stedet for at vise de forventede oplysninger. # Detection Spørgsmålet blev opdaget gennem en automatisk hændelse alarm for Orchestrator front ende den 28 august 2026 på 15: 23 UTC. # Response Kl. 15: 31 UTC den 28. august 2026 beskrev vores ingeniørhold problemet som kunder, der ikke er i stand til at få adgang til detaljer i køen på grund af en regression. Kl. 15: 41 i UTC bekræftede en opdatering af den offentlige status, at den grundlæggende årsag var blevet identificeret, at en rettelse var ved at blive indsat, og at adgang til applikationsprogrammeringsgrænsefladen ikke var påvirket. Kl. 17: 27 blev anvendelsesområdet indsnævret til forbundne køer, hvor brugeren ikke havde adgang til den oprindelige mappe. Kl. 17: 29 fastslog holdet, at det oprindelige fix ikke fuldt ud dækkede det berørte scenario, og der blev udviklet et korrigeret fix. Kl. 17.30 blev det berørte scenario reproduceret, og det korrigerede fiks blev valideret lokalt. Klokken 17: 39 UTC, en status side opdatering dokumenteret CSV eksport som en workout. Implementeringen af det korrigerede fiks fortsatte på tværs af de berørte regioner. Kl. 10: 50 blev fixet bekræftet overalt. Klokken 10: 57 UTC, hændelsen blev markeret løst, og statussiden blev opdateret for at bekræfte, at tjenesten fungerede som forventet. # Follow up Formelle opfølgningsforanstaltninger følges op af den procedure for gennemgang efter hændelsen, der blev indledt ved resolution. # Action items - Udvidelse af vores automatiserede test sager til at omfatte dette scenario, og andre lignende scenarier relateret til forbundne objekter eller cross-mappe scenarier. - At sikre, at vi kan slukke alle ændringer via et flag for en hurtigere responstid.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 27. august 2026 kl. 17.16 UTCinvestigating

   Vi efterforsker rapporter om manglende robotter i den amerikanske region. Vores hold arbejder på at identificere årsagen og vil dele flere detaljer, efterhånden som undersøgelsen skrider frem.

2. 27. august 2026 kl. 18.53 UTCidentified

   Vi fandt ud af, at robotten blev forsinket. Robot logs er at indhente live data, og vi overvåger inddrivelse.

3. 27. august 2026 kl. 20.31 UTCmonitoring

   Logge er nu befolkning som forventet i realtid, og vi vil fortsætte med at overvåge ansøgningen.

4. 27. august 2026 kl. 21.57 UTCresolved

   Spørgsmålet er blevet løst, og logfiler er ved at fylde som forventet.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 25. august 2026 kl. 09.41 UTCidentified

   Vi har identificeret et problem, der påvirker løsningen implementering funktion i Studio Web i Japan-regionen, hvor løsning implementeringer kan mislykkes. Et fix er blevet udarbejdet og vil blive rullet ud snart. Vi vil give yderligere opdateringer, efterhånden som flere oplysninger bliver tilgængelige.

2. 25. august 2026 kl. 09.47 UTCmonitoring

   Fixet er blevet anvendt med succes i Japan-regionen, og problemet er blevet mildnet. Vi overvåger nøje tjenesten for at sikre, at Solution Deployment fortsætter med at fungere som forventet og vil levere yderligere opdateringer efter behov.

3. 25. august 2026 kl. 10.12 UTCresolved

   Problemet er blevet løst, og løsning implementering i Studio Web fungerer som forventet i Japan-regionen. Der er ikke observeret yderligere virkninger.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 25. august 2026 kl. 03.58 UTCinvestigating

   Vi undersøger et problem, der påvirker kunder, der bruger Insights i Singapore-regionen, hvor dashboards kan undlade at indlæse og vise timeout fejl. Vores hold arbejder på at identificere årsagen og vil give yderligere opdateringer, efterhånden som flere oplysninger bliver tilgængelige.

2. 25. august 2026 kl. 04.37 UTCmonitoring

   Spørgsmålet er blevet mildnet, og vi overvåger nøje Insights-tjenesten i Singapore-regionen for at sikre, at instrumentbrætter fortsat læsser som forventet.

3. 25. august 2026 kl. 04.53 UTCresolved

   Spørgsmålet er løst, og Insights-tjenesten i Singapore-regionen fungerer som forventet. Der er ikke observeret yderligere virkninger.

4. 4. september 2026 kl. 11.46 UTCpostmortem

   Kundeeffekt Mellem 25. august 2026 kl. 3: 42 om UTC og 25. august 2026 kl. 4: 53 om UTC oplevede kunder, der bruger Insights i Singapore-regionen, fejl ved indlæsning af Insights instrumentbrætter. Berørte brugere så dashboard sider tid ud eller undlader at indlæse, og server fejl blev observeret for relaterede serviceanmodninger. Den primære indvirkning var på Insights dashboard adgang, herunder diagrammer og advarsler. En relateret backend service også returneret server fejl under hændelsen, men dashboard adgang havde genvundet før endelig opløsning. # Root cause Hændelsen blev tilskrevet en regional Microsoft Service afbrydelse i Singapore påvirker infrastruktur, der anvendes af Insights service. Under afbrydelsen, Insights service var ude af stand til pålideligt at tjene dashboard anmodninger, hvilket resulterer i anmodning timeouts og server fejl. Der blev ikke foretaget ændringer på vores side. Tjenesten inddrives som Microsoft regionale forstyrrelse blev løst, og Microsoft efterfølgende rapporteret en Singapore regionale service problem på sin status side. Microsoft har anmodet om en formel grundanalyse for at bekræfte den specifikke fejlmekanisme og identificere eventuelle yderligere forebyggende eller afbødende foranstaltninger. # Detection Automatiseret helbredskontrol for Insights service opdagede problemet i august 25, 2026 kl. 03: 42 UTC. Kundens indvirkning blev bekræftet på svarbroen kort efter opdagelsen. # Response På August 25, 2026 på 3: 58 am UTC, vi lagt en offentlig status opdatering bemærke, at Insights dashboards i Singapore-regionen kan undlade at indlæse og vise timeout fejl. Under svaret, vores ingeniør team verificerede server fejl i automatiseret overvågning, forsøgte at få adgang til service diagnostik, og begyndte en inddrivelsesprocedure på den underliggende infrastruktur. I august 25, 2026 kl 4: 01 UTC, Insights service genvundet, mens inddrivelsesproceduren var i gang, og dashboard lastning blev valideret på tværs af flere testkonti. Den 25. august 2026 kl 4: 37 UTC, flyttede vi hændelsen til overvågning efter bekræftelse dashboards indlæses med succes. En relateret backend service inddrives i august 25, 2026 på 4: 49 am UTC, og hændelsen blev markeret i august 25, 2026 på 4: 53 am UTC. # Follow up 1. Anmoder om en rodløs årsag analyse fra Microsoft for Singapore regionale forstyrrelser påvirker indsigter dashboards loading problem.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 25. august 2026 kl. 03.44 UTCinvestigating

   Vi undersøger et problem, der påvirker kunder ved hjælp af Extended OCR funktionalitet i dokumentet Forståelse service i Singapore regionen. Vores hold arbejder på at identificere årsagen og vil give yderligere opdateringer, efterhånden som flere oplysninger bliver tilgængelige.

2. 25. august 2026 kl. 04.04 UTCmonitoring

   Spørgsmålet er blevet mildnet, og vi overvåger nøje tjenesten for at sikre, at den fortsat fungerer som forventet. Vi vil give yderligere opdateringer, efterhånden som flere oplysninger bliver tilgængelige.

3. 25. august 2026 kl. 04.59 UTCresolved

   Problemet er løst, og tjenesten fungerer som forventet. Der er ikke observeret yderligere virkninger.

4. 27. august 2026 kl. 03.42 UTCpostmortem

   Kundeeffekt Den 25. august 2026, Udvidet OCR anmodninger i dokumentet Forståelse service mislykkedes med 500 statuskode i Singapore-regionen i ca. 33 minutter, mellem 03: 08 og 03: 41 UTC. Årsagen var en Microsoft regional service afbrydelse i Singapore. Alle andre dokumenter forståelse funktionalitet var upåvirket, og ingen anden region blev påvirket. # Root cause Fejlen skyldtes en regional Microsoft Service afbrydelse i Singapore påvirker ressourcer, der anvendes af den udvidede OCR kapacitet. Der var ikke blevet foretaget ændringer på vores side, og Microsoft efterfølgende opdateret deres egen status side for at afspejle en Singapore regionale problem. Microsoft har anmodet om en formel grundlæggende årsag analyse. # Detection En automatisk indberetning for den dokumenttjeneste, der blev affyret den 25. august 2026 kl. 15.13. Advarslen blev straks anerkendt, og hændelsen blev erklæret customer- påvirke inden for få minutter. # Response Den on- call ingeniør undersøgte virkningen til Singapore regionen. Responderne udelukkede en nylig opdatering af tjenesten som årsag, da den samme opdatering var blevet udsendt til andre regioner uden tilsvarende virkninger, hvilket pegede på en regional afhængighed fiasko uden for vores infrastruktur. Fordi fejlen opstod i en opstrøms Microsoft-service, ingen formildende handling var tilgængelig eller kræves på UiPath side. Anmodninger begyndte at lykkes igen på 03: 41 UTC som Microsoft afhængighed inddrives. Responders holdt hændelsen åben for at kontrollere vedvarende opsving: ti minutter ren trafik blev bekræftet på 03: 51 UTC, hændelsen flyttet til Overvågning på 04: 04 UTC, og det blev løst på 04: 59 UTC efter fortsat stabilitet uden yderligere svigt. # Follow up 1. Forespurgte en rodårsag analyse fra Microsoft for Singapore regionale forstyrrelser påvirker udvidet OCR afhængigheder, herunder hvordan gentagelse kan forhindres.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 24. august 2026 kl. 10.43 UTCidentified

   Vi har identificeret årsagen til et problem påvirker et lille antal kunder ved hjælp af UiPath Apps forfattet fra Studio Web service på tværs af flere regioner. Vores hold er klar med et fix, og deployeringen er ved at begynde på tværs af de berørte regioner. Vi vil fortsat overvåge indsættelsen og levere yderligere opdateringer, efterhånden som fixet træder i kraft.

2. 24. august 2026 kl. 11.30 UTCmonitoring

   Løsningen er blevet anvendt med succes på tværs af alle berørte regioner, og problemet er blevet mildnet. Vi overvåger nøje tjenesten for at sikre, at fixet fortsætter med at fungere som forventet og vil give yderligere opdateringer efter behov.

3. 24. august 2026 kl. 11.55 UTCresolved

   Problemet er løst, og tjenesten fungerer som forventet. Der er ikke observeret yderligere virkninger.

4. 1. september 2026 kl. 11.47 UTCpostmortem

   Kundeeffekt Mellem den 19. august 2026 kl. 02: 33 UTC og den 24. august 2026 kl. 11: 30 UTC kunne en undergruppe af kunder ikke indlæse UiPath Apps-projekter, der var forfattet fra Studio Web. Berørte kunder oplevede fuldstændig manglende tilgængelighed af Apps projekter snarere end langsom eller forringet ydeevne. Virkningen var begrænset til et lille sæt kunder, hvis Apps service blev hostet i Japan regionen. Den samlede customer- påvirkende varighed var omkring 4 dage og 21 timer. # Root cause Roden årsag var en implementering mismatch mellem Studio Web og UiPath Apps. Den 19. august 2026 modtog Studio Web en planlagt opdatering i EU-regionen, der omfattede en rammeopgradering. Den tilsvarende UiPath Apps opdatering med rammen opgradering var endnu ikke blevet indsat til Japan skala enhed. En tidligere opdatering af Apps, der allerede var forenelig med den nye rammeversion, var blevet udsendt til alle regioner undtagen Japan, hvor indsættelsen var blevet udskudt af ikke-relaterede årsager. Som et resultat, Japan regionen kørte stadig en ældre Apps version, der ikke var kompatibel med den opdaterede Studio Web. # Detection Spørgsmålet blev rapporteret af en kunde gennem deres UiPath konto team på August 24, 2026 på 9: 36 am UTC. En hændelse blev åbnet kl 10: 21 UTC, og en offentlig status side hændelse blev erklæret inden for et minut. Eksisterende automatiseret overvågning opdagede ikke problemet, fordi det validerer matchede implementeringskombinationer; forbedring af detektering af blandede konfigurationer er en del af vores opfølgningsplan. # Response Inden for få minutter efter åbningen af hændelsen, vi identificeret deployering mismatch som roden årsag og besluttede at fremskynde deployeringen af den tilsvarende UiPath Apps opdatering til alle berørte regioner, tilpasse Apps med Studio Web version allerede bliver serveret til påvirket kunder. På 10: 43 am UTC, vi sendte en offentlig status opdatering bekræfter årsagen var blevet identificeret, og at fix blev indsat. Kl. 10: 52 var UTC undervejs for de resterende regioner, og flere regioner var allerede færdige. Kl. 11.30 bekræftede vi, at fixet var blevet sat ind på tværs af alle berørte regioner og markerede hændelsen afbødet. Klokken 11: 55 UTC, efter overvågning viste ingen yderligere virkning, hændelsen blev markeret løst. # Follow up 1. Tilføj automatisk alarmering på produktion telemetri for at opdage Apps belastning fejl korreleret med Studio Web version bliver serveret. 2. Implementere syntetisk overvågning, der regelmæssigt indlæser et Apps projekt forfattet fra Studio Web på tværs af repræsentative kundekonfigurationer og advarsler om svigt. 3. Juster release sekventering for stramt koblede Studio Web og Apps ændringer, så afhængige Apps opdateringer er fuldt implementeret til alle regioner, før den nyere Studio Web oplevelse når kundetrafik.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 21. august 2026 kl. 12.37 UTCmonitoring

   Der er gennemført et fix for det spørgsmål, der påvirker dokumentklassificering og ekstraktion til dokumentforståelse i USA, og vi overvåger i øjeblikket resultaterne.

2. 21. august 2026 kl. 13.36 UTCresolved

   Det spørgsmål, der påvirker dokumentklassificering og -ekstraktion til dokumentforståelse i den amerikanske region, er blevet løst. Efter en periode med overvågning, service er bekræftet sund og fungerer normalt.

3. 27. august 2026 kl. 03.46 UTCpostmortem

   Kundeeffekt Mellem 21. august 2026 kl. 11: 05 UTC og 21. august 2026 kl. 12: 18 UTC oplevede en undergruppe af kunder fejlslagne dokumentforståelse, herunder dokumentklassificering, ekstraktion og digitalisering. Den anslåede varighed af den delvise afbrydelse var 48 minutter. Virkningen var begrænset til kunder, der anvendte Document Forståelse i den amerikanske region. # Root cause Hændelsen var forårsaget af dokumentforståelse lagerdatabase fejl over konfiguration ind i en brudt tilstand under en forebyggende database scale-up operation. Scene- up blev indledt efter databasen nærmede sig sin lagergrænse. Under operationen, kunne den sekundære database ikke skaleres, forsøg på fjernelse fra failover konfiguration mislykkedes, og databasen platform udbyder måtte bryde replikation link. Dette efterlod failover konfiguration i en midlertidig utilgængelig tilstand, forårsager opbevaring og runtime tjenester, der afhænger af denne database til at mislykkes anmodninger. # Detection Hændelsen blev opdaget ved hjælp af en automatisk indberetning til dokumentforståelsen, som blev anerkendt den 21. august 2026 kl. 12: 10 UTC. # Response Før customer-impacing hændelse blev erklæret, den primære database scale- up blev afsluttet, og støtte fra databasen platform udbyder blev engageret for den sekundære database problem. Efter fejlindstillingen blev brudt, udforskede vi omdirigering af serviceforbindelsen, men kunne ikke identificere en sikker, umiddelbar vej til at gøre det i betragtning af tjenestens nuværende konfiguration. Service blev genoprettet ved at slette den usunde sekundære database og genskabe failover konfiguration. I august 21, 2026 kl 12: 37 UTC, fixet var blevet gennemført og overvågning var i gang. Klokken 13: 36 UTC, overvågning bekræftede tjenesten var sund, og hændelsen var markeret løst. # Follow up 1. Anmoder om en rodårsag analyse fra databasen platform udbyder til at afgøre, hvorfor den sekundære database ikke kunne skaleres, og hvorfor failover konfiguration oprensning krævede bryde replikation. 2. Opdatér databaselagring alarmering tærskler og routing, så advarsler er tildelt og handlet på tidligere, herunder en lav sværhedsgrad advarsel ved 75% brug og en højere sværhedsgrad advarsel ved 85% brug.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 19. august 2026 kl. 16.34 UTCinvestigating

   Vi undersøger et problem, der kan påvirke nogle kunder ved hjælp af Claude Sonnet 4.6 i agenter i den amerikanske region. Vores ingeniørteam arbejder aktivt på at forstå problemet og vil dele yderligere opdateringer, efterhånden som flere oplysninger bliver tilgængelige.

2. 19. august 2026 kl. 16.40 UTCmonitoring

   Vi har løst problemet. Vores engineering team er aktivt morgen og vil dele yderligere opdateringer som mere information bliver tilgængelig.

3. 19. august 2026 kl. 16.42 UTCmonitoring

   Vi har løst problemet. Vores ingeniørhold overvåger aktivt og vil dele yderligere opdateringer, efterhånden som flere oplysninger bliver tilgængelige.

4. 19. august 2026 kl. 16.55 UTCresolved

   Spørgsmålet er løst.

5. 31. august 2026 kl. 12.41 UTCpostmortem

   # Customer Impact Mellem 19. august 2026 kl. 13: 36 UTC og 19. august 2026 kl. 15: 53 UTC modtog en undergruppe af kunder fejl ved brug af Claude Sonnet 4.6 i Agenter. Anslaget varede omkring 2 timer og 17 minutter. Virkningen var for kunder, der brugte agenter i den amerikanske region. Der blev også observeret fejl for Claude Opus 4. 6 og Claude Opus 4. 5, som anvendes ved lavere volumen. --- # Root Cause Som en del af en planlagt infrastruktur migration, flyttede vi den platform service, ruter model anmoder om agenter på et nyt konfiguration leveringssystem, region for region. Den nye konfiguration kilde manglede routing poster for tre Claude modeller - Claude Sonnet 4.6, Claude Opus 4.6, og Claude Opus 4.5. Uden disse poster kunne tjenesten ikke løse en gyldig destination for anmodninger til disse modeller og afviste dem med fejl. Andre modeller var upåvirkede og fortsatte med at tjene normalt overalt. --- # Detection Spørgsmålet blev opdaget gennem kundeeskaleringer den 19. august 2026 kl. 02: 55 UTC - ca. 1 time og 19 minutter efter den første berørte anmodning. Vores ingeniørhold undersøgte spørgsmålet til specifikke Claude modeller og begyndte at undersøge. Public status kommunikation begyndte kl. 15: 08 UTC. Vores alarmovervågning er baseret på aggregerede fejlrater. Selv om næsten alle anmodninger til de tre berørte modeller var mislykkede, udgjorde disse modeller en lille del af den samlede trafik i regionen, så det samlede signal krydsede ikke vores varslingstærskelværdier, og spørgsmålet blev ikke rejst automatisk. Dette er den detektionsforskel, der behandles i nedenstående opfølgning. --- # Response Klokken 15: 25 UTC blev den ufuldstændige konfigurationskilde identificeret som årsagen, og en rettelse blev startet. Klokken 15: 47 UTC, implementering af fix var i gang, og tjenesten blev aktivt overvåget som ændringen rullede ud. Ved 15: 59 UTC, service logs bekræftet problemet blev reduceret, og ved 4: 00 UTC blev fejlprocenten bekræftet på 0%. Hændelsen blev afhjulpet kl. 16.40 UTC, og fuld opløsning blev erklæret kl. 16.55 UTC efter fortsat overvågning og kundebekræftelse af, at tjenesten fungerede som forventet. --- # Follow - Up Infrastrukturmigrationen er gennemført på tværs af alle regioner og routing konfiguration nu trækker fra en enkelt kilde, fjerne den manglende match, der forårsagede denne hændelse, så det kan ikke gentage. Der indføres automatisk kontrol for løbende at kontrollere alle støttede modeller i alle regioner, så en utilgængelig model detekteres og alarmeres øjeblikkeligt - også i lavtrafikregioner.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 18. august 2026 kl. 17.54 UTCinvestigating

   Vi er ved at undersøge rapporter om et udfald, der påvirker fejlene i ekspressionsevalueringer i forbindelse med HITL 's parametre for produktion af asgentiske orchestratron hos brugere i lokalsamfundet i Europa. Indvirkning: Brugerne kan være ude af stand til at udføre ITL-opgaver Næste opdatering: Vores hold arbejder på at forstå årsagen og omfanget og vil dele opdateringer som tilgængelig.

2. 18. august 2026 kl. 20.31 UTCidentified

   Vi har identificeret årsagen til et udfald, der påvirker ekspressionsvurderinger i forbindelse med HITL 's parametre for output for Agentic Orchestration hos brugere i lokalsamfundet i Europa. Impact: Brugere vil opleve fejl, når de har et udtryk ved hjælp af HITL opgave output parameter. Næste opdatering: Vores hold arbejder på at forstå årsagen og omfanget og vil dele opdateringer som tilgængelig.

3. 18. august 2026 kl. 21.45 UTCidentified

   Vi har identificeret løsningen, og beslutningen er i gang. Næste opdatering: Vores hold arbejder på fix og vil dele opdateringer som tilgængelig.

4. 18. august 2026 kl. 22.53 UTCmonitoring

   Vi har indsat fixet og overvåger beslutningen. Næste opdatering: Vores hold overvåger opløsningen og vil dele opdateringer som tilgængelig.

5. 18. august 2026 kl. 23.25 UTCresolved

   Udbruddet er blevet løst, og Agentic Orchestration er fuldt operationel. Påvirkning: Ingen igangværende brugerpåvirkning.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 18. august 2026 kl. 12.08 UTCidentified

   Vi har identificeret den egentlige årsag til et problem i Studio Web, hvor ressourcekonfigurationsskærmen til ændring af ressourcetattributter ikke indlæses. Vi sender et fix.

2. 18. august 2026 kl. 13.05 UTCidentified

   Implementering af fixet er i gang. Vi vil levere yderligere opdateringer, efterhånden som indsættelsen skrider frem.

3. 18. august 2026 kl. 14.06 UTCidentified

   Løsningen er blevet verificeret og bliver rullet ud på tværs af alle resterende regioner. Vi overvåger deployeringen og opsvinget. Tak for din tålmodighed.

4. 18. august 2026 kl. 17.03 UTCidentified

   Udrulningen skrider frem som forventet i de resterende regioner. Vi fortsætter med at overvåge indsættelsen. Tak for din tålmodighed.

5. 18. august 2026 kl. 18.12 UTCmonitoring

   Udrulningen skrider frem som forventet i de resterende regioner. Vi fortsætter med at overvåge indsættelsen. Tak for din tålmodighed.

6. 18. august 2026 kl. 19.05 UTCresolved

   Udrulningen er afsluttet, og spørgsmålet bør løses.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 18. august 2026 kl. 05.32 UTCinvestigating

   Vi er i færd med at undersøge et problem, der påvirker Fællesskabets regnskaber, hvor nyoprettede enheder kan tage ca. en time for at blive vist i Studio Web. Ingen data går tabt, og eksisterende enheder er uberørte.

2. 18. august 2026 kl. 06.48 UTCinvestigating

   Vi fortsætter med at undersøge spørgsmålet og arbejder på at identificere den grundlæggende årsag og genoprette normale behandlingstider.

3. 18. august 2026 kl. 08.44 UTCinvestigating

   Vi fortsætter med at undersøge spørgsmålet om en delmængde af lejere i Europa, USA og Japan, hvor nyoprettede enheder kan tage længere tid end forventet at dukke op i Studio Web. Ingen data går tabt, og eksisterende enheder er uberørte.

4. 18. august 2026 kl. 09.37 UTCidentified

   Vi har identificeret årsagen og arbejder på en resolution om spørgsmålet om en undergruppe af lejere i Europa, USA og Japan. Tak for din tålmodighed.

5. 18. august 2026 kl. 11.19 UTCmonitoring

   Spørgsmålet er blevet mildnet, og vi forventer, at behandlingstiden snart bliver normal igen. Vi overvåger opsvinget nøje. Tak for din tålmodighed.

6. 18. august 2026 kl. 11.57 UTCresolved

   Problemet er løst, og behandlingstiden er blevet normal igen. Tak for din tålmodighed.

7. 27. august 2026 kl. 03.51 UTCpostmortem

   Kundeeffekt Mellem august 18, 2026 på 5: 11 am UTC og august 18, 2026 på 11: 57 am UTC, nyoprettede enheder i en delmængde af UiPath Cloud lejere kunne tage længere tid end forventet at dukke op i Studio Web. På tidspunktet for den indledende vurdering dukkede nyoprettede enheder op med en forsinkelse på ca. en time. Kunder i Europa, USA og Japan blev berørt. Selve oprettelsen af en enhed fortsatte med succes, ingen data blev tabt, og eksisterende enheder var upåvirket. # Root cause Spørgsmålet var forårsaget af en usædvanlig stor mængde af aktiver-skabelse anmodninger fra en lejer. Disse anmodninger genereret flere begivenheder end vores backend entity- indeksering service kunne behandle med samme hastighed, skabe en forsinkelse i begivenhedsbehandling kø. Fordi Studio Web er afhængig af denne service til at vise nyoprettede enheder, nye enheder dukkede først op efter backlog blev behandlet. # Detection Spørgsmålet blev identificeret af vores ingeniør team ved enhed behandling latency alarm, og en hændelse blev erklæret på 5: 11 am UTC den 18 august 2026. Ved 5: 23 am UTC, analyse bekræftet den sidste behandlede enhed var omkring en time bagud. # Response Kl. 5: 32 udsendte vi en første kundeopdatering, der bemærkede forsinket synlighed for nyoprettede enheder i Studio Web. Ved 6: 07 på UTC, undersøgelse identificeret usædvanligt høj asset- creation trafik fra en lejer, og på 7: 03 på UTC, vi justerede database ressourcer til den berørte tjeneste for at hjælpe behandlingen inddrive. Kl. 7: 59 UTC var kilden til den høje efterspørgsel holdt op med at sende forespørgsler, og køen begyndte at dræne. Kl. 9: 59 UTC startede vi en datasynkroniseringsproces for den berørte lejer, og kl. 10: 31 UTC fjernede vi de problematiske begivenheder i kø, så normal behandling kunne indhente hurtigere. Køens dybde faldt fra 95.000 genstande ved 8: 34 UTC til 1.000 genstande ved 11: 44 UTC. Hændelsen blev markeret afbødet ved 11: 19 UTC efter behandling genvundet væsentligt, og løst ved 11: 57 UTC efter behandling tid vendte tilbage til normal. # Follow up Genudløser datasynkronisering for den berørte lejer og overvåge indtagelse, indtil lejerens data er bekræftet konsekvent. Forbedre enheden håndtering i indeksering backend, så backlog ikke vil hobe sig op på denne sats.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 14. august 2026 kl. 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 kl. 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 kl. 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 kl. 10.58 UTCresolved

   En storm af anmodninger på en en sjældent brugt model funktion i IXP Communications Mining forårsaget en prøve løkke til at låse ned synkrone anmodninger i den bredere IXP API. Dette fik anmodningerne til at mislykkes med 500 'erne, da arbejderne havde travlt med langtrukne anmodninger. Automatisk skalering hurtigt nåede det maksimale kapacitet og opløsning blev kun gjort ved at anvende en kode rettelse, der indførte strenge timeouts til den bidragende API anmodning. Anmodningen storm startede omkring 15: 10 UTC og detekteret en 15: 15 UTC med automatiske alarmer. Resolutionen blev bekræftet omkring 18: 15 UTC. Hændelsen blev oprindeligt fejlagtigt tilskrevet kun kunden gør storm af anmodninger, men blev senere opdaget at have påvirket en bredere vifte af brugere. Total effekt begrænset til en håndfuld brugere i USA.

2. 18. august 2026 kl. 21.25 UTCpostmortem

   # Customer Impact Den 12. august 2026, mellem ca. 15: 10 og 18: 15 UTC, Communications Mining (IXP) brugere i USA region oplevede periodisk anmodning svigt. Hændelsen var begrænset til en af regionens deployeringsenheder, hvor brugerne på det oplevede svigt i sprængninger på fem til ti minutter, med op til 5-7% af deres anmodninger mislykkes med 5xx fejl på toppen. Mellem brister tjenesten fungerede normalt, genprøvede anmodninger generelt lykkedes, og ingen data gik tabt. # Root Cause En storm af anmodninger til en sjældent brugt API funktion, der beregner maskin- læring forudsigelser på efterspørgslen faldt sammen med gentagne omskoling af den ønskede model. Hver omskoling ugyldiggjort cached forudsigelser, gør hver anmodning til en multi-minutters beregning. API 'en placerede ingen tidsbegrænsning for, hvor længe en anmodning kunne vente på denne beregning, så disse langløbende anmodninger gradvist besatte al anmodningskapacitet, hvilket fik ikke-relaterede anmodninger til at mislykkes. Automatisk skalering nåede sin maksimale kapacitet hurtigt og kunne ikke kompensere. # Detection Automatiseret overvågning opdagede fejlene ved 15: 15 UTC, omkring fem minutter efter virkningen begyndte, og tilkaldte on- call ingeniør. Hændelsen blev oprindeligt kun tilskrevet den klient, der genererer anmodningen storm, men kunderapporter og yderligere undersøgelse viste, at et bredere sæt af brugere blev påvirket i løbet af fiasko udbrud. # Response On- call ingeniør sporet fejlene til den ubegrænsede ventetid i on-demand forudsigelse sti. Service kapacitet blev gentagne gange genoprettet ved automatisk instans udskiftning, mens en kode fix blev udviklet. Løsningen er en streng timeout på den bidragende anmodning, så det mislykkes hurtigt uden at påvirke andre anmodninger, og blev sendt til den ramte region på ca. 18: 00 UTC, og opløsning blev bekræftet på 18: 15 UTC. # Follow - Up 1. Den strenge timeout og loading-slippe fix er blevet gjort permanent og frigivet til alle regioner (afsluttet August 13, 2026). 2. Evaluere per- klient grænser for on- demand forudsigelse beregning, så en enkelt klients brug ikke kan degradere den delte API.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 10. august 2026 kl. 14.11 UTCinvestigating

   Vi undersøger forringet ydeevne påvirker Frontend Services i Document Forståelse på tværs af GXP East US Region. Impact: Brugere kan bemærke timeouts, når adgang til UI i GXP US. Næste opdatering: Yderligere opdateringer vil blive leveret som mere information bliver tilgængelig.

2. 10. august 2026 kl. 14.25 UTCresolved

   Problemet er blevet løst, og udførelsen af Front- End Service i Document Forståelse er vendt tilbage til forventede niveauer efter forringet ydeevne påvirket UI i GXP East US Region. Påvirkning: Ingen igangværende brugerpåvirkning.

3. 19. august 2026 kl. 06.14 UTCpostmortem

   Kundeeffekt Mellem 10. august 2026 kl. 13: 21 UTC og 10. august 2026 kl. 14: 03 UTC oplevede en undergruppe af kunder forringet ydeevne og timeouts, når de fik adgang til dokumentforståelse brugergrænsefladen, som giver design- tid erfaring, i den forsinkede USA-region. Automatiseringen af dokumentbehandlingen blev ikke påvirket. # Root cause Under en manuel implementering fra en allerede eksisterende opbygning af tjenesten bag Document Forståelse brugergrænsefladen til den forsinkede amerikanske region, vores implementering proces forflyttet version-id for den service, der bliver indsat. Grænsefladen til dokumentforståelse kræver, at dets støtteressourcer er tilgængelige under samme versionsidentifikator som den anvendte tjeneste. Fordi ibrugtagningsprocessen ændrede denne identifikator, kunne grænsefladen ikke finde de nødvendige ressourcer, hvilket fik det til at blive utilgængelige eller time out. # Detection Vi blev opmærksomme på spørgsmålet kort efter, at indsættelsen var afsluttet, gennem manuel verifikation som en del af den manuelle indsættelse checkliste. En automatiseret indberetning fulgte snart, udløses kl. 13.28 UTC den 10. august 2026. # Response Efter at have identificeret årsagen til den manuelle implementering, begyndte vores ingeniørhold at implementere en korrigeret opdatering med de nødvendige ressourcer til rådighed. Samtidig var operationsteamet engageret til at udføre en manuel rollback af indsættelsen. Rollback blev afsluttet kl 14: 03 UTC, genoprette adgang til designtid oplevelse. På 14: 11 UTC, vi offentliggjort en offentlig status opdatering, der angiver forringet ydeevne og mulige timeouts i Document Forståelse brugergrænseflade for den forsinkede amerikanske region. Ved 14: 15 UTC, den korrigerede opdatering var afsluttet, og grænsefladen blev bekræftet som indsat med en korrekt ny version og arbejder. Kl 14: 25 UTC, hændelsen blev markeret løst, og den offentlige status side blev opdateret for at bekræfte, at Document Forståelse interface ydeevne var vendt tilbage til forventede niveauer. # Follow up 1. Vi reducerer den tid, der er nødvendig for at genoprette en tidligere version af tjenesten, så inddrivelse fra en mislykket implementering er hurtigere. 2. Vi gør forbedringer af den manuelle implementering for at forhindre en fremtidig situation, ved at validere de nødvendige ressourcer eksistens som en forudsætning.

Automatisk oversat fra den officielle hændelsesopdatering.

1. 8. august 2026 kl. 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 kl. 13.01 UTCidentified

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

3. 8. august 2026 kl. 14.14 UTCidentified

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

4. 8. august 2026 kl. 15.30 UTCidentified

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

5. 8. august 2026 kl. 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 kl. 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 kl. 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 kl. 21.14 UTCresolved

   Mellem 06- 08- 2026 10: 00 UTC og 06- 08- 2026 13: 00 UTC var nogle organisationer i den amerikanske region ude af stand til at fuldføre dokument indtagelse. Et lille antal søgeanmodninger i samme region var også langsomme eller tidsbegrænsede. Spørgsmålet var forårsaget af en kapacitetsbegrænsning, der påvirkede behandlingen af indtagelse i USA. Normal præstation blev genoprettet kl 13: 00 UTC. Vi har overvåget de berørte miljøer siden genopretning og bekræfter, at problemet er fuldt afbødet. Indtagelse anmodninger, der mislykkedes i løbet af dette vindue blev ikke genprøvet automatisk og vil skulle gen- indsendes. Der kræves ingen handling til søgning.

2. 13. august 2026 kl. 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.

Automatisk oversat fra den officielle hændelsesopdatering.