121 Uipath incidents · Nisan 2026 — official updates, affected components, duration and resolution details.
27 Ekim'de, 14:35 ve 16:08 UTC arasında, Avrupa bölgesinde Belge Anlayışı, jeneratif çıkarma, jeneratif sınıflandırma ve otovalidasyon etkileyen kısmi bir kesinti yaşadı. Kök nedeni üçüncü bir parti depolama sağlayıcısıyla bir bağlantı sorunuydu. Connectivity restore edildi ve normal olarak 16:08 UTC'den bu yana sınıflandırmanın çalıştığını doğruladık.
Resmî olay güncellemesinden otomatik olarak çevrilmiştir.
Şu anda içgörüler ve otomasyon ops hizmetlerinin varlığını etkileyen bir sorunu araştırıyoruz. Ekibimiz, alt yatan nedeni tanımlamak ve normal operasyonları restore etmek için gerekli adımları belirlemek için durumu aktif olarak değerlendirmektedir. Ek güncellemeler daha fazla bilgi mevcut olduğu gibi sağlanacaktır.
Otomasyon Ops ile ilgili sorun çözüldü. Şu anda Erişilebilirlik hizmeti sorununun azaltılmasını bekliyoruz. Ayrıca güncellemeler mevcut oldukları gibi paylaşılacaktır.
Singapur, Japonya, İsviçre, Kanada, Hindistan, İngiltere, Avrupa, Amerika Birleşik Devletleri, BAE, Güney Kore ve Avustralya Bölgesi'nde içgörüler ve diğer bölgelere başvuru yapıyoruz
Sorun çözüldü ve tüm hizmetler artık normal olarak çalışıyor.
Resmî olay güncellemesinden otomatik olarak çevrilmiştir.
26 Ekim'de, 10:20 ve 17:30 UTC arasında, Otomasyon Bulut Robotları (VM) makine operasyonlarını etkileyen kısmi bir kesinti yaşadı. Bu pencerede, başlangıç, duraklama veya teslim VM makineleri gibi eylemler tamamlanmamış olabilir ve bu makinelerde planlanan işler gecikmiş veya hatalı olabilir. Sebep, alt temel altyapı kaynaklarının bir alt kümesi üzerinde yanlış yapılandırmadır. Ekibimiz sorunu tespit etti, yapılandırmayı düzeltti ve makine operasyonlarının 17:30 UTC'den beri normal çalıştığını doğruladı. Yanlış yapılandırmanın nasıl tanıtıldığı ve bir recurrence önlemek için kontroller ekliyoruz. Hiçbir eylem sizin tarafınızda gerekli değildir. Hala bu pencereden başarısız veya sıkı işler görürseniz, lütfen onları yeniden deneyin ve problem devam ederse iletişim desteği ile iletişime geçin.
Resmî olay güncellemesinden otomatik olarak çevrilmiştir.
23 Ekim'de 20:42 ve 21:19 UTC arasında, Avrupa'daki bazı orkestra müşterileri yavaş cevaplar ve aralıklı hatalar gördü. Bu, robotun varlık, süreç kuyruk öğeleri ve iş statüsünü alması çağrısında bulundu. Bazı istenmeyen işler bu süre zarfında başarısız olabilir. Sebep veritabanının kaynakları sınırlarına ulaşan yükte aniden artış oldu. Veritabanı kapasitesini ekledik ve performans 21:19 UTC'den beri normale döndü. Bu pencerede başarısız olan müşteriler onları yeniden başlatmaları gerekebilir.
Resmî olay güncellemesinden otomatik olarak çevrilmiştir.
Avustralya bölgesinde barındırılan müşteriler için IXP'yi etkileyen bir sorunu tespit ettik. 10:24 UTC'den beri, Gemini 2.5 Flash modelini kullanan talepler bölgede başarısız oluyor. Diğer modeller etkilenmez. Müşteri verileri sadece Avustralya'da işlemeye devam ediyor. Hizmeti restore etmek için Google ile çalışıyoruz
Bir düzeltme yapıldı ve hizmet geri dönüyor. Tam iyileşme sağlamak için sistemi izliyoruz. Ek güncellemeler yakında paylaşılacaktır
İlk kurtarmadan sonra, hizmet tekrar mezun oldu. Bir karara karşı araştırıyoruz ve çalışıyoruz. Mevcut oldukları gibi daha fazla güncelleme sağlayacağız.
Google Support ile temasa geçtik ve sonunda araştırmaya başladılar. İzlemeye devam edeceğiz ve onların olduğu gibi güncellemeleri paylaşacağız.
Gemini 2.5 Flash trafiği üzerinde gelişmeleri gözlemliyoruz. Google'dan olası bir düzeltmeyi izliyoruz.
Sorun Google'dan çözülür.
## Müşteri Etkisi 22 Ekim'de 10:24'te 2026 UTC ve 2226'da 6:04 pm UTC'de belge işleme talepleri kapasite hatalarıyla başarısız oldu. Etki yaklaşık 7 saat ve 40 dakika sürdü. Bu bölgede belge çıkarma iş akışlarını kullanan müşterilerin alt kümesi etkilendi. Geçici bir kesinti girişimi sırasında, bazı ekstraksiyon talepleri kısaca geri alındı, ancak kelime seviyesindeki alıntı ve üretilen sayfa metni de başarısız olana kadar bozuldu. ## Root neden Kök nedeni, eş zamanlı bakım sırasında bir sağlayıcının bölgesel ağ kesintisi idi. Bu, sağlayıcının model koruma ortamında ciddi bant genişliğine neden oldu, bu da arka uç sistemlerinin etkilenen bölgede Gemini 2.5 Flash ve Gemini 3.5 Flash'a güvenilir bir şekilde hizmet etmesi gerekiyordu. # # Tespit Sorun, Avustralya bölgesinde Gemini 2.5 Flash'ta hızlanan hataları tespit eden otomatik uyarı ile tespit edildi. Mühendislik ekibimiz, etkilenen isteklerin sürekli başarısız olduğunu ve bir cevap koordine etmeye başladığını doğruladı. # # Response 1:40 UTC'de, Gemini 2.5 Flash trafiğini aynı bölgede veri ikametini korumak için rotaladık. İlk telgraf bu değişiklikten sonra kapasite hataları göstermedi, ancak 2:10 pm UTC, İkizler 3.5 Flash da kapasite hataları geri döndü, bu yüzden geri çekilme artık uygulanabilir değildi. 2:05 pm UTC'de, ilgili belge işleme yollarını ayarladık, bu yüzden alıntı ve sayfa metin nesli aynı in-bölgedeki geri dönüşleri kullanırdı; bu ayarlama yaklaşık 2:09 pm UTC'de tamamlandı. İndükten sonra da başarısız olduktan sonra, routing değişikliği tekrar ettik ve 4:28 pm UTC trafiği beklenen Gemini 2.5 Flash yolunda geri döndü. 5:38 pm UTC, telemetri Gemini 2.5 Flash başarı oranını artırmayı gösterdi. 6:04 UTC'den sonra, daha fazla kapasite hataları gözlemlendi ve sonraki istekler başarılı oldu. ## Takip 1. Etkilenen trafik modellerini kullanarak etkilenen bölge için ayrılmış model kapasite değerlendirmesini tamamlayın. 2. Belge işleme müşterilerinde yeniden deneme ve gerileme davranışı, sağlayıcının kapasite başarısızlıkları sırasında tekrarlama azaltmak için.
Resmî olay güncellemesinden otomatik olarak çevrilmiştir.
Yaklaşık 11:17 UTC'den bu yana, birden çok bölgede müşteriler UiPath Agents ve Solutions Management ile ilgili sorunlar yaşadı. Yeni işler Pending statüsünde kalabilir ve çalışan ajanlar işlem escalations veya araç sonuçları beklerken gecikmeleri yaşayabilir. Sorunu araştırıyoruz ve bir karara doğru çalışıyoruz.
Sorun azaltıldı. Etkilenen hizmetleri istikrar sağlamak ve bu işin başladığını ve çözüm dağıtımlarının normal olarak çalıştığını doğrulamak için izliyoruz.
Bu olay çözüldü. 15 Ekim'de 11:15 ve 12:45 UTC arasında, bir iç yapılandırma sorunu, birden çok bölgede UiPath hizmetleri arasında teslim edilmekten bazı olayları engelledi. Sorun değişimin geri çekilmesiyle çözüldü ve yeni aktivite normalde işleniyor. Bu pencere sırasında veya ilerlemede bazı çalışmalar dikkat gerektirebilir: Ajans: Action Center görevleri veya otomasyon aracı sonuçları için bekleyen Agents sıkışı kalabilir. Orkestrator'dan başlayan işler de sıkı veya zaman ortaya çıkabilir. - Maestro: Kullanıcı görevleri için bekleyen süreçler görev tamamlandıktan sonra yeniden başlatılamaz. Uygulamaları: Queue item durumları modası geçmiş olabilir ve kuyruk öğe tamamlanması ile tetiklenen eylemler yönetilmeyebilir. - Herkes için Autopilot: Otomasyon sonuçlarını bekleyen konuşmalar durdurulabilir. - Doküman Anlayışı ve Context Grounding: Ekstraksiyon için bekleyen Otomasyonlar ve ajanlar, geçerlilik veya indeksleme askıya alınabilir. - Bütünleştirme Hizmeti: Stok olayları beklenen süreçleri veya bildirimleri tetikleyemez. - Çözümler ve Stüdyo Web: Çözüm yüklemeleri, yüklemeler, yayınlar, dağıtımlar ve bu pencere sırasında başlatılan doğrulamalar başarısız veya zamanlanmış olabilir. Bu operasyonları yeniden deneme sorunu çözebilir. Bozukluk için özür dileriz ve sabrınız için teşekkür ederiz.
**Müşteri etkisi** 15 Ekim 2026, 11:15'ten 12:50 UTC'ye (yaklaşık 1 saat ve 35 dakika), UiPath bulut hizmetleri arasında yapılan bazı olaylar teslim edilmedi. Tüm ticari bulut bölgelerindeki müşteriler etkilendi. Bu pencere sırasında: - Yeni ajan Pending statüsünde kalabilir. Bir araç sonucunda bekleyen ajanlar, bir insan escalation, belge çıkarma veya bağlam zeminleme özgeçmişi olmayabilir. - Bir otomasyona başlayan herkes konuşmaları için Konuşma ajanları ve Autopilot, sonucu almamış olabilir. - Bir kullanıcı görevinde bekleyen Maestro süreçleri, görev tamamlandıktan sonra ilerlememiş olabilir ve Entegrasyon Servis Bağlantı olayları tarafından başlatılan süreçler başlatılamaz. - Ekstra öğe statüsüne gösterilen veya tepki gösteren uygulamalar eski bilgileri gösterebilir. - Çözüm yüklemeleri, yüklemeler, yayınlar ve dağıtımlar başarısız olabilir veya zaman dışarı çıkabilir. - Pencerede yapılan bazı kullanıcı, grup ve klasör değişiklikleri tüm hizmetlere yayılmamış olabilir. 12:50 UTC'den sonra çalışmaya başladı. Robot iş infazı, kuyruklar ve Orkestrasın içinde ele alınması normalde çalışmaya devam etti. **Root neden ** İç servis konfigürasyonunun yeni bir mekanizmaya iletilmesi, müşteriler üzerinde hiçbir etkisi olmayan bir değişiklik. Bu değişiklik olay teslim servisine uygulandığında, üretilen konfigürasyon gerekli bir değeri eksikti. Bu olmadan, hizmet, birçok ürün entegrasyonlarına maruz kaldı ve sessizce olayları teslim etmeyi bıraktı. Çünkü değişim aynı zamanda tüm üretim bölgelerine ulaştı, her bölge etkilendi. **Deteksiyon** Sorun 11:51 UTC'de tespit edildi, etki başladıktan yaklaşık 35 dakika sonra, Pending statüsünde kalan ajan işlerinde uyarıldığında. Çözüm dağıtımlarının zamanlamalarının raporları takip edildi ve 12:12 UTC'de bir olay ilan edildi. **Response** 11:51 UTC'deki ilk tespitin ardından, yapılandırma değişikliği tespit edildi ve geri dönüş 12:00 UTC'de başladı. 12:14 UTC'de bir ilk geri dönüş tamamen teslimat yapmadı. Ekip daha sonra yeni yapılandırma teslimat sürecini durdurdu ve önceki yapılandırmayı restore etti. Etkinlik teslimatı 12:40 UTC'de iyileşmeye başladı ve tüm bölgelerdeki tam iyileşme 12:50 UTC'de onaylandı. Mümkün olduğu yerde, etkilenen iş devam edebileceği için kaçırılmış olayları tekrarlıyoruz. ** Takip Et 1. Etkilenen hizmet için yeni yapılandırma işlemi durduruldu ve yapılandırma doğru şekilde üretilinceye kadar duraklayacak. 2. Herhangi bir çevreye uygulanmadan önce gerekli değerlerin için yeni teslimat mekanizması tarafından üretilen doğrulama. 3.Bir zamanlar tüm bölgelere yönelik olarak, dağıtıma yönelik olarak sürekli olarak tüm bölgelere yapılan değişiklikler. 4. Olayların normalde aldıkları bir ürün entegrasyona teslim edilmeyi durdurması için izlememizi geliştirin. 5. Bir kesinti sırasında kaçırılmış ve redeliver olaylarımızı iyileştirme yeteneğimizi geliştirin.
Resmî olay güncellemesinden otomatik olarak çevrilmiştir.
ABD bölgesindeki bazı müşteriler, yaklaşık 11:20 ile 11:45 UTC arasında gözlemlenen, robot girişinde gecikmeler yaşadı. Sorun çözüldü ve ingestion normale döndü. Sabrınız için teşekkür ederiz.
## Müşteri Etkisi Yaklaşık 15 Ekim 2026 arasında 11:20 pm UTC ve yaklaşık 15 Ekim 2026 11:45 pm UTC, ABD'deki bazı müşteriler UiPath Orkestrası'nda robot girişlerinde gecikme yaşadılar. Robot logları etkilenen dönemde güncel değildi. Etki yaklaşık 20 dakika sürdü. ## Root neden Olay sırasında, robot logunu enjekte eden 13 hizmet örneklerinden 2 tanesi, etkinliği engestion hizmetine bağlamayı gözlemledi. Sadece ingestion servisine istekleri başarısız oldu ve sadece bu iki durumda. Bu, etkilenen müşteriler için geciken log verileri tamamlamak için bazı robot giriş isteklerine neden oldu. Sadece bu iki örneğin ingestion servisine olan bağlantının neden olay sırasında belirlenmedi. Ekip, alt yatan nedeni tanımlamak için etkilenen örneklerden gelen logları gözden geçirmeye karar verdi. Bulut sağlayıcımızdan sınırsız bir altyapı sorunu olduğuna inanıyoruz. # # Tespit Sorun, 15 Ekim 2026'da yaklaşık 11:33 UTC'de otomatik bir uyarıyla tespit edildi ve etkilenen iki hizmet örneğinden gelen istisnaları gösteren telgrafla teyit edildi. # # Response Tespit ettikten sonra, telemetri sadece iki hizmet örneği istisnalar yaratıyordu. Yanıtlar bu iki sağlıksız örneği hizmetten kaldırdı ve yedek örnekleri otomatik olarak başladı. İlk uyarının yaklaşık 20 dakika içinde - yaklaşık 11:53 UTC tarafından - telemetri kurtarma ve sentetik izleme kontrolleri geçiyordu. Tüm hizmet örneklerinin daha geniş bir yeniden başlaması, ancak yapılmadığı gibi, takım ilk önce kök nedenini anlamadan ilerlememelidir. ## Takip 1. Etkilenen servis örneklerinden gelen girişlerin bir post-denincit incelemesi, konu ile ilgili altyapı olduğunu ve daha fazla ayrıntı için bulut altyapı sağlayıcısıyla takip ediyoruz. 2. Soruşturmanın daha fazla bulguları varsa bir güncelleştirme yayınlanacak.
Resmî olay güncellemesinden otomatik olarak çevrilmiştir.
6:50 UTC ile başlamak, Hindistan ve İngiltere dışında tüm bölgelerin uygulamaları ve kodlanmış uygulamaları etkileyen küresel bir kesinti yaşadık. Outage çözüldü ve hizmetler tamamen operasyonel. Etkisi: Sürekli kullanıcı etkisi yok.
6:50 UTC ile başlamak, Hindistan ve İngiltere dışında tüm bölgelerin uygulamaları ve kodlanmış uygulamaları etkileyen küresel bir kesinti yaşadık. Outage çözüldü ve hizmetler tamamen operasyonel. Etkisi: Sürekli kullanıcı etkisi yok.
## Müşteri Etkisi 06:38 UTC ve 07:21 UTC on 14 2026, UiPath Apps, Kodd Apps ve onlara bağlı çözümler 11 bölgede başarısız oldu: Avrupa, Amerika Birleşik Devletleri, Topluluğu, Japonya, Singapur, Avustralya, Kanada, Güney Kore, İsviçre, BAE ve gecikmiş ABD ortamı. Hindistan ve Birleşik Krallık bölgeleri etkilenmedi. İsteklerin yaklaşık yüzde 2'si, bölgeye bağlı olarak 0.6 ve yüzde 5 arasında başarısız oldu. Etkilenen kullanıcılar uygulamaları yükleyemez, geri sunucu hataları veya yavaş cevaplar talep eder. Servis pods'un yeniden başlatılması gereken bölgelerde, uygulamalar yaklaşık sekiz dakika kadar ulaşılamazdı. Yanıt süreleri her bölgede 07:40 UTC tarafından normale döndü. Zaten yayınlanan uygulamaların çoğu küçük veya hiçbir şey fark etti. App tanımları tarayıcıda 24 saate kadar önbelleklenir, uygulama verileri bu veritabanından ziyade Data Service ve Orkestrasıtor'dan gelir ve hizmet zaten tutulan veritabanı bağlantılarını kullanmaya devam etti. Başarısız olan talepler yeni bir veritabanı bağlantısına ihtiyaç duyuyor: Tasarımcıyı veya uygulama listesini açıyor, henüz önbellekli değil, Uygulamalarda saklanan belgeleri ve görüntüleri indirin ve kaydetmek. ## Root neden 06:38 UTC'de, veritabanı erişimi yeni bir bölgesel dağıtım için ayarlandığında, Uygulama hizmetinin değiştiği veritabanı kullanıcısının şifresi değiştirildi. Bu kullanıcı, tüm etkilenen bölgelerin üretim veritabanı kümeleri tarafından paylaşılır, bu nedenle tüm bunlara bir kez uygulanan değişiklik. Operasyon hizmetleri hala önceki şifreyi tuttu ve artık yeni veritabanı bağlantıları açamadı. Hindistan ve Birleşik Krallık bölgeleri bu haçlı kullanmıyor ve etkilenmedi. Değişim, yeni bölge için ayrı bir veritabanı kullanıcısı oluşturmak anlamına geliyordu. Bunun yerine, tüm bölgelerin paylaştığı mevcut kullanıcının şifresi değiştirildi. Veritabanı bildirimleri için değişim sürecimiz, mevcut bir kişiyi değiştirmekten yeni bir credential yaratmadı ve birçok küme ve bölgenin bir haçlı değişikliğin nasıl etkileyeceğini kontrol etmedi. Bölgeler arasında paylaşılan tek bir veritabanı kullanıcısıyla birlikte, bu, bir bölge için multi-bölge kesintisine neden olmak için tasarlanmış bir değişikliğe izin verdi. # # Tespit İç izlememiz ilk uyarıyı 06:41 UTC'de yükseltti, ilk başarısızlıklardan üç dakika sonra ve 06:46 UTC tarafından takip edilen her etkilenen bölge için uyarılar. 06:50 UTC'de on-call mühendisi, her üretim kümesinin veritabanı tarafından reddedildiğini ve olay sürecine başladığını doğruladı. # # Response 07:05 UTC'de önceki şifre restore edildi ve doğrulama hataları her yerde durdu. Çoğu bölge otomatik olarak bağlanır. Değil bölgelerde, servis pods yeniden başlatılmış veya yeniden çalıştırılmıştır: 07:21 UTC ve İsviçre'de 07:30 UTC tarafından gecikmedi. İstek başarısızlıkları 07:21 UTC'de durduruldu, yanıt süreleri 07:40 UTC tarafından sıraya geri döndü ve olayın 07:43 UTC'de çözülmesine kadar izlemeye devam ettik. ## Takip Bunu tekrar olmasını önlemek için: - Veritabanı bilgilerini oluşturmak ve döndürmek için tanımlanmış bir prosedür tanıtarak, kümelerin ve bölgelerin şifreli olduğunu ve daha yaygın olarak uygulanmadan önce bir bölgede doğrulanan bir rollout. - Her bölge için en az öncelikli veritabanı kullanıcıları ayırmak, böylece bir bölgedeki bir değişiklik başka etkilemez. - veritabanı sahiplerinin aynı veritabanı hatası bir zamanlar birkaç bölgede tespit edildiğinde, bireysel bölgesel uyarılardan manuel olarak tırmanmaya güvenmek yerine. - Yenilenen veritabanı bilgilerini yeniden başlatmadan almak için enabling hizmetleri ve kimlik doğrulama başarısızlığından sonra tekrar bağlantı kurmak.
Resmî olay güncellemesinden otomatik olarak çevrilmiştir.
Şu anda birden çok bölgede UiPath Cloud hizmetlerini etkileyen kesintiyi araştırıyoruz. Kullanıcılar etkilenen bölgelerde barındırılan hizmetlere erişemiyor. Sonraki güncelleme: Ek bilgi mevcut olduğu gibi paylaşılacaktır.
Bu konuyu araştırmaya devam ediyoruz.
Bir düzeltme uygulandı ve sonuçları takip ediyoruz. Sorun Doküman Anlayışı ile sınırlıydı, Bilgisayar Vizyon, Semantic Proxy, Autopilot Studi, IXP. Hizmetlerin tamamen kurtarıldığı bir kez başka güncellemeyi paylaşacağız.
Bir düzeltme uygulandı ve sonuçları takip ediyoruz.
Bu olay, IXP, Doküman Anlayışı, Bilgisayar Vizyonu, Semantic Proxy ve Autopilot dahil olmak üzere birkaç ML bağımlı servisinin yenilenmesinin ardından çözüldü. Hizmet kurtarma etkilenen bölgelerde ilerleme gösterdi ve otomatik uyarılar, sertifika genişletmesini önceden tespit etmek ve gelecekte benzer kesintileri önlemek için yapılandırıldı. Sabrınız ve anlayışınız için teşekkür ederiz.
## Müşteri Etkisi 13:37 ve 14:40 UTC 13 2026 Ekim'de, birden çok bölgede müşteriler IXP yapılandırılmış Belgeler, IXP İletişim Madencilik ve Dokümanları kullanamadı. Geliştiriciler için Bilgisayar Vizyon ve Autopilot, aynı makine öğrenme hizmetlerine bağlı olarak da başarısız oldu. Etkilenen müşteriler, "500 Internal Server Hatası" yanıtları veya zamanında başarısız olduğunu gördü, IXP açık olmayan projeler ve bilgisayar Vision faaliyetleri çalışan otomasyonlarda başarısız oldu. Servis yaklaşık 1 saat boyunca kesintiye uğradı. Hiçbir müşteri verileri kaybedilmedi. # # # Root Cause Olay, bu hizmetlere güvenli bağlantıları kurmak için kullanılan süresiz bir güvenlik sertifikasına neden oldu. Sertifika otomatik bir süreçtir. Bu süreç artık başarılı bir şekilde uygulanmadı ve başarısızlıklar bir uyarı yükseltmedi, bu yüzden sertifika sona ermeden önce değiştirildi. Etkilenen hizmetlere güvenli bağlantılar 13:37 UTC'den reddedildi. # # Tespit Otomatik izleme, 13:40 UTC'de hata ve eksik trafik konusunda uyarıya başladı ve olay 13:54 UTC'de ilan edildi. Bitmiş sertifika 14:00 UTC'de tespit edildi ve ilk durum sayfası güncelleme 14:03 UTC'de yayınlandı. Hiçbir uyarı, sertifikanın expiry'ye yaklaştığını ve otomatik yenilemenin tekrarlanan başarısızlıklarının kendi takıma rapor edilmedi, bu yüzden sorun sadece bir kez müşteri etkilendi. # # Response 14:06 UTC'de ekip sertifikanın sona erdiğini doğruladı çünkü otomatik yenileme başarısız oldu. 14:18 UTC, yenileme işlemi için yeni bir haçlı yayınlandı. Yenileme 14:19 UTC'de manuel olarak başladı ve 14:33 UTC'de tamamlandı ve 14:37 UTC tarafından her müşteri tarafından yenilenmiş sertifikaya hizmet etmek için doğrulandı. Trafik yaklaşık 14:40 UTC tarafından normal seviyelere geri döndü. İzleme sürecinden sonra, olay 15:19 UTC'de çözüldü. ## Follow-Up Gelecekte benzer olayları önlemeye yardımcı olmak için aşağıdaki gelişmeleri yapıyoruz: - Bu sertifikalardan herhangi birinin önceden tahmin edilmesi expiry'ye yaklaştı. - Otomatik yenileme başarısız olduğunda kendi takımlarını onaylama. - Bu hizmetlere güvenli bağlantıların başarısız olduğu kadar uyarıları ekleyin. - Sertifika yenileme sürecinin mülkiyetini ve güvenlerini güçlendirmek.
Resmî olay güncellemesinden otomatik olarak çevrilmiştir.
Robot infaz günlüklerinin Orkestrada göstermediğini araştırıyoruz. Tam kapsamı ve kök nedenini belirlemek için çalışıyoruz.
Bu konu çözüldü. Robot yürütme logları senkronize edilir ve tekrar Japonya Orkestra için görünür. Sabrınız için teşekkür ederiz.
## Müşteri Etkisi Japonya'daki müşteriler için yaklaşık% 6'sı 2026'da saat 9'da saat 2026 ve 10:45 UTC arasında, Japonya bölgesindeki müşteriler için yaklaşık% 6'sı Orkestrasında görünmedi. İş infazı ve diğer tüm orkestra işlevselliği etkilenmedi. Eksik girişler, konu düzeltildikten sonra Orkestrasında görünür hale geldi. ## Root neden Robot logları 32 bölüme bölünmüş bir kuyrukta yerleştirilir ve bir ingestion servisi her bölümü okur ve orkestracı için girişleri depolar. 9 Ekim'de, Japonya'daki en büyük hizmet, bir hata yapmadan 32 bölümden 2 tanesini okumayı bıraktı. Bu bölümlere girişler kuyrukta tutuldu ama depolanmadı, bu yüzden Orkestrada görünmediler. İzlememiz hizmetin tamamını kontrol etti, her bölüm değil, bu yüzden konu otomatik olarak tespit edilmedi. # # Tespit Sorun müşteri raporları aracılığıyla tespit edildi. 13 Ekim'de 10:13 UTC'de bir olay ilan ettik ve 10:32 UTC'de bir durum sayfasını yayınladık. # # Response Yaklaşık 10:41 UTC'de ingestion servisini yeniden başlattık ve tüm bölümleri okumaya devam ettik. kuyrukta tutulan loglar daha sonra işlendi ve Orkestra'da görüldü. Olay 10:57 UTC'de çözüldü. ## Takip * Herhangi bir bölüm okumayı durdurulduğunda bu uyarıları takip ediyoruz, bu yüzden bu tür bir konu birkaç dakika içinde tespit edilir.
Resmî olay güncellemesinden otomatik olarak çevrilmiştir.
ABD'de Maestro için HITL görev oluşturma başarısızlıklarını etkileyen kesinti raporları araştırıyoruz. Etkisi: Kullanıcılar HITL görevleri oluşturamaz. Sonraki güncelleme: Takımlarımız nedeni ve kapsamı anlamak için çalışıyor ve mevcut olarak güncellemeler paylaşacaktır.
ABD'de Maestro için HITL görev oluşturmanın nedenlerini tespit ettik ve sorunu azaltmak için çalışıyoruz. Etkisi: Kullanıcılar HITL görevleri oluşturamaz. Sonraki güncelleme: Takımlarımız sorunu azaltmak için çalışıyor ve mevcut olarak güncellemeler paylaşacaktır.
HITL görevini ABD'de yapılandıran ve sorunu azaltmak için çalışan SLA zamanlayıcıları ile Maestros için bir kesintiye yol açıyoruz. Etkisi: Kullanıcılar, HITL görev SLA zamanlayıcıları ile Maestros içinde HITL görevleri oluşturamaz. Sonraki güncelleme: Takımlarımız sorunu azaltmak için çalışıyor ve mevcut olarak güncellemeler paylaşacaktır.
ABD'de yapılandırılan HITL görev yaratılmasını etkileyen sorun için düzeltme tamamen ortaya çıktı. HITL görev yaratımı normale döndü.
## Müşteri Etkisi 2026-10-05 9.30 PM UTC - 2026-10-07 3.30 AM UTC, Maestro BPMN ve Case müşterileri, HITL düğümlerini yapılandırılmış bir görev Timer ile kullanıyor HITL sahnesinde, 4xx ile. ABD ve Avrupa'daki müşteriler arasında yaklaşık 30 örnek tespit edildi, bu hiçbir çalışmayla engellendi. ## Root neden SLA'nın başlangıç ve son ölçüler dahil olmak üzere bir nesneyi yapılandırın, SLA'nın zamanlayıcısı ve SLA ihlalinin sonucu. Müşteriler bunu HITL node üzerinde Maestro tasarımcısında yapılandırır. Sonuç yanlışlıkla tasarım yüzeyindeki önemsiz değildi, ancak bir SLA yapılandırması bir sonuç olmadan devam etmedi ve iş hissi yapmaz. Action Center backend ekibi, eksik bir sonuçla bir null SLA nesnesi durumunda kötü bir istek (400) atmak için geçerli bir işlem ekledi. Bu, Node'de Başlangıç/Bitki kriterleri ekleyen müşterileri etkiledi, ancak bir sonuç yapılandırmadı. Daha önce çalışan instances 400s ile başarısız oldu ve yeniden başlayamadı. # # Tespit Bir müşteri, bu konuyu takımla içselleştirmiş olan Maestro Engineering SME'e bildirdi. Maestro ekibi bu başarısızlığı inceledi ve ABDI için giderek artan sayıda başarısızlık gözlemledi ve birkaç diğer kiracıları loglar aracılığıyla, onları Action Center ekibine katılmaya yönlendirdi. # # Response Maestro ekibi, müşteriden E-posta yoluyla rapor aldı ve bazı ilk soruşturma yaptılar ve bunun ardından, Action Center SME meşguldü, konu daha düşük ortamlarda yeniden üretildi ve tüm etkilenen bölgelere geri döndü. Bu, içsel olarak yeniden beslenmekte ve yeniden ortaya çıkan tüm örneklerle çözüldü. ## Takip 1. Bu senaryo için insan incelemesini sağlamak için tüm çapraz servis kodbase yüzeyleri arasında geçerlilik ekleyin. 2. Bu sorunu daha hızlı tespit etmek için yerinde gerekli izleme ve entegrasyon testleri ekleyin
Resmî olay güncellemesinden otomatik olarak çevrilmiştir.
Doğu ABD'de Otomasyon Bulut Bölgesinde bir alt kuruluş etkileyen sürekliliği ve hataları araştırıyoruz. Etkilenen kullanıcılar, Orkestrası UI'deki sayfaların yüklenmediğini görebilirler (örneğin, Jobs sayfası “Bir hata meydana geldi), ve robot işlemleri kuyruk işlemleri ve seans gibi geçici olarak sona erebilir. Daha kısa sürede daha fazla bilgi olarak bir güncelleme sağlayacağız.
Doğu ABD bölgesinde etkilenen veritabanı altyapısına kapasite artırımı yaptık ve hata oranları ve gecikme normal seviyelere geri döndük. Daha kısa sürede daha fazla bilgi olarak bir güncelleme sağlayacağız.
Doğu ABD bölgesinde ve hata oranlarında ve geç kalmışlık normal seviyelere geri döndük.
## Müşteri Etkisi 7 Ekim 2026'da yaklaşık 13:00 UTC ve 18:15 UTC arasında, ABD'deki müşteriler, Orkestrator'da geçici hataları ve yavaş cevaplar yaşadı. Etkilenen kullanıcılar orkestra sayfaları yüklenemez, örneğin Jobs sayfası “Bir hata meydana geldi,” ve kuyruk işlemleri gibi robot operasyonları ve seans geçici olarak tükenebilir. Orkestrator'a bağlı diğer UiPath hizmetleri de bu dönemde daha yavaş cevap veya hataları görmüş olabilir. ## Root neden Her biri sık kullanılan orkestra operasyonları, her çalışan robotun yaptığı rutin durum kontrolü de dahil olmak üzere veritabanı içinde paylaşılan kısa ömürlü bir kaynak üzerinde yoğunlaşmıştır. Bu bölgede eş zamanlı robot aktivitesinin hacmi büyüdükçe, talepleri, işlerini tamamlamak yerine paylaşılan kaynağa erişmek için kuyruklamaya başladı. Etkisi genel bir yavaşlamadan ziyade seçiciydi: Bu kaynağı kullanan işlemler gecikti, diğerleri normalde çalışmaya devam ederken. Çünkü veritabanının işlemcisi, hafıza ve depolama kullanımı tüm normal aralıklarda kaldı, rutin kapasite izleme bir problem belirtmedi. # # Tespit Otomatik izlememiz, yaklaşık 35 dakika müşteri etkisinin başlangıcını tespit etti ve mühendislerimiz olay sırasında alt kategoriyi tanımladı. Çünkü bu bir kapasite eksikliğinden ziyade bir içerik sorunuydu ve tüm kapasite göstergeleri normaldi, artan veritabanı kapasitesi onu çözmeyi beklemiyordu ve ekip bunu uygulamadan önce alternatifleri araştırdı. Bu değerlendirme mitigation'u geciktirdi. # # Response Mühendislik ekibimiz etkilenen veritabanının kapasitesini artırdı. Yanıt süreleri ve hata oranları hemen normale döndü ve olayı kapatmadan önce hizmetin istikrarlı olduğunu doğrulamaya devam ettik. * 13:00: Hata oranları ve yanıt süreleri ABD bölgesinde müşteriler için yükselmeye başlar. * 13:36: Otomatik izleme bozulmayı tespit eder ve on-call mühendislik ekibini bilgilendirir. * 13:36 - 17:29: Mühendisler araştırıyor. Tüm standart veritabanı kapasite göstergeleri - işlemci, hafıza ve depolama - boyunca normal aralıklarda kalır, bu nedenle neden rutin izlemeden belirgin değildir. * 17:29: Resmi bir olay ilan edilir ve tam yanıt ekibi meşguldür. 17:38 Bir kamu hesabı [UiPath Status] (http://status.uipath.com/) \(Investigating\) * 17:31 - 17:43: Ek veritabanı kapasitesi etkilenen bölge için düzenlenmiştir. * 18:00: Hata oranları, yanıt süreleri ve gecikme süresi normal seviyelere geri döner. * 18:11: Durum sayfası İzleme ve Müşteri Etkisi sona erdirmek için güncellendi. * 19:06: Olay sürekli izleme onaylarından sonra kapalıdır. ## Takip Bunu tekrar olmasını önlemek için: * Etkilenen işlemleri değiştirmek, böylece artık paylaşılan kaynağa bağlı değildir. Bu, tüm etkilenen sistemlere çıktı ve olayı yaratan durumu büyük ölçüde azalttı. * Bu sistemlerde ayrıntılı veritabanı izleme, bu nedenle bu içerik kategorisi daha sonra olduğu gibi görünür. * Uyarımızı geliştirmek, böylece bu tür gerçek bir bozulma rutinden açıkça ayırt edilebilir, kendini kayıt dışı varyasyondan ve daha hızlı yükselmektedir.
Resmî olay güncellemesinden otomatik olarak çevrilmiştir.
Avrupa'daki Orkestra için dışlanmış işlevsellik ya da kullanıcı semptomu ile ilgili raporları araştırıyoruz. Etkisi: Kullanıcılar robot loglarının ve / veya arama / logların görüntülenmesini bekleyebilirler. Hiçbir giriş kaybolmayacaktır. Sonraki güncelleme: Takımlarımız nedeni ve kapsamı anlamak için çalışıyor ve mevcut olarak güncellemeler paylaşacaktır.
Avrupa'daki Orkestra için robot loglarının azaltılmasının sebebini tespit ettik. Etkisi: Kullanıcılar robot loglarının ve / veya arama / logların görüntülenmesini bekleyebilirler. Hiçbir giriş kaybolmayacaktır. Sonraki güncelleme: Takımlarımız nedeni ve kapsamı anlamak için çalışıyor ve mevcut olarak güncellemeler paylaşacaktır.
Avrupa'daki Orkestralar için robot loglarının verimini azalttık. Etkisi: Kullanıcılar robot loglarının ve / veya arama / logların görüntülenmesini bekleyebilirler. Hiçbir giriş kaybolmayacaktır. Sonraki güncelleme: Takımlarımız nedeni ve kapsamı anlamak için çalışıyor ve mevcut olarak güncellemeler paylaşacaktır.
Avrupa'daki Orkestralar için robot loglarının verimini azalttık. Etkisi: Kullanıcılar robot loglarının ve / veya arama / logların görüntülenmesini bekleyebilirler. Hiçbir giriş kaybolmayacaktır. Sonraki güncelleme: Takımlarımız nedeni ve kapsamı anlamak için çalışıyor ve mevcut olarak güncellemeler paylaşacaktır.
## Müşteri Etkisi Bununla birlikte, yaklaşık 15:45 UTC ve 18:45 UTC arasında, Avrupa, Avustralya ve Japonya bölgelerinde barındırılan müşteriler, son robot loglarını Orkestrator'da göremedi. Etki penceresi sırasında yazılan Logs, Jobs ve Logs görüşlerinde veya Robot Logs API'sinde görünmedi ve gün sadece geçici olarak mevcut olan yaklaşık 03:00 UTC'den daha eski giriş yaptı. Etki penceresi bölgeye farklılık gösterdi: Avustralya: 18:35 UTC'ye yaklaşık 15:45 UTC Avrupa: yaklaşık 16:35 UTC to 18:00 UTC Japonya: 18:30 UTC'ye yaklaşık 16:45 UTC İş infazı, kuyruklar, tetikler ve diğer tüm orkestra işlevselliği etkilenmedi. Hiçbir robot logları kayboldu. Etki penceresi sırasında üretilen Logs toplandı ve bir kez daha ortaya çıktı. ## Root neden Biz, mağazalardan orkestra robot logları olan Elasticsearch servisinin planlanan bir yükseltmesini yapıyorduk. Yükseltme mavi / yeşil bir yaklaşım kullanır: Mevcut olan bir grubun yanında yeni bir küme oluşturulur, veriler bir yedeklemeden geri getirilir, yeni logların başladığı boru hattı. Etkilenen bölgelerde, trafik geçişi, veri geri yüklemeden önce yükseltmeyi çalışan mühendis tarafından onaylanmıştır ve ingestion yakalama tamamlandı, bu da yükseltme prosedürümüzden sapmadır. Bu bir insan hatasıydı. Sonuç olarak, orkestracı henüz yeni veriler içermediği bir kümeden robot loglarını okuyordu, ancak yeni loglar toplanmaya devam ederken henüz kümeye hizmet eden taleplere indekslemedi. Hata yakalanmadı çünkü dağıtım aracımız veri tamlığı doğrulamak için operatöre güveniyor ve veri geri yükleme ve trafik geçişi arasındaki düzeni uygulamaz. # # Tespit Sürekli olarak test işlerini yürüten sentetik izlememiz ve girişlerinin geri döndüğünü, etkilenen bölgelerdeki eksik logları tespit ettiğini ve uyarıları yükseltti. Mühendislik ekibimiz, in-progress yükseltmesi ile uyarıları ilişkilendirdi, bir olay ilan etti ve bir statü sayfası bildirimini yayınladı. # # Response Mühendislik ekibimiz trafikten önceki Elasticsearch kümelerine geri döndü ve bu da hemen tüm robot loglarına erişimi restore etti, bu da etki penceresi sırasında üretilenlere dahil. Her etkilenen bölgede sentetik izleme yoluyla iyileşmeyi doğruladık ve olayın yaklaşık 18:45 UTC'de çözülmesinden önce izlemeye devam ettik. Yeni kümelerin yükseltilmesi arka planda devam ediyor. Trafik sadece veri geri yükleme tamamlandıktan sonra onlara taşınacak ve ingestion tarihe kadar doğru onaylanmıştır. ## Takip Bunu tekrar olmasını önlemek için: - Dağıtım hattını değiştirmek, böylece trafik geçişi, yeni kümedeki veri geri yüklemesine ve giriş girişi tamamen doğrulanamaz. - Boru hattına otomatik bir geri dönüş adımı ekleyin, bu yüzden trafik bir geçişten sonra bir sorun tespit edilirse birkaç dakika içinde önceki kümeye geri dönebilir.
Resmî olay güncellemesinden otomatik olarak çevrilmiştir.
BAE'deki hizmetler için bozulan performansı gözlemliyoruz
Şu anda bu konuyu araştırıyoruz.
Sorunu üçüncü taraf servis sağlayıcı ile bir ağ yönlendirme problemi olarak tespit ettik, UAE'de barındırılan hizmetlerimiz için bağlantıyı etkiliyoruz. Karardaki üst düzey sağlayıcımızla çalışıyoruz ve burada ilerlemeyi güncelleyeceğiz.
Bu sorun için bir düzeltme üzerinde çalışmaya devam ediyoruz.
Bağlantıyı takip ediyoruz ve bu sayfayı bir kez istikrar onaylandı.
Daha fazla sorun için izlemeye devam ediyoruz.
Olay çözüldü.
## Müşteri Etkisi 12:38 PM UTC ve 2:51 PM UTC, a subset of customers in the UAE region experienced failures when accessing UiPath cloud services. Olay yaklaşık 2 saat ve 13 dakika sürdü. Etkilenen hizmetler, **cloud.uipath.com**, **account.uipath.com**'ye erişim içeriyordu. BAE'de barındırılan hizmetler. Müşteriler zaman aralıkları, başarısız kimlik doğrulama, sıfırlama bağlantıları veya sunucu hataları ile karşılaşabilirler. ## Root neden Kök nedeni, üçüncü taraf altyapı sağlayıcısında bölgesel bir ağ yönlendirme başarısızlığıydı. UAN bölgesinden belirli dış ağlara giden ağ yollarının bir alt kümesi, **cloud.uipath.com** ve **account.uipath.com** - trafiği teslim etmeyi bıraktı. Etkilenen hizmetlerden gelen yeni bağlantı girişimleri yanıt almadı, talepleri zamanından beri. Mühendislik ekibimiz UiPath servis konfigürasyonunu, uygulama düzeyinde politikayı ve nedenleri olarak bağlantı kapasitelerini yönetti. Altyapı sağlayıcısı, aynı ağ yolunda birden fazla müşteri etkileyen bilinen bir konu kabul etti. # # Tespit Sorun otomatik izleme yoluyla tespit edildi. Yaklaşık 12:40 UTC - başarısızlık başladığından yaklaşık iki dakika sonra - soruşturma, UiPath endpoints'in başarısız olduğunu doğruladı. # # Response 1:20 pm UTC'ye göre, mühendislik ekibimiz başarısızlığın belirli ağ yolları ile sınırlı olduğunu doğruladı, diğer destinasyonlar ulaşılabilirken. Geçerlilik UiPath-side routing değişiklikleri, içerik teslimat yapılandırma değişiklikleri, uygulama seviyesi politikası ve bağlantı kapasite sorunları yönetti. Yüksek hacimli bir destek vakası üçüncü taraf altyapı sağlayıcısı ile açıldı. 1:50 UTC'de, sağlayıcı birçok müşteriyi etkileyen bilinen bir sorunu kabul etti. Ekibimiz etkilenen ağ yollarından kurtarmaya devam etti ve trafik geri döndükçe hizmet sağlığını doğrulamaya devam etti. 2:51'de UTC, kurtarma kontrolleri, UiPath trafiğinin etkilenen içerik teslimat yolları aracılığıyla normal seviyelere geri döndüğünü doğruladı. Otomatik sağlık kontrolleri ve servis ölçümleri doğrulanmış kurtarma ve UAN'daki hizmetler operasyonelydi. ## Takip 1. Altyapı sağlayıcısının doğrulayıcı eylemini takip ediyoruz ve bölgesel routing başarısızlığı için kök neden analizine sebep oluyoruz. 2. Etkilenen bölgeye benzer üçüncü taraf ağ kesintilerine karşı dayanıklılık güçlendirmek için inceleme yapıyoruz.
Resmî olay güncellemesinden otomatik olarak çevrilmiştir.
Yaklaşık 15:05 UTC'den bu yana, ABD bölgesindeki bazı müşteriler Bulut Robotları üzerinde çalışan işleri her zamankinden daha uzun sürebilir veya Pending eyaletinde kalabilirler. Kendi robotlarınızdaki işler etkilenmez ve başka bölgeler de değildir. Büyük nedeni bulduk ve normal iş işleme geri yüklemek için çalışıyoruz. Zaten kuyruklanmış olan işler kaybolmaz ve konu bir kez işlenecektir. 60 dakika içinde başka bir güncelleme yayınlayacağız.
ABD bölgesinde Bulut Robotları üzerinde geciken işler için bir düzeltme yaptık ve işler normal olarak yeniden başlıyor. Gecikmiş olan işler artık işleniyor. Hizmetin istikrarlı olduğundan emin olmak ve 60 dakika içinde başka bir güncelleme yayınlayacağız.
Sorun üzerinde daha fazla çalışmadan sonra, ABD bölgesinde Bulut Robotları üzerinde işler artık normal olarak başlıyor. Daha önce gecikmiş olan işler işleniyor. Hizmeti izlemeye devam ediyoruz ve bir kez daha bir güncelleme yayınlayacağız.
Bu konu çözüldü. 15:05 ve 16:39 UTC arasında ABD bölgesinde Bulut Robotları üzerinde işler başlamak veya Pending eyaletinde kalmak için yavaştı. İşler normalde 16:39 UTC'den beri başlıyor ve bu süre zarfında geciken işler şimdi işlendi. Bu rahatsızlıktan özür dileriz.
## Müşteri Etkisi 15:00'ten 16:38 UTC 2026-10-02'te, ABD bölgesindeki Bulut Robotları işleri her zaman 16:20 UTC'nin tepesinde 22 dakikaya kadar sürdü. Orkestra mevcut kaldı, hiçbir iş kayboldu, başka bir bölge etkilenmedi. Küçük bir müşteri, daha önceki işler beklediğinde yeni gönderimlerde geçici bir limit hatası aldı. # # Tespit Otomatik uyarılar 15:07 UTC'de kovuldu, etki başladıktan yedi dakika sonra. ABD bölgesinde kontroller yaklaşık 15:32 UTC'den başarısız oldu ve olay yanıtı başladı. ## Root neden 14:55 UTC'de bir müşterinin iş akışı normal oranını yaklaşık 20 kez göndermeye başladı. İşlerini kabul eden hizmet, veritabanında per-customer concurrency count in the database and updates it under a database kilit on each job start and end. Bu oran müşterinin kaydı için kilit kuyruğu, zamanlanana kadar büyüdü. Bekleme güncellemeleri bölgedeki tüm müşteriler için işe başlayan ortak işçi havuzunu işgal etti, bu yüzden her müşterinin işlerini geride bıraktı. Bu mekanizma, bir müşterinin yükünün şişenck haline geldiğini fark etmek anlamına geliyordu. # # Response Takım, aşırı kabul yolunu ve bunun arkasındaki iş yükü tespit etti. 15:46 UTC'de ilk konfigürasyon değişikliği yanlış kaydı hedef aldı ve hiçbir etkisi yoktu. 16:10 UTC, müşterinin iş tipinin veritabanı kilitinden muaf olduğunu ve yaklaşık 16:20 UTC'de etkilendiğini kabul etti. Başlangıç süreleri bir saniyenin altında yaklaşık 13 saniyeden düştü ve 18 dakika içinde yaklaşık 5200 iş yeniden başladı. İş 16:38 UTC'de normaldi. Müşterinin tetikleyicisi 16:40 UTC'de müşteri ile kapatılmıştır. ## Takip Veritabanı sınırlı oranı, ekranlı yüksek performans oranı limitli mekanizma ile değiştirilir, bu yüzden bir müşteri yükü iş diğerleri için başlatamaz. Değişim tamamlandı, aynı yükte pre-prodüksiyonda test edildi ve çıktı.
Resmî olay güncellemesinden otomatik olarak çevrilmiştir.
Şu anda BAE bölgesinde İçgörü portalını etkileyen bir kesintiyi araştırıyoruz. Bu bölgedeki kullanıcılar portala erişemez veya başarısız sayfa yükleri yaşayabilir. Ekibimiz, nedeni ve restore hizmetini tanımlamak için aktif olarak çalışmaktadır. Daha fazla bilgimiz olduğu sürece başka bir güncelleme sağlayacağız.
Bir masyon yolunu tespit ettik ve BAE bölgesinde bir geri dönüş başlattık. Kullanıcılar, bu çalışma devam ederken İçgörü portalı ile sürekli erişim sorunlarını deneyimlemeye devam edebilir. Döndükten sonra başka bir güncelleme sağlayacağız.
BAE bölgesindeki İçgörü portal şimdi geri dönüşümüzü başarıyla takip ediyor. Stabiliteyi doğrulamak için hizmeti izlemeye devam ediyoruz ve sorunun tamamen çözüleceğine emin olduğumuz bir son güncelleme sağlayacaktır.
BAE bölgesindeki içgörüler portal artık normalde geri dönüşleri takip ediyor. Anahtar portal işlevselliğini doğruladık ve hizmetin sağlıklı kaldığını doğruladık. Bu olay şimdi çözüldü.
## Müşteri Etkisi ** Ekim 1, 2026**, UiPath **UAE bölgesinde** hizmeti mevcut değildi. Yaklaşık **23:40 1 Ekim'de saat 1'e 00:39 UTC 2**'den itibaren kullanıcılar, 10 saniye sonra bir hatayla başarısız olabilir. Bölgedeki yeni kiracılar için içgörüler sağlamak da başarısız oldu. Bu kesinti yaklaşık **59 dakika sürdü. BAE bölgesinde diğer UiPath hizmetleri ve diğer tüm bölgelerdeki içgörüler etkilenmedi. Hiçbir müşteri verileri kaybedilmedi. # # # Root Cause The outage, planlanan bir İçgörü salıvermede sevk edilen bir değişiklikten kaynaklanıyordu. Değişim, **minimum TLS \ (Transport Katman Security\) sürüm**'i BAE bölgesinde TLS 1.2'den **TLS 1.3**'ye yükseltti. UiPath ağ geçidi, müşteri trafiğinin bu uç noktaları TLS 1.2 üzerinden bağlar. Son nokta TLS 1.2'yi kabul etmeyi bıraktıktan sonra, ağ geçidi artık onlara güvenli bir bağlantı açamadı. Müşteri zamanlarını talep eder ve hataları iade eder, ancak İçgörü uygulama kendisi sağlıklı kalır. Değişim sadece BAE bölgesine uygulanır, bu yüzden başka bir bölge etkilenmemiştir. # # Tespit Sorun, **UiPath'in otomatik sentetik izleme** tarafından tespit edildi, ki bu sürekli olarak çoklu konumlardan erişilebilirliği test ediyor. İlk başarısız sağlık kontrolü 23:40 UTC'de kaydedildi. Otomatik uyarılar dakikalar içinde kovuldu ve on-call mühendislik ekibi araştırmaya başladı. # # Response Mühendislik ekibi, BAE bölgesinde etkilenen sadece İçgörüleri doğruladı. Uygulama normalde koşuyordu, ancak müşteri trafiği buna ulaşamadı. Ekip, ağ geçidi ve Insights arasındaki güvenli bağlantı adımını takip etti ve serbest bırakılması tarafından uygulanan TLS ayarıyla bağlantılıydı. Yaklaşık **00:38 UTC**, ekip önceki minimum TLS versiyonunu geri aldı \(TLS 1.2\) etkilenen uç noktaları üzerinde. Sentetik sağlık kontrolleri hemen geçti ve **00:41 UTC** BAE bölgesinde tüm İçgörü kontrolleri sağlıklıydı. Ekip tam stabiliteyi doğrulamak için izlemeye devam etti. ## Follow-Up Gelecekte benzer olayları önlemek için aşağıdaki adımları atıyoruz: * **Başlangıçtan TLS değişikliğini yeniden uygulamadığı için gelecekteki dağıtımlar yeniden uygulanmaz, ağ geçidi TLS 1.3 sonuna kadar. * **Gücüklüğe karşı güncel bağlantı güvenlik değişiklikleri, üretime uygulanmadan önce önceden üretim ortamında.
Resmî olay güncellemesinden otomatik olarak çevrilmiştir.
1 Ekim'e kadar yaklaşık 1:30 PM UTC, bazı Agents, hem düşük kodlu hem de kodlanmış ajanlar da dahil olmak üzere tüm bölgelerdeki başarısızlıklar yaşamaya başladı, gemileri kullanarak -3.1-pro-pwer ve gpt-4o-2024-05-13. Bu modeller aynı zamanda ajan tasarımı sırasında seçim için de kullanılabilir. Aktif olarak bir düzeltme üzerinde çalışıyoruz ve çalışıyoruz.
Sorunu tespit ettik ve bir düzeltme dağıtıyoruz. Etkilenen modelleri kullanan ajanlar başarısızlıkları deneyimlemeye devam edebilir ve modeller ajan tasarımı sırasında seçim için kullanılamaz, ancak dağıtım tamamlandığında.
Bu sorunun neden olduğuna ve etkilenen modellerin tekrar mevcut olduğunu doğruladık. Bazı ajanlar, örneklerin yenilenmesi sırasında geçici başarısızlıkları deneyimlemeye devam edebilir. Gemi tasarımını ve infazı gemi-3.1-pro-pauer ve gpt-4o-2024-05-13 için izlemeye devam ediyoruz.
## Müşteri Etkisi 1 Ekim 2026'da, 14:31'den 19:40 UTC'ye kadar, Gemini 3.1 Pro Preview ve GPT-4o (2024-05-13) dahil olmak üzere bazı büyük dil modelleriyle yapılandırılan ajanlar mevcut değildir. Aynı modeller, ajanları tasarlarken model listesinden kayboldu. Diğer modelleri kullanan ajanlar etkilenmedi. ## Root neden Bir özellik bayrağı çevrildi, Ajans hizmetine modelleme isteği için bir operasyon kodu göndermeye neden oldu. Bu, bu özel işlemin temel ajan model listesine karşı olduğu modellerin listesine neden oldu. Operasyon modeli listesi başlangıçta kendi modelinizin (BYOM) konfigürasyonundan alındı ve ajanlar için önemli ölçüde desteklenen modellere sahip değildi. İç denetim bunun bir hata olduğunu ve kasıtlı bir boşluk olmadığını gösterdi. Zamanla bu boşluk asla ele alınmadı ve bayrak geçişinden sonra, etkilenen modellerden herhangi biri ile yapılandırılan ajanlar geri listedeki yokluğu nedeniyle başarısız olacaktır. # # Tespit Bir müşteri konuyu bildirdi ve 16:44 UTC'deki mühendislere yükseldi. İzlememiz uyarmadı, çünkü bu hata genellikle organizasyon veya ajan seviye konfigürasyon sorunlarına işaret ediyor. # # Response Mühendisler, yapılandırma değişikliğine başarısızlıkları takip etti ve 19:01 UTC'de tekrarladılar. Revert aşağıdaki dakikalar üzerinde etkisi aldı ve son başarısızlık 19:40 UTC'de gerçekleşti. ## Takip 1. Model listeleri bu değişiklik tekrar yapılmadan önce uyumlu olacaktır. 2. Bu hatanın bu kadar platform çapındaki uyarıları nasıl sınıflandırıldığını değiştiriyoruz.
Resmî olay güncellemesinden otomatik olarak çevrilmiştir.
1 Ekim'e yaklaşık 12:00 PM UTC'de başlayan, Avrupa'daki topluluk kullanıcıları çözüm-yerel Eylem Uygulamaları kullanan LowCode Agent'larda başarısızlık yaşayabilirler. Etkinin Avrupa'daki topluluk kullanıcıları ile sınırlı olduğunu doğruladık. Sorunu aktif olarak araştırıyoruz, hataların boyutunu belirler ve bir düzeltme üzerinde çalışıyoruz.
Sorunu, Avrupa'daki topluluk kullanıcıları için çözüm-yerel eylem uygulamalarını kullanan düşük kodlu ajanlarda tespit ettik. Önceki değişiklikleri geri alıyoruz ve kurtarmayı izlemeye devam ediyoruz. Bir kez geri dönüş tamamlandıktan sonra başka bir güncelleme sağlayacağız ya da paylaşmak için ek bilgilerimiz varsa.
Rollback'in tamamlandığını ve Avrupa'daki topluluk kullanıcıları için çözüm-yerel eylem uygulamalarını kullanan düşük kod ajanlarının etkilendiğini doğruladık. Hizmetler iyileşti ve bu olayı kapatıyoruz.
## Müşteri Etkisi 1 Ekim 2026'da, 10:50'den 19:50 UTC'ye kadar, Avrupa'daki bazı Studio Web kullanıcıları orkestra süreçleri (RPA, ajanlar, vs.) veya Eylem Uygulamaları aynı çözümden çağıran ajanlar yapamazlardı. Çağrı " bulunamadı" bir hatayla başarısız oldu. Yayınlanmış ajanlar ve üretim işleri etkilenmedi. ## Root neden A Studio Web update, çözüm kaynaklarının debugging sırasında nasıl yer aldığını değiştirdi. Önceki davranışı koruyan bir ayar eksikti, bu yüzden debug, kullanıcının kişisel çalışma alanındaki kaynakları, debug klasörü yerine inceledi. # # Tespit Otomatik son testler mühendislerimizi 16:43 UTC'de uyarır. En son test paketi her 2 saatte bir kez çalışır ve sadece 3 ardışık test başarısızlıklarından sonra uyarır. Sorun aynı zamanda bir müşteri ortamından da rapor edildi. # # Response Kök nedenini tespit ettikten sonra, bir rollback 18:00 UTC'de başladı ve 19:50 UTC'de tamamen etkisi oldu. Bu süre, 50 dakika süren bir dağıtım başarısızlığı içeriyordu. ayarı içeren düzeltilmiş bir versiyon 2 Ekim 13:00 UTC'de dağıtıldı. ## Takip 1. Set şimdi ana kod hattının bir parçasıdır, bu yüzden gelecek sürümler içerir. 2. Uyarıları geliştiriyoruz ve son test paketi daha önce regresyon yakalamak için geliştiriyoruz.
Resmî olay güncellemesinden otomatik olarak çevrilmiştir.
1 Ekim 2026'da 14:23 ve 16:04 UTC arasında, Avustralya'daki UiPath Otomasyon Bulut hizmetlerindeki bazı istekler "404 Not Found" hatalarıyla başarısız oldu. Etkilenen hizmetler orkestracı, Doküman Anlayışı, AI Center ve Data Service içeriyordu. Görme, yaratma ve güncellenmesi gibi diğer işlemler normalde çalıştı. Sebep, talep routing için bir yapılandırma değişikliğiydi. Geri döndük ve hizmet tamamen restore edildi.
## Müşteri Etkisi 1 Ekim 2026 2:23 UTC ve 4:04 pm UTC arasında, müşterilerin alt seti deneyimledi **404 Avustralya bölgesinde bazı UiPath Otomasyon Bulut talepleri için hata bulunamadı. Olay 1 saat ve 41 dakika sürdü. Etkilenen istekler işlemleri ve bazı Robot bağlantı kontrollerini içeriyordu. Etkilenen hizmetler orkestracı, Doküman Anlayışı, AI Center ve Data Service içeriyordu. Orkestrator denilen robot işleri başarısız olabilir ve müşteriler bu pencerede başarısız olan herhangi bir robot işi yeniden çalıştırmanız gerekebilir. Diğer tüm operasyonlar etkilenmedi. ## Root neden A routing yapılandırma değişikliği Avustralya bölgesine, serbest boru hattında bir süre boyunca desteklenen operasyonların eksik bir setiyle uygulandı. Delete işlemleri yapılandırmadan eksikti, bu nedenle bu istekler, alt servislere ulaşmadan önce **404 numaralı routing katmanında reddedildi. # # Tespit Otomatik end-to-end izleme sorunu Belge Anlama hizmeti kontrolleri için başarısızlıklarla tespit etti. Mühendislik ekibimiz daha sonra etkilenen hizmetlerdeki daha geniş hataları doğrulamak için iç izleme verilerini kullandı. # # Response Araştırma sırasında, izleme verileri, Avustralya bölgesi aracılığıyla yollanan isteklerin geri döndüğünü gösterdi **404 Not Found** hataları, diğer bölgelerden gelen talepler etkilenmedi. Analiz, **404'un başlangıç zamanını tespit etmedi ** yanıt artışı, routing yapılandırması yürürlüğe girdiğinde zaman ile ilişkilendirildi. Takım önceki çalışma versiyonuna routing yapılandırmasını tekrarladı. Revert'den sonra, izleme, yaklaşık üç dakika içinde hata sayılarını gösterdi ve hizmet 1 Ekim 2026 tarafından 4:04 pm UTC'de tamamen restore edildi. ## Takip 1. 4xx temelsel değişiklikler üzerine katman uyarılarını geliştirin. 2. Analiz yapmadan önce kısmen devre dışı konfigürasyonlar uygulanır
Resmî olay güncellemesinden otomatik olarak çevrilmiştir.
Ekibimiz, ABD bölgesinde orkestracıyı etkileyen mezuniyetsiz performans için aktif olarak çalışıyor. Güncellemeleri ilerleme olarak paylaşacağız.
Bir düzeltme şu anda ABD bölgesinde orkestracı ve Eylem Merkezi etkileyen yüksek çözünürlük için kullanılıyor. Daha fazla güncelleme takip edecektir.
ABD bölgesinde orkestracı ve Eylem Merkezi etkileyen üstün performans için bir düzeltme uygulandı. Ekibimiz, sorunu doğrulamak için sonuçları aktif olarak izliyor.
ABD bölgesinde orkestracı ve Eylem Merkezi etkileyen üstün performans için bir düzeltme uygulandı. Sorunu doğrulamak için sistem performansını ve istikrarı izlemeye devam ediyoruz. Ek güncellemeler daha fazla bilgi mevcut olduğu gibi sağlanacaktır.
ABD bölgesinde orkestracı ve Eylem Merkezi etkileyen üstün performans çözüldü. Sistem performansı, uygulanan düzeltmenin ardından istikrarlı kaldı ve standart izlemeye devam edeceğiz.
## Müşteri Etkisi 1 Ekim 2026'da yaklaşık 11:00 UTC ve 13:40 UTC arasında, ABD'deki müşteriler daha yavaş orkestracı yanıt süreleri ve geçici zaman aralıkları gözlemledi. Robotlar artık işe başlamaya, süreç kuyruk öğelerine başlamalı ve varlıklar okumayı başardı ve bu taleplerin bazıları başarısız oldu. Orkestrator'a güvenen diğer UiPath hizmetleri de orkestracı bozuldu ve daha yavaş cevap veya hataları görmüş olabilir. ## Root neden Bir orkestra tamir dağıtım, bilişim kapasitesinin hizmetlerimiz için nasıl rezerve edildiği ve ölçekleneceği bir değişiklik içeriyordu. Değişim, altyapımızı daha verimli kullanmak anlamına geliyordu, ancak orkestracıya mevcut işleme kapasitesini düşürdü. Yoğun dönemlerde, otomatik ölçeklememiz beklenen kapasiteyi eklemedi, bu yüzden hizmet taleple devam edemedi. # # Tespit İç izlememiz güncellemeden sonra yavaşlamayı tespit etti. İlk planımız, birkaç saat süren standart serbest bırakma sürecimiz aracılığıyla düzeltilmesiydi. Müşteri raporları gelmeye başladığında, bir olayı açtık ve daha hızlı bir düzeltmeye taşındık. # # Response Mühendislik ekibimiz, önceki kapasite ayarlarını doğrudan etkilenen hizmetlere uyguladı, düzeltme güncellemesini beklemeden. Yanıt süreleri yaklaşık 13:40 UTC'de normale döndü ve hizmetin istikrarlı olduğunu doğrulamaya devam ettik. ## Takip Bunu tekrar olmasını önlemek için: - Önceki kapasite ayarlarını sürekli olarak geri yükleyin ve yuvarlanmadan önce üretim seviyesindeki yüklere karşı gelecekteki kapasite değişikliklerini gözden geçirin. - Atıklar sırasında müşteri etkisini nasıl değerlendirdiğimizi geliştirmek, bu yüzden daha önce bir olaya yükseldiler. - Müşterilerinizi etkileyen kapasite ve konfigürasyon değişiklikleri yuvarlamak için daha hızlı yapmak.
Resmî olay güncellemesinden otomatik olarak çevrilmiştir.
