Pricing
Status historyRSS updatesStatus API

Powered by Uptimus

    Unico kesinti geçmişi

    60 Unico incidents · Mart 2026 — official updates, affected components, duration and resolution details.

    Güncel duruma dön

    Instability affecting ID CLOUD

    Başlangıç 30 Ağustos 2026 02:00 UTC · 1h 15m

    IssuesKüçük çaplı olay
    Etkilenen bileşenler
    Messaging SystemAPIAPIAPI
    1. 30 Ağustos 2026 02:35 UTCinvestigating

      Sevgili Müşteri, Cuma günü saat 11 PM (BRT)'de, 29 Ağustos 2026'da, IDCloud'da bir istikrarsızlığı tespit ettik. Bu süre zarfında, bazı istekler normal yanıt zamanlardan daha yavaş başarısız olabilir veya deneyimleyebilir. Bu durumun sizin anlayışınıza sebep olabileceğini ve takdir edebileceğini biliyoruz. Yeni bir güncelleme kısa sürede sağlanacaktır. Unico Team

    2. 30 Ağustos 2026 02:49 UTCidentified

      Mühendislik ekibimiz, IDCloud'daki süreç yaratımını etkileyen istikrarsızlığın kökenini haritaladı. Teknik ekip zaten etkilenen katmandaki ölçeklendirme kaynakları dahil olmak üzere doğru önlemleri uygulamaya başladı ve önemli göstergeleri sürekli izlemeye başladı. Hizmeti geri almak en öncelikli ve tam mühendislik seferberliği ile ele alınır. Daha fazla güncellemenin kısa sürede gönderileceği tekrarlıyoruz. Unico Team

    3. 30 Ağustos 2026 02:57 UTCmonitoring

      Sevgili Müşteri, Mühendislik ekibimiz, IDCloud'daki süreç yaratmasını etkileyen istikrarsızlığı çözmek için gerekli olan doğru eylemleri gerçekleştirmiştir. Çevre, 11:48 PM (BRT) olarak normal işletim seviyelerine restore edilen erişilebilirlik ve cevap zamanlı göstergelerle istikrara döndü. Servis normal kullanım için mevcuttur. Bu zamanda teknik ekibimiz, tutarlı performansı sağlamak ve herhangi bir dalgalanma durumunda hemen hareket etmek için ortamı yakından takip ediyor. Anlayışınızı takdir ediyoruz ve daha fazla güncellemenin kısa bir süre sonra gönderileceğini tekrarlıyoruz. Unico Team

    4. 30 Ağustos 2026 03:15 UTCresolved

      Sevgili Müşteri, Yönetici Özeti ve Etkisi 11:48 PM ve 11:48 PM (BRT) 29 Ağustos'ta, IDCloud'da etkilenen bir süreç yaratılması. Bu pencerede, bu akışları kullanarak bazı müşteriler deneyimli başarısızlıklar ve yanıt süreleri arttı, kimlik doğrulama, belge yakalama ve bildirim teslimatları dahil olmak üzere bağımlı yolculuklara. İşlenmiş bilgilerin bütünlüğü veya güvenliği için bir uzlaşma yoktu ve hiçbir veri kaybedilmedi. Göstergeler 11:48 PM (BRT) normalleşme ile normal çalışma seviyelerinde hem izlememizde hem de müşteri tarafında, süreç yaratılması ve tamamlanmasını doğruladı. Kök Sebep ve Karar Kökeni veri katmanımızda tespit edildi: iç bakım rutini sıkıştı ve uygulama işlemleri mevcut bağlantı sınırının tükenmesine, işleme kapasitesini azaltmaya başladı. Mühendislik ekibimiz sadece sıkışık rutini cerrahi olarak sonlandırmıştır, hemen kuyrukları serbest bırakır. Bağlantılar ve işleme kapasitesi tamamen restore edildi, hiçbir veri değişikliği yoktu. Komünizm ve Sonraki Adımlar Mühendislik ekibimiz üç cepheye odaklanacaktır: iç bakım rutinleri için zaman sınırlamak, aynı yapıya karşı koşup, veri katmanındaki dalgalanmalara hizmet esnekliğini güçlendirmek. Tam zaman çizelgesi ve tarihlerle bir eylem planı dahil olmak üzere ayrıntılı bir postmortem, kısa sürede paylaşılacaktır. Operasyonlarınız üzerindeki etki için içtenlikle özür dileriz ve destek kanallarımız aracılığıyla kullanılabilir. Unico Team

    Resmî olay güncellemesinden otomatik olarak çevrilmiştir.

    ID CLOUD yeteneklerini etkileyen enstability

    Başlangıç 10 Ağustos 2026 20:10 UTC · 51m

    OutageBüyük çaplı olay
    Etkilenen bileşenler
    APIIDTrust | APIAPI
    1. 10 Ağustos 2026 20:26 UTCidentified

      Sevgili müşteri, Bazı IDCloud talepleri üzerinde bir etki tespit ettik, Davranış Uyarısını (IDTrust) yeteneği ve 1:N akışı etkileyen. Bu istikrarsızlık, bu yeteneği kullanan Meksika'daki müşterileri de etkileyebilir. Mühendislik ekibimiz sorunu mümkün olduğunca kısa sürede çözmek için seferber edilir. Kısa bir süre yeni güncellemeler sağlayacağız.

    2. 10 Ağustos 2026 20:29 UTCmonitoring

      Mühendislik ekibimiz etkilenen IDCloud akış yeteneklerindeki istikrarsızlığı çözmek için gerekli eylemleri belirledi ve uyguladı. Bu zamanda, teknik ekip veri katmanımızın ayrıntılı bir analizini yürütüyor ve çevreyi izlemeye devam ediyor. Daha fazla güncellemenin kısa sürede gönderileceği tekrarlıyoruz.

    3. 10 Ağustos 2026 21:01 UTCresolved

      Yönetici Özeti ve Etkisi Yaklaşık 5:08 PM, yüz tanıma hizmetinde bir erişilebilirlik düşüşü tespit etti (1:N akışı), olayı tetikledi. Sorun hızla yükseldi ve davranış uyarı hizmeti etkilemeye başladı ve daha sonra, bu hizmetler arasında zaman kesintileri nedeniyle süreç oluşturma akışı. Etki, bu yetenekleri kullanarak müşterilerin alt setini etkiledi. Durum 5:22 PM'de stabilize edildi, metrikler normal seviyelere geri döndü. Kök Sebep ve Karar Kök nedeni, bir iç iş yükü tarafından üretilen bir trafik artışıydı, bu da yüksek yüz tanıma taleplerini doğrudan biyometrik boru hattına gönderdi ve normal müşteri trafiği tarafından kullanılan kenar katmanını atladı. Bu ek hacim, yüz tanıma hizmeti destekleyen veritabanının kapasitesini doyabilirsiniz. Bu hizmette zaman aralıklarına neden oldu, bu da biyometrik motor orkestrası hizmetine yol açtı ve sonunda bu yetenekleri kullanarak süreç yaratımına yol açtı. Sorunu çözmek için, ekip, etkilenen veritabanının kapasitesini arttırmak ve artırmaktan sorumlu iş yükünü durdurdu. Bu eylemler problemi hafifletti, hata hacmi yakın seviyelere geri döndü. Komünizm ve Sonraki Adımlar Takip edilen bir öğe, geri dönüşe neden olan iç iş yükü türü için limitli bir hesaplama olarak açıldı. Etkilenen veritabanı için kapasite artışı zaten olay sırasında yapıldı.

    4. 25 Ağustos 2026 13:05 UTCpostmortem

      **Summary** 10 Ağustos 2026'da, 5:08 PM ve 5:27 PM \(Brasília zamanı) arasında, 1.N yüz tanıma akışı için erişilebilir gösterge% 95'in altında kaldı, yaklaşık 19 dakika etkilendi. Olay, biyometrik motor tarafından kullanılan vektör arama veritabanının doygunlaşmasına neden oldu ve kuyruk tüketim mekanizmasında beklenmedik davranışlardan kaynaklanan bir çağrı hacmi 236 kat daha yüksekti. Aşırı yük, veritabanının maksimum ölçeklendirme sınırına ulaştı, birden çok bağımlı servislere karşı zaman aralıklarına neden oldu ve 55 müşteri kullanıcıyı dönem boyunca hatalarla etkiledi. **Impact** Yüz tanıma, kimlik doğrulama ve süreç oluşturma kullanıcıları, birçok müşteriden gelen hataları ve zamanları dönem boyunca deneyimlediler. Veritabanı biyometrik orkestrasyon, motor ve süreç oluşturma hizmetleri aracılığıyla kalibre edildi. Mitigation, bir iç hizmeti bozmak ve veritabanın maksimum ölçeklendirme limitini artırmak, hizmeti 5:27 PM'de stabilize etmek tarafından gerçekleştirildi. **Root Cause** Kök nedeni, hizmet davranışı ile ilgili faktörlerin bir kombinasyonu ve ilgili altyapının kapasitesiydi. Servis ikinci başına 2 istekle yapılandırıldı, ancak kuyruk tüketim mekanizması beklenmedik bir şekilde hareket etti: işleme süresi sona ermiş olan mesajlar orijinal infazı iptal etmeden sıraya alındı - 938 iş öğelerini 2,217 etkili aramalar \ (~8.4 RPS\). Bu geliştirilmiş bir trafik, kenar koruma katmanından geçmeden veritabanına ulaştı, bu normalde talep hacmini sınırlayacaktı, çünkü bu akışta kullanılan ağ yolu bu kontrollerden geçmedi. Veritabanı, zaten maksimum ölçeklendirme limitine yakın çalışıyor, ek yükü absorbe edemiyordu - CPU, 100 düğümün yapısal tavanına kadar ölçeklendirmek için% 88'e ulaştı - ve sorgu geçncy ~3 saniyeden ~18.75 saniye sonra p90'a kadar, bağımlı hizmetlerin tüm zincirine zaman harcıyordu. **Resolution** Ekip, yükün kaynağı olarak uyarının birkaç dakika içinde tespit etti. Süreç devre dışı bırakıldı ve veritabanının maksimum ölçeklendirme sınırı 100 ila 150 düğümden yükseldi. Bu iki eylemle, hizmet 5:27 PM'de stabilize edildi. **Lessons Learned** Olay, sadece mesaj yayın tarafında uygulanan oranın, tüketicinin kırmızıelivery ile hacmi artırabileceğinde yetersiz olduğunu gösterdi. Seviye ve eşdeğer kontrollerin tüketim tarafında da var olması gerekir. Ek olarak, kenar korumalarının yapısal bir risk teşkil ettiği yollarla kritik bileşenlere erişim sağlayan iç hizmetler - herhangi bir iç müşteri paylaşılan altyapıya kontrol edilemez yük üretebilir.

    Resmî olay güncellemesinden otomatik olarak çevrilmiştir.

    Instabilidade people-sign

    Başlangıç 31 Temmuz 2026 12:42 UTC · 1h 24m

    IssuesKüçük çaplı olay
    Etkilenen bileşenler
    Assinatura Eletrônica no API - Unico SignAssinatura Eletrônica
    1. 31 Temmuz 2026 12:42 UTCinvestigating

      Prezados müşterileri, Identificamos uma instabilidade técnica pontual que afeta azarização do painel de acompanhamento após o envio de documentos. Reforçamos que o fluxo de envio e assinatura está funcionando normalmente: os kaderatários sürekliam reebendo e conseguindo assinar os arquivos. No entanto, o kayıto roma pode temporariamente não ser exibido na lista de acompanhamento tekrarmetente yapar. Nossa done de engenharia já está atuando para corrigir a exibição na arayüz e restabcerele o histórico no painel o mais breve possível. Pedimos desculpas pelo inconveniente e manteremos todos bilişimados sobre o ilerlemeo. Atenciosamente,

    2. 31 Temmuz 2026 13:08 UTCidentified

      Prezados müşterileri, Gostaríamos de inualizar o durumu sobre a visualização de documentos no painel de acompanhamento. O problema foi identificado com sucesso por nossa done técnica. No momento, os engenheiros já estão subindo a correção para restabelecer a exibição correta de todos os envios na arayüz do remetente. Lembramos que o processamento, envio e assinatura dos documentos sürekliam operando normalmente. Volataremos com uma nova atualização assim que a correção for concluída e entrarmos na fase de monitoramento. Atenciosamente,

    3. 31 Temmuz 2026 13:20 UTCmonitoring

      Prezados müşterileri, Informamos que a correção para exibição no painel de acompanhamento foi aplicada com sucesso. A lista de documentos e históricos de envios já está retornando à normalidade. No momento, nossa done de engenharia está monitorando o ortamıe de perto para makinesine sahip bir estabilidade total doço. Agradcemos bir paciência e traremos doğru biração breve yapıyor. Atenciosamente,

    4. 31 Temmuz 2026 14:06 UTCresolved

      Prezados müşterileri, Informamos que o evente relacionado à exibição de envios no painel de acompanhamento foi oficialmente encerrado. Após aplicação da correção e o período de monitoramento, bir listecim e o he histórico de documentos foram totalmente restabelecidos, e a plataforma opera amleta estabilidade. Agradcemos pela compreensão e paciência de todosgglete o processo. Atenciosamente,

    Resmî olay güncellemesinden otomatik olarak çevrilmiştir.

    Webhook Instability Influenceing ID Cloud Cap tasks

    Başlangıç 29 Temmuz 2026 11:00 UTC · 0m

    Pending
    1. 29 Temmuz 2026 14:04 UTCresolved

      Yönetici Özet & Etkisi Size, olayın ID Cloud Webhook bildirim hizmetini geçici olarak etkilediği konusunda bilgi vermek istiyoruz. Etkisi Dönemi: 08:32'den 10:05'e kadar. Platform Etkisi: Belirsizlik Webhook bildirim teslimatı ile kesinlikle sınırlıydı, mesaj dağıtımında gecikmeye yol açtı. Ana platformun bozulması yoktu, canlılık motorunda başarısızlık yoktu ve veri kaybı yoktu. Müşteri Etkisi: Sorun, müşterilerin küçük bir kısmını etkiledi. Bir GET kirletici akışı bir kontingency (fallback) olarak kullanan müşteriler, kesinti veya operasyonel etki yaşamamıştır. Kök Sebep & Karar Kök Sebep: Risk, ortamda bir özellik güncellemesi tarafından tetiklendi. Görev kuyruğu ve varış rotası arasında geçici bir yanlışlık, geçici bir geri bildirime yol açtı. Resolutive Action: Teknik ekip, yeni çevreye trafik yönlendirmesini tamamladı, bileşenler arasında uygun iletişimin geri kalanını geri Webhooks'un geri dönüşünü geri getirdi. İşleme normale döndü ve gönderilen kuyruk tamamen temizlendi. Commitment & Next Steps Hizmetlerimizin istikrarı bizim en yüksek önceliğimizdir. Toplam şeffaflığı sağlamak ve recurrence önlemek için, mühendislik ekibimiz aşağıdaki cephelere odaklanacaktır: Detaylı Postmortem: derinlemesine kök neden analizi ve koruyucu bir eylem planı içeren kapsamlı bir rapor hazırlanacaktır. Observability Improvements: Geçiş senaryolarında daha fazla görünürlük sağlamak için ölçüm ölçüm ölçümleri ayarlayacağız. Rahatsızlıktan içtenlikle özür dileriz ve daha fazla clarification için kullanılabilir kalırız. Sincerely, Unico Team

    2. 7 Ağustos 2026 13:08 UTCpostmortem

      **Summary** 29 Temmuz 2026'da, 8:32 AM ve 10:05 AM \ (Brasília zamanı) arasında, webhook teslimat servisi yaklaşık 1 saat ve 33 dakika boyunca bozuldu. Olay planlı bir altyapı göçü tarafından geçici bir yetersizlik durumuna yol açtı: İç rotalar yeni kümeye geçtikten sonra, webhook hizmeti yeni kümeden kimlik doğrulama Jetonları üretmeye başladı, ancak teslimatlar hala eski kümeye yönlendirildi - bu da Jetonları bir yetki hatasıyla reddetti. Kayıp olaylar talep üzerine yeniden işlendi. **Impact** Birden çok ürün aynı anda etkilendi - kimlik doğrulama, ödeme ve gemi akışları dahil. İş akışlarına devam etmek için yalnızca webhook bildirimlerine dayanan müşteriler dönem boyunca deneyimli operasyonel kesintilere devam ederler. Bir geri dönüş mekanizması olarak aktif ankete uygulanan müşteriler azaltıldı. **Root Cause** Kök nedeni göç planında tespit edildi: prosedür webhook akışının zincirli bağımlılığı haritalamadı - iç rotanın bu noktada, teslimat için halka uygun bir görev yarattığı. İç rotaları ve halka açık rotaları ayrı adımlar atarak, yeni küme tarafından üretilen depoların eski kümenin yetki politikası tarafından reddedildiği, özellikle önceki hizmet hesap tanımlayıcısını doğrulayan bir uyarı penceresi oluşturuldu. Bu senaryo, değişimin risk değerlendirmesi sırasında tespit edilmedi ve mevcut hizmet kalitesi göstergelerinin hiçbiri başarısızlık materyalinin bulunduğu asynchronous teslimat katmanını kapladı. **Resolution** Ekip, hataların kaynağı olarak token uygunsuzluğu tespit etti ve halk rotalarının yeni kümeye geçişini tamamladı, ayrımı ortadan kaldırdı. Bu noktadan itibaren kuyruktaki bekleme teslimatları normal olarak işlemeye başladı. Etki 10:05 AM'de durduruldu ve eski kümedeki trafik 10:32 AM'de sıfıra ulaştı. **Lessons Learned** Olay, zincirlenmiş asynchronous teslimat akışlarını içeren göçlerin zincire katılan tüm rotaları gerektirdiğini gösterdi - iç ve halk - kümeler arasındaki tutarlı pencereler olmadan koordineli bir şekilde göç edilmesi. Kullanılan kademeli yaklaşım, çoğu göç için uygun olsa da, atomik bir geçiş veya çok daha kısa bir geçiş penceresinden kaçınabilecek uzun bir başarısızlık dönemi yarattı. Ek olarak, asynchronous teslimat katmanında gözlemlenebilirliğin eksikliği olayı içsel olarak tespit edilmedi - mevcut göstergeler yalnızca olay kabulünü ölçtü, gerçek teslimat değil. Bu katmandaki başarısızlıklar ve backlog için özel uyarılar oluşturmak, tespit edilen en acil izleme artışıdır.

    Resmî olay güncellemesinden otomatik olarak çevrilmiştir.

    Webhookslarımızda veri teslimatında geç kalmışlığı etkiler

    Başlangıç 24 Temmuz 2026 21:47 UTC · 31m

    IssuesKüçük çaplı olay
    Etkilenen bileşenler
    APIAPIAPIAPI
    1. 24 Temmuz 2026 21:47 UTCinvestigating

      Sevgili Müşteri, Şu anda Webhookslarımızda bir istikrarsızlığı araştırıyoruz, bu da veri teslimatında gecikmeyi etkiliyor. Mühendislik ekibimiz sorunu mümkün olduğunca çabuk çözmek için aktif olarak çalışıyor. Yakında daha fazla güncelleme sağlayacağız.

    2. 24 Temmuz 2026 21:53 UTCmonitoring

      Sevgili Müşteri, Mühendislik ekibimiz, verilerin gecikme süresini etkileyen Webhook istikrarsızlıkını çözmek için gerekli eylemleri belirledi ve uyguladı. Bu zamanda, teknik ekip veri katmanımızın ayrıntılı bir analizini yürütüyor ve çevreyi izlemeye devam ediyor. Daha fazla güncellemenin kısa sürede gönderileceği tekrarlıyoruz.

    3. 24 Temmuz 2026 22:18 UTCresolved

      Yönetici Özeti ve Etkisi 6:05 PM (Brasília zamanında), Webhook hizmetinde bir istikrarsızlık meydana geldi, bu dönemde etkilenen operasyonlar için olay işleme ve bildirim teslimine yol açtı. Kök Sebep ve Karar Olay, birden çok hizmette kullanılan paylaşılan bir Servis Hesabı ile ilgili bir konu tarafından neden oldu, kimlik doğrulama başarısızlıkları nedeniyle. Kök nedenini tespit ettikten sonra, mühendislik ekibi gerekli bilgileri ve yapılandırmayı restore etti. Normal operasyon 6:29 PM (BRT) tamamen yeniden kuruldu. Komünizm ve Sonraki Adımlar Sürekli iyileşme ve risk mitigation'in bir parçası olarak, mühendislik ekibi, hizmet genelinde kaynak bağımlılarını ve erişim yönetimini inceleyecek. Bu, gelecekteki altyapı ayarlamalarında benzer konfigürasyon sorunları önleyecek.

    4. 3 Ağustos 2026 20:00 UTCpostmortem

      **Summary** 24 Temmuz 2026, 6:05 PM ve 6:29 PM \ (Brasília zamanı) arasında, webhook yaratımı ve teslimat hizmeti yaklaşık 24 dakika boyunca mevcut değildi. Olay, daha önceki günlerde yapılan bir küme göçü ile bağlantılı bir kaynak erteleme sürecinde bir altyapı hizmetine erişim kaybından kaynaklanıyordu. Etkilenen hesap, bu bağımlılık belgelenmeden birçok hizmet tarafından paylaşıldı, webhook hizmetinin kimlik doğrulama kapasitesini kaybetmesine ve olayların yaratılmasına neden oldu. **Impact** Webhook olayı oluşturma ve teslimat dönem boyunca kesintiye uğradı, 18 müşteri kullanıcıyı 1.550'den fazla hata kaydetti. Aynı kimlik doğrulama akışına bağlı olan diğer hizmetlere olan etkisi, farklı platform yeteneklerine eşzamanlı olarak bozulmaya neden oldu. **Root Cause** Kök nedeni hizmet bağımlılığı yapılandırmasında tespit edildi. Bu çapraz hizmet bağımlılığı, herhangi bir bağımlılık haritasında belgelenmiş veya görünür değildi. Emisyon işlemi orijinal hizmetin kaynağının bir parçası olarak hesabı kaldırıldığında, hesabın diğer aktif hizmetler tarafından kullanılmış olup olmadığını kontrol etmek için otomatik bir doğrulama yoktu. Bu korumanın yokluğu, ortadan kaldırılmasının yaygın kimlik doğrulama başarısızlıklarına yol açtığına kadar saklı tuttu. **Resolution** Ekip, kimlik doğrulama başarısızlıklarının kaynağı olarak istikrarsız hizmet hesabını hızla tanımladı. Hesap manuel olarak ayarlandı ve kümeye uygulandı, hizmeti 6:29 PM'de restore etti. Toplam etki süresi yaklaşık 24 dakika idi. **Lessons Learned** Olay, hizmetler arasında gizli bağımlılık yaratan miras yapılandırmalarının risklerini açığa çıkardı: Planlanan bakım sırasında tek bir kaynak değişikliği aynı anda birden fazla hizmeti bozmak için yeterliydi. altyapı kaynağı, herhangi bir değişiklikten önce otomatik bağımlılık doğrulamayı içermelidir.

    Resmî olay güncellemesinden otomatik olarak çevrilmiştir.

    ID CLOUD yeteneklerini etkileyen enstability

    Başlangıç 21 Temmuz 2026 16:39 UTC · 1h 23m

    OutageBüyük çaplı olay
    Etkilenen bileşenler
    API
    1. 21 Temmuz 2026 16:39 UTCidentified

      Sevgili müşteri, Süreç yolculuğunda kimlik doğrulama akışlarını etkileyen IDCloud işlevlerinde bir istikrarsızlığı araştırıyoruz, özellikle Web Yolculuğunu etkiliyor (eski olarak ByUnico). Mühendislik ekibimiz sorunu mümkün olduğunca kısa sürede çözmek için seferber edilir. Yakında daha fazla güncelleme sağlayacağız.

    2. 21 Temmuz 2026 16:49 UTCmonitoring

      Sevgili Müşteri, Mühendislik ekibimiz etkilenen IDCloud akış yeteneklerindeki istikrarsızlığı çözmek için gerekli eylemleri belirledi ve uyguladı. Bu zamanda, teknik ekip veri katmanımızın ayrıntılı bir analizini yürütüyor ve çevreyi izlemeye devam ediyor. Daha fazla güncellemenin kısa sürede gönderileceği tekrarlıyoruz.

    3. 21 Temmuz 2026 18:02 UTCresolved

      Yönetici Özeti ve Etkisi 21 Temmuz 2026'da yaklaşık 12:44 PM (Brasília zamanı) başlayarak, akıştaki ilk ekranların daha yavaş yüklemesini deneyimledi. Etki, bu yolculuğun kullanıldığı tüm ortamlarda gözlemlendi, algılanan hızı etkiledi ve daha az ölçüde, kullanıcıların bu dönemde süreci tamamlamak için yeteneği. Kök Sebep ve Karar Soruşturma, olayın kesin kök nedenini doğrulamak için devam ediyor. Sunucular, ağ veya altyapı üzerinde hiçbir etkisi yoktu - konu kullanıcının cihazdaki ekran deneyimine izole edilmek için doğrulandı. Bir kapsam ölçüsü olarak, sorumlu ekip 1:39 PM (BRT)'de önleyici bir ayarlama uyguladı ve yükleme süreleri birkaç dakika içinde normale döndü. Kök nedenini doğrulamak ve doğrulamak için analiz hala teknik ekip tarafından yürütülmektedir. Komünizm ve Sonraki Adımlar Olay yanıt süreçlerinin sürekli iyileştirilmesinin bir parçası olarak, ekip, sorumlu takımlar için otomatik escalasyon akışını artırmak için taahhüt eder ve bir olaydan daha doğrudan ve etkili hale getirir. Ayrıca, yükleme hızı izleme, bu yolculuğa yeni değişiklikler sırasında güçlendirilecek ve potansiyel regresyonları tanımlamak ve daha hızlı bir şekilde düzeltmek, benzer durumlarda kullanıcılar için minim etkisi ileriye götürecek.

    4. 3 Ağustos 2026 14:01 UTCpostmortem

      **Summary** 21 Temmuz 2026'da, 12:44 PM ve 1:43 PM \ (Brasília zamanı) arasında, düşük yolculuk için performans göstergeleri, ortalama yük zamanı ~4.8s'den ~8.9'a kadar atladı ve p95 31.5 saniye ulaştı. Olay, yüklemeden önlenen sağlayıcıdan gelen bağlantıların bulut altyapısı tarafından uygulanan oran sınırlamasına neden oldu. **Impact** 32 müşteriden gelen kullanıcılar son derece yavaş sayfa yükleri veya tam yükleme başarısızlıklarını deneyimledi, yaklaşık 94 yolculuk hatası kaydedildi. "Initialization Timeout" hataları - uygulamanın 30 saniye içinde dağıtmadığı zaman - dönem boyunca yaklaşık 23 bin olaya ulaştı. **Root Cause** Kök nedeni altyapının ağ katmanında tespit edildi: CDN sağlayıcısı sınırlı sayıda IP adresi aracılığıyla trafiği konsolide etti. Yeni TCP bağlantıları ve TLS elhakları bu IP'lerden kaynaklanan bir artış, bulut altyapısının otomatik ağ katmanlı savunma mekanizmalarını tetikledi ve bu işlemden önce oran-limiting bağlantıları başladı. Çünkü bu başarısızlıklar ağ katmanında meydana geldi - HTTP işlemeden önce - standart istek girişlerinde görünmediler, sorunu geleneksel izlemeye görünmez hale getirdiler ve önemli ölçüde kısıtlayıcı tanılar. **Resolution** Etki bulut altyapısı tarafından uygulanan oranın doğal iyileşmesiyle durduruldu. Bir bileşenin yok edilmesi, başlangıçta mümkün bir neden olarak bayraklandı, iyileşme ile zaman zaman zaman zaman zamanlandı, ancak daha sonra olayla ilgili olmadığını doğruladı. Kurulum düzeltmeleri - HTTP Keep-Alive'e genişletilmiş bir süre ile izin vermek ve kenar koruma katmanında CDN IP'lere izin vermek - ilgili sağlayıcıların destek ekipleri tarafından takip edilen öğeler olarak tespit edildi. **Lessons Learned** Olay, CDN ve bulut altyapısı arasındaki ağ katmanındaki başarısızlıkların standart uygulama izleme için görünmez olduğunu, önemli bir kör nokta yaratarak vurguladı. Takip malzemeleri olarak, ekip, sağlayıcıların önerdiği yapılandırma düzeltmelerini uygulama ve bu tür bozulmaları proaktif olarak tespit etmek için varlık teslim katmanında gözlemlenebilirliği genişletme ihtiyacını belirledi.

    Resmî olay güncellemesinden otomatik olarak çevrilmiştir.

    ID CLOUD yeteneklerini etkileyen enstability

    Başlangıç 21 Temmuz 2026 14:30 UTC · 1h 29m

    OutageBüyük çaplı olay
    Etkilenen bileşenler
    APIAPIAPIIDTrust | APIAPI
    1. 21 Temmuz 2026 14:39 UTCidentified

      Sevgili müşteri, IDCloud yeteneklerimizde bir istikrarsızlık araştırıyoruz, süreç yaratılmasını ve süreci ayrıntıları akışlarını etkiliyoruz. Mühendislik ekibimiz sorunu mümkün olduğunca kısa sürede çözmek için seferber edilir. Yakında daha fazla güncelleme sağlayacağız.

    2. 21 Temmuz 2026 14:46 UTCidentified

      Bu sorun için bir düzeltme üzerinde çalışmaya devam ediyoruz.

    3. 21 Temmuz 2026 14:50 UTCmonitoring

      Sevgili Müşteri, Mühendislik ekibimiz etkilenen IDCloud akış yeteneklerindeki istikrarsızlığı çözmek için gerekli eylemleri belirledi ve uyguladı. Bu zamanda, teknik ekip veri katmanımızın ayrıntılı bir analizini yürütüyor ve çevreyi izlemeye devam ediyor. Daha fazla güncellemenin kısa sürede gönderileceği tekrarlıyoruz.

    4. 21 Temmuz 2026 16:00 UTCresolved

      Yönetici Özeti ve Etkisi 21 Temmuz 2026'da, yaklaşık 11:17 AM BRT'de, erişilebilirlik içinde bir düşüş IDCloud oluşturma-işlem ve işlem-kır akışlarında tespit edildi. Etki penceresi sırasında, müşterilerin bir kısmı yüksek gecikme ve başarısızlıklar (zamanlar) bu işlemlerde, bağımlı hizmetler zinciri aracılığıyla yönlendirildi. Etkili etki yaklaşık 23 dakika içinde yoğunlaştı. zirvede, hata ve latency göstergeleri normal işletim seviyelerinin üzerindeydi. Kök Sebep ve Karar Soruşturma, bu yetenekleri kökeni olarak destekleyen bir okuma veritabanının bozulmasına işaret etti. Bu veritabanı daha fazla yük ve sorgu yürütme süresini göstermeye başladı, iç içerikli işlemeyi durduran ve okuma isteklerini destekledi. Sonuç olarak, yukarıdaki hizmetler, koruma mekanizmalarının belirlenmesi ve tetiklenmesine başladı (circuit breakers), müşterilerin deneyimlediği kalibrasyon etkisini üretti. Komünizm ve Sonraki Adımlar Unico bu olayı ayrıntılı bir postmortem ile ele alıyor, zaten draft ediliyor ve önleyici eylemleri konsolide etmek için bir post-incident inceleme (PiR) toplantısı gerçekleştirecek. Takipler arasında zaten yanıt sırasında ortaya çıkan sonuçlar, bu veritabanı katmanında içeriklenmenin tanımlanmasını hızlandırmak için tanı rutinlerinin ve sorguların hazırlanmasıdır ve dahil edilen veritabanı üzerinde gözlemlenebilirlik geliştirir. Detaylı önleyici eylemler postmortem'de paylaşılacaktır. Platformun istikrar ve güvenilirliğine olan taahhüdümüzü tekrar teyit ettik ve istikrarsızlık döneminde kaynaklanan rahatsızlıktan özür dileriz. Unico Team.

    5. 28 Temmuz 2026 12:10 UTCpostmortem

      **Summary** 21 Temmuz 2026'da, 11:41 ve 11:43 AM \ (Brasília zamanı) ile süreç oluşturma akışı, ana hizmet hatasının% 42'sine ulaşması ve 15.75 saniye içinde p99 gecikme oranıyla kullanılamaz. Olay biyometri veritabanında kopyalama tarafından neden edildi: veritabanı hafıza havuzu artık en sık erişimli veri kümesine hizmet edemedi, normal olarak hızlı sorgulara geri dönmek için disk okumasına neden oldu, bir kendini ifade eden seanslar ve latency artırmak için. **Impact** Süreç yaratımı, kimlik doğrulama ve ödemeler birçok müşteri arasında akışlar, dönem boyunca hatalar ve zamanlar aldı. İlk veritabanı olay boyunca sağlam kaldı - başarısızlık okuma kaynağına izole edildi. **Root Cause** Kök nedeni tatmin ediciydi: kimlik doğrulama akışında kullanılan sorgular eksik indeksler nedeniyle kritik tablolarda kapsamlı taramalar yapıyordu. Normal koşullarda, bu davranış veritabanı altyapısı tarafından tolere edildi. Bellek kapasitesi limitine ulaştığında ve artık önbellekteki en erişilebilir verileri tutamadı, her okuma diskten veri toplamaya başladı, her sorgunun maliyeti üst düzeye yükseldi. Bu bir aniden çöküntü etkisi – kademeli bozulmanın yaygın bir başarısızlık için yol açtığı – yanıtları ve iç veritabanı kaynak içeriğini bekleyen seanslar olarak kendini teşvik etti. Ayrıca, kritik akış için tüm okuma trafiği tek bir çoğaltma üzerinde yoğunlaştı, dağıtım veya alternatif rota ile bu tür bir bozulmaya herhangi bir dayanıklılık ortadan kaldırmak. **Resolution** Veritabanı doğal olarak birleştirilmiş seanslar tükendiğinde, manuel müdahale gerektirmez. Ekip veritabanı ekibine yükseldi ve servis stabilizasyonunu izledi. Olay normal işlemin restore edildiğine dair onaylandıktan sonra kapalıydı. **Lessons Learned** Olay veritabanı katmanında yapısal boşluklar ortaya çıkardı: kritik sorgularda indeksler eksik indeksler ve tüm okuma trafiğini alternatif bir rota ile tek bir çoğaltmada azaltın. Takipler olarak, ekip eksik indeksler oluşturmaya öncelik verdi, çoğaltmalar boyunca trafiği dağıtmaya ve benzer bir doğanın gelecekteki olaylarına cevap vermek için teşhis listeleri inşa etti.

    Resmî olay güncellemesinden otomatik olarak çevrilmiştir.

    ID CLOUD yeteneklerini etkileyen enstability

    Başlangıç 20 Temmuz 2026 12:10 UTC · 1h 13m

    OutageBüyük çaplı olay
    Etkilenen bileşenler
    APIID PortalAPIAPIIDTrust | APIAPI
    1. 20 Temmuz 2026 12:33 UTCidentified

      Sevgili Müşteri, IDCloud yeteneklerimizin bazılarında bir istikrarsızlığı tespit ettik, Get Selfie'yi, süreç yaratımını etkileyen ve Web Yolculuğu için akışları (eski olarak ByUnico tarafından). API Yolculuğu (ByClient) akışları etkilenmedi. Mühendislik ekibimiz sorunu mümkün olduğunca kısa sürede çözmek için seferber edilir. Daha fazla güncelleme ile kısa sürede takip edeceğiz.

    2. 20 Temmuz 2026 12:35 UTCidentified

      Bu sorun için bir düzeltme üzerinde çalışmaya devam ediyoruz.

    3. 20 Temmuz 2026 12:39 UTCmonitoring

      Sevgili Müşteri, Mühendislik ekibimiz etkilenen IDCloud akış yeteneklerindeki istikrarsızlığı çözmek için gerekli eylemleri belirledi ve uyguladı. Bu zamanda, teknik ekip veri katmanımızın ayrıntılı bir analizini yürütüyor ve çevreyi izlemeye devam ediyor. Daha fazla güncellemenin kısa sürede gönderileceği tekrarlıyoruz.

    4. 20 Temmuz 2026 13:22 UTCresolved

      Yönetici Özeti ve Etkisi Süreç yakalama ve görselleştirme akışlarını etkileyen bir istikrarsızlığı tespit ettik ve Web Yolculuğu için, 09:07 ve 09:21 (BRT) arasındaki etkiyle. Etki bu akışı kullanan müşterilerin bir kısmına ulaştı; API Yolculuğu etkilenmedi. Kök Sebep ve Karar Kök nedeni, üretimde uygulanan bir yapılandırma değişikliği ile bağlantılıdır ve bu da içsel bir veritabanı bileşeni üzerinde artış gösterdi. Bu artan yük, bir entegrasyon katmanında gecikme ve hataları yükseltti, bu da koruyucu bir mekanizmayı tetikledi ve Web Yolculuğu akışlarını geçici olarak durdurdu. Mühendislik ekibi, sorunu azaltmak için yapılandırma değişikliğini geri getirdi ve durum kısa bir süre sonra normalleşti. Komünizm ve Sonraki Adımlar Mühendislik ekibi, yapılan değişikliklerin geri kalanını takip eden ortamı izlemeye devam ediyor. Önümüzdeki günlerde ekibimiz tarafından ayrıntılı bir postmortem paylaşılacaktır. Bu rahatsızlıktan özür dileriz. Unico Team!

    5. 4 Ağustos 2026 14:14 UTCpostmortem

      **Summary** On July 20, 2026, between 9:07 AM and 9:21 AM \(Brasília time\), the selfie capture and authentication flows were unavailable for approximately 14 minutes. The incident was caused by a query without an adequate index running as part of the database migration flow, causing database CPU to spike to 53%, dependent service latency to jump 78 times above normal, and the circuit breaker mechanism to fully block calls to the affected service. The causing behavior was reverted and the service recovered in approximately 1 minute. **Impact** Users of the selfie, authentication, and web-based proof-of-life flows received open-circuit errors during the period, with 743 and 125 requests blocked respectively in the most affected flows. The service returned to normal at 9:21 AM after the causing behavior was reverted **Root Cause** The root cause was identified in the database migration flow: a query introduced as part of the migration lacked the index needed to run efficiently on the new database. When the new behavior was activated in production, the query began performing full scans per tenant, with the number of rows read jumping from ~5 million to ~25 million per execution, saturating the database CPU and causing response latencies of up to 10 seconds. **Resolution** The team identified the database CPU spike as the source of the problem and correlated it with the recently introduced behavior change approximately 7 minutes after the first alert. The change was reverted at 9:20 AM, and the service recovered immediately. **Lessons Learned** The incident showed that volume differences between validation and production environments can mask performance issues that only manifest at real-world scale. Silent error handling in the application worsened the situation by making the degradation invisible to monitoring. As follow-up actions, the team prioritized creating the missing index and removing the silent error suppression pattern.

    Resmî olay güncellemesinden otomatik olarak çevrilmiştir.

    Unico People Portals ve IDCloud mesajlaşma servisi için Kimlik Tanımlama Hizmetleri

    Başlangıç 16 Temmuz 2026 14:02 UTC · 1h 26m

    OutageBüyük çaplı olay
    Etkilenen bileşenler
    NotificaçõesMódulo CandidatoMessaging System
    1. 16 Temmuz 2026 14:02 UTCinvestigating

      Sevgili Müşteri, Unico People portalları için kimlik doğrulama sistemimizde bir istikrarsızlığı araştırıyoruz ve aynı zamanda IDCloud müşterileri etkileyen mesajlaşma servisimizde sorunları da değerlendiriyoruz. Mühendislik ekibimiz sorunu mümkün olduğunca kısa sürede çözmek için seferber edilir. Kısa bir süre içinde güncellemeler vereceğiz.

    2. 16 Temmuz 2026 14:08 UTCmonitoring

      Sevgili Müşteri, Ekibimiz konuyu tanımladı ve olayı çözmek için harekete geçti. Unico People portalları için doğrulama sistemimizde bir istikrarsızlık yaşadık ve IDCloud akışındaki müşterileri etkileyen mesajlaşma hizmetindeki sorunlar, SMS ve e-posta teslimatı için. Mühendislik ekibimiz seferber kalıyor, düzgün çalışmasını sağlamak için çevreyi takip ediyor.

    3. 16 Temmuz 2026 15:28 UTCresolved

      Yönetici Özeti ve Etkisi 10:51 AM on 07/16/2026, Unico People kabul portalında ve mesajlaşmada bir sorun tespit edildi, bu da Unico People ve IDCloud müşterileri için SMS ve e-posta bağlantılarını Unico People kabul portalının teslim edilmesini etkiledi. Etki bu iki akışla sınırlıydı ve ürünün temel kritik yolculuğu etkilemedi. Olay tam karara kadar yaklaşık 30 dakika sürdü. Kök Sebep ve Karar Kök nedeni, mesaj teslimat ve doğrulamadan sorumlu kuyrukların işlenmesine ilişkin kritik bir disk eşine ulaşan mesajlaşma kümesinden birinde depolama basıncı olarak tespit edildi. Mühendislik ekibi, kümenin depolama kapasitesini yaklaşık 10:59 AM'de artırdı ve kuyruklara ve izleme göstergelerinin dakikalar içinde normalleşmesine izin verdi. Çevre tam iyileşme doğrulanana kadar izlendi ve olay 11:20 AM'de kapatıldı. Komünizm ve Sonraki Adımlar Mühendislik ekibi bu tür bir bozulma için uyarıları ve önceliklendirme kriterlerini inceleyecek, çünkü uyarılar sorunu doğru bir şekilde tanımladı, ancak sorumlu takıma otomatik escalasyon akışı geliştirilebilir. A detailed postmortem hazırlanmakta ve önümüzdeki günlerde paylaşılacaktır.

    4. 3 Ağustos 2026 12:14 UTCpostmortem

      **Summary** 16 Temmuz 2026, 10:12 AM ve 11:10 AM \ (Brasília zamanı) arasında, mesajlaşma ve kimlik doğrulama hizmeti yaklaşık 58 dakika boyunca bozuldu. Sebep mesaj kuyruk kümesindeki düğümlerden birinde disk saturasyondu, bu da tüm yayıncılara ulaşmada otomatik olarak tüm yayıncıları engelledi, kuyruktaki 33 bin mesaja neden oldu. Etki, SMS ve e-posta yoluyla kimlik doğrulama bağlantılarının teslim edilmesini etkiledi ve Unico People kabul portalında son kullanıcı kimlik doğrulama akışı. **Impact** SMS veya e-posta yoluyla kimlik doğrulama bağlantıları bekleyen kullanıcılar onları dönem boyunca almadılar. Kabul portalında kimliklendirmeye çalışan bir insan yönetim ürünü kullanıcıları da hizmete erişemedi. Etkisi, kümenin diski genişletildikten sonra bulundu. **Root Cause** Kök nedeni mesaj işleme akışında tespit edildi: aşırı büyük maaş yükleri - gereksiz verileri içeren bir denetim bileşeni tarafından üretilen - mesaj kuyruk kümesi tarafından kabul edilen boyut sınırı aştı. Her girişimde determinist olarak reddedildiği için, bu mesajlar tüm retries'ten sonra ölü kuyruklara yollandı. Bu kuyruklar sona ermedi ya da otomatik temizlik politikası yoktu, son zamanlarda bir araya gelme mesajlarına neden oldu ve kümenin disk alanını yoğun olarak tüketti. **Resolution** Kümenin diski, kuyrukları ve küme metrikleri hemen normalleştirmiş olan node başına 500 GB'ye genişletildi. Servis 11:10'da normale döndü. Yapısal kök nedeni - ölü kuyruklardaki sonlu birikimi - ele alınması gereken bir takip öğesi olarak kalır. **Lessons Learned** Olay, sorunun kökünü incelemeden sadece semptom \ (disk saturasyon\) ele geçirmeyi güçlendiriyor. Bir yaşam döngüsü politikasının yokluğu (TTL/expiration\) ölü kuyruklar için ve yayınlamadan önce ödeme yükü büyüklüğünin eksikliği, düzeltilmesi gereken iki merkezi yapısal boşluktır. Ek olarak, konunun düşük öncelikli olarak sınıflandırıldığı uyarı, uyarının tetiklendiği ve olayın resmi açılışı arasında yaklaşık 38 dakika gecikmesine neden oldu - kritik bir hizmet bozulması için kabul edilemez bir aralığı.

    Resmî olay güncellemesinden otomatik olarak çevrilmiştir.

    ID CLOUD yeteneklerini etkileyen enstability

    Başlangıç 13 Temmuz 2026 12:30 UTC · 1h 16m

    OutageBüyük çaplı olay
    Etkilenen bileşenler
    APIAPIAPI
    1. 13 Temmuz 2026 12:51 UTCidentified

      Sevgili Müşteri, Kimlik doğrulama kapasitesinde bir istikrarsızlığı tespit ettik, IDCloud taleplerinin küçük bir kısmında bir hata ürettik. Mühendislik ekibimiz zaten teşhis için seferber edilir ve hizmeti mümkün olduğunca kısa sürede normalleştirmek için kök nedenini tanımlamak için çalışmaktadır. Bu zamanda, teknik ekip, etkisini azaltmak için veri katmanımızda ayrıntılı analiz yürütüyor. Daha fazla güncellemenin kısa sürede gönderilmesini güçlendiriyoruz.

    2. 13 Temmuz 2026 13:06 UTCmonitoring

      Sevgili Müşteri, Mühendislik ekibimiz, kimlik doğrulama kapasitesindeki istikrarsızlığı çözmek için eylemleri belirledi ve IDCloud isteklerinin küçük bir kısmında bir hata üretti. Bu zamanda, teknik ekip veri katmanımızda ayrıntılı analiz yürütüyor ve çevreyi izlemeye devam ediyor. Daha fazla güncellemenin kısa sürede gönderilmesini güçlendiriyoruz.

    3. 13 Temmuz 2026 13:47 UTCresolved

      Yönetici Özeti ve Etkisi 13 Temmuz 2026'da, kimlik doğrulama yeteneğimizde bir istikrarsızlığı tespit ettik, kimlik doğrulama yeteneğimizdeki hataları en az sayıda IDCloud isteğinde üreterek, çoklu kimlik doğrulama akışlarını etkileyen. Sorun, 9:27 AM BRT civarında otomatik kullanılabilirlik uyarıları ile tespit edildi, hatalarda hafif bir artış zaten yaklaşık 8:00 AM BRT'den fark edildi ve 9:07 AM BRT civarında başlayan önemli bir kötüleme, yaklaşık 9:49 AM BRT'ye ulaştı. Kök Sebep ve Karar Kök nedeni, oturum token imzası geçerliliği olan bir iç doğrulama bileşenine uygulanan kademeli bir değişim olarak tespit edildi. Kök nedeni doğrulandıktan sonra, mühendislik ekibi değişikliği tekrarladı ve hizmet kullanılabilirliği normale döndü. Etkisin en kritik aşaması yaklaşık 44 dakika sürdü. Komünizm ve Sonraki Adımlar Mühendislik, bu tür bir rollout sırasında otomatik geri dönüş mekanizmaları da dahil olmak üzere kritik kimlik doğrulama bileşenlerini etkileyen kademeli akışlar için iyileştirmeleri değerlendirmektedir. Detaylı bir postmortem, bir sonraki adım olarak içsel olarak paylaşılması bekleniyor.

    4. 20 Temmuz 2026 22:47 UTCpostmortem

      # Postmortem: Authentication Flow Instability **Incident date:** July 13, 2026 **Impact süresi:** ~44 dakika # # # Özet 13 Temmuz 2026'da, platformun kimlik doğrulama akışlarında kullanılabilir bir bozulma tespit ettik. Olay, güvenlik jetonlarının geçerlileştirilmesinden sorumlu bir iç bileşenin yuvarlanması sırasında tanıtıldı. Sebep, operasyonları ekiplerimiz tarafından teşhis edildi ve birkaç dakika içinde yenileme sistemi istikrarını geri getirdi. ## Effects Regreasyon yaklaşık 44 dakika sürdü ve aynı anda platformda birden fazla kimlik doğrulama akışı etkiledi, müşteri odaklı hizmetlerde yaklaşık% 0.9 oranında bir hata oranına yol açtı. Bu dönemde, bazı son kullanıcılar dengesizliğe maruz kaldı ve genel hata mesajları \(HTTP 500\) gerçekleştirmeye çalışırken gördü. Olay 44 dakika sürdü olsa da, gecikmiş ve nonavailability arasında dalgalandı. # # # Root Cause Başarısızlık, güvenlik token geçerlilik bileşenine bir güncellemede ortaya çıkan bir yazılım hatasına neden oldu, bu nedenle farklı versiyonları çalışan örnekler arasında yetersizlik gösterdi. Bu yetersizlik test ortamlarında tespit edilmedi, çünkü farklı versiyonların eş zamanlı, paralel yürütülmesi gerekiyordu. Ek olarak, iç uç noktası, doğrulama başarısız olduğunda bile bir HTTP başarı cevabı geri döndü, bu da sorunu tespit etmekten otomatik dağıtım izleme sistemlerini engelledi ve otomatik olarak yuvarlanmayı bıraktı. ## Karar Sebep tespit edildikten sonra, on-call ekibi etkilenen bileşenden bir rollback idam etti, hemen doğrulama akışlarının kullanılabilirliğini geri getirdi. Olay otomatik SLO uyarıları birkaç dakika içinde tespit edildi ve escalation olayın tam teşhisini ve mitigationunu sağladı. # # # Dersler Öğrenildi Otomatik dağıtımların otomatik geri dönüşlerini tetiklemek için iç uç noktaların HTTP yanıt davranışını ayarlayacağız ve müşteriye ulaşmadan önce maskelenmeyi önlemek için hataları standartlaştıracağız. # # # Sürekli İyileştirmeye Bağlılık Bu gibi olaylar, platform güvenilirliğini sürekli geliştirmek için taahhüdümüzü güçlendiriyor. Her olayı bir öğrenme fırsatı olarak tedavi ediyoruz, süreçlerimizi, algılamayı ve önleme mekanizmalarımızı gözden geçiriyoruz ve sürekli olarak daha sağlam mühendislik uygulamalarına yatırım yapıyoruz. Amacımız, tüm müşterilerimiz için kullanılabilirlik ve şeffaflığı artırmayı sürdürmektir. Unico Team.

    Resmî olay güncellemesinden otomatik olarak çevrilmiştir.

    ID CLOUD yeteneklerini etkileyen enstability

    Başlangıç 10 Temmuz 2026 16:43 UTC · 1h 14m

    IssuesKüçük çaplı olay
    Etkilenen bileşenler
    APIAPIAPISDKAPIIDTrust | APIAPI
    1. 10 Temmuz 2026 16:43 UTCinvestigating

      Şu anda IDCLOUD yeteneklerinde istikrarsızlık yaşıyoruz. Teknik ekibimiz zaten kök nedenini araştırıyor. Güncellemeleri en kısa sürede daha fazla bilgi mevcut olacak.

    2. 10 Temmuz 2026 17:12 UTCidentified

      Bazı temel doğrulama ve risk analiz API'lerimiz için geçici veya geç saatlere neden olabilecek bir istikrarsızlığı tespit ettik. Etkilenen Hizmetler: Kimlik ve Geçerlilik: Kimlik Doğrulama, 1:1 Geçerlilik, Serpro Benzerlik Returnity Risk ve dolandırıcılık: Risk Puanı, Dolandırıcı Risk Sınıflandırması - Dokümantasyon ve Yaşam: Doküman Reuse & catch, Liveness Mevcut Durum ve Sonraki Adımlar: Mühendislik ekibimiz zaten tamamen meşgul ve kök nedenini araştırıyor. Davranışı aktif olarak izole etmek ve normal işlemleri mümkün olduğunca çabuk geri getirmek için çalışıyoruz.

    3. 10 Temmuz 2026 17:25 UTCmonitoring

      Şimdiki Durum ve Sonraki Adımlar Dava eylemleri başarıyla uygulandı ve sistem şimdi istikrarlı. Bu zamanda, Mühendislik ekibimiz sürekli olarak istikrar ve normal operasyonları sağlamak için platformun performansını takip ediyor. Bu olay sırasında sabrınız ve anlayışınız için teşekkür ederiz. Hizmetlerimiz artık normal olarak çalışmalıdır.

    4. 10 Temmuz 2026 17:57 UTCresolved

      Yönetici Özeti ve Etkisi 10 Temmuz 2026'da 1:21 PM ve 2:16 PM (Brasília Time) arasında, süreç yaratım akışı ve ilgili yolculukların kullanılabilirliği konusunda bir dalgalanma tespit ettik ve ana API'lerimizin hata oranına yol açtı. - Etkisi Kapsamı: Olay bu aralıkta belirli yolculukların varlığını yalnızca etkiledi. Bu dönemde hata oranlarında artış deneyimleyen müşteriler etkilenmedi. - Data Integrity: İşlenmiş bilgilerin bütünlüğü veya güvenliği konusunda uzlaşma yoktu. - Mitigation: İlk bir çalışma birkaç dakika içinde uygulandı, hataların hacmini durdurdu. Servis, 2:16 PM'de tamamen normalleştirildi, Mühendislik ve İzleme takımlarımızdan stabilite onayını takip etti. Kök Sebep Olay bir altyapı hizmetinde dengesizliğe yol açtı, ilgili iç bileşenlerin başlangıçta aniden bir bozulma izledi. Komünizm ve Sonraki Adımlar Platformumuzun direncine derinden bağlıyız. Olay sırasında başlatılan düzeltici ve önleyici eylemler zaten bu doğanın gelecekteki olaylarının riskini azaltmak için izleniyor. - Postmortem: ayrıntılı bir teknik rapor (Postmortem) yakında paylaşılacaktır, tam zamanlı, mimari analiz ve tanımlı tarihlerle uzun vadeli bir eylem planı içeren. Etki ve istikrarsızlığa karşı içtenlikle özür dileriz. Müşterilerimizin güveni en yüksek önceliğimizdir ve hizmetlerimizin mükemmelliğini sağlamak için sürekli çalışmaya devam ediyoruz. Sincerely, Unico Team

    5. 14 Temmuz 2026 14:08 UTCpostmortem

      **Summary** 10 Temmuz 2026'da, 1:21 PM ve 2:09 PM \(Brasília zamanı) ile süreç yaratımında hata oranı yaklaşık% 9 dakika boyunca yaklaşık% 11 arttı, 2:09 PM'ye kadar kesintisiz olarak bozulmaya devam etti. Olay, altyapı yapılandırma yönetimi bileşenindeki bir istikrarsızlıktan kaynaklanıyordu, bu da biyometrik servis pods'ı doğru bir şekilde başlatmayı engelledi. Etki, önceden gelişmekte olan bir bellek tüketim davranışı tarafından geliştirilmişti (ki bu pod yeniden başlatmasının frekansı arttı) ve yeni örneklerin yaratılmasını tetikleyen bir trafik artışı tarafından - tüm bunlar konfigürasyon bileşeninin istikrarsızlığı penceresi sırasında başlatamadı. **Impact** Birden çok akış aynı anda etkilendi - süreç oluşturma, doğrulama, biyometrikler, ödemeler ve iç işlemler dahil - tüm hizmetlerde biyometrik motora bağlı hataları ile. Onun zirvesinde, hata oranı% 11'e ulaştı. Mevcut biyometrik servis pods sayısı, olayın en kritik penceresi sırasında hem üretim kümelerinde sıfıra düştü. **Root Cause** Kök nedeni, biyometriks servisinin başlangıç mantığında optimizasyon fırsatıyla ilgiliydi: Uygulama, altyapı yapılandırma yönetimi bileşeninin önyükleme sırasında bir başarısızlık iade etmesi durumunda, önbellek veriler bir düşüş olarak kullanılabilirken bile ortaya çıktı. Bu mantık, kalıcı bir yapılandırma hatası olarak aynı şekilde geçici bir iletişim kesintisine yol açtı, geri dönüş önbelleği tam olarak gerekli olduğu anda ortaya koydu. yapılandırma bileşeni dengesiz hale geldiğinde, her pod yeniden başlatmaya çalışır - hafıza basıncı veya otoskaling nedeniyle - başarısızlık döngüsünde sıkıştı, ilkleme sürecini tamamlayamadı. **Resolution** Ekip, etkilenen bileşenlerinden biri tarafından ilk etkisini içeriyordu ve bu da yaklaşık 9 dakika içinde hata artışını durdurdu. Yapı yönetimi bileşeninin stabilizasyonu takip edildi, pods'un normalde geri dönmesine izin verdi. Bir acil düzeltme hazırlandı ve aynı gün dağıtıldı, açılışını bloke eden kısıtlayıcı doğrulamayı ortadan kaldırmak - geri dönüş önbelleğinin şeffaf bir şekilde ileri sürülmesini sağlamak. **Lessons Learned** Olay, hizmetin dayanıklılık mekanizmasının - geri dönüş önbelleğinin - mimaride var olduğunu ortaya koydu, ancak çevre erişilebilirliği üzerinde sıkı veri doğrulamaya öncelik veren başlangıç mantığı tarafından tarafsızleştirildi. Kritik hizmetler için inisiyatif yolları, altyapı bileşenlerini destekleyen, operasyonel sürekliliği sağlamak için mükemmel bir şekilde dekore etmek için tasarlanmıştır. ** Stability ve Sürekli İyileştirme ile ilgili olarak Hizmetlerimizin sürekli olarak en yüksek verimlilik, güvenlik ve güvenilirlik seviyelerinde çalışmasını sağlamak için altyapımızın sağlamlığına ağır yatırım yapmaya devam edeceğiz. Unico Team.

    Resmî olay güncellemesinden otomatik olarak çevrilmiştir.

    Instabilidade na Integração das capacidades que utilizam IDScore, ID Unico (Verificação de Identidade), ID Trust (Alerta de Comportamento) e ID Live (Prova de Vida)

    Başlangıç 7 Temmuz 2026 21:22 UTC · 53m

    OutageBüyük çaplı olay
    Etkilenen bileşenler
    APIAPIIDTrust | APIAPI
    1. 7 Temmuz 2026 21:22 UTCidentified

      Prezado Cliente, Identificamos uma latência seguida de indisponibilidade na criação de processos de algumas capacidades da Unico. Devido a isso, uma parcela de nossos clientes pode perceber lentidão ou aumento de erros em operações que envolvem o ID Score, ID Unico (Verificação de Identidade), ID Trust (Alerta de Comportamento) e ID Live (Prova de Vida). Nossa equipe de engenharia já foi acionada e está trabalhando no diagnóstico da causa raiz para normalizar o serviço o quanto antes. No momento, o time técnico realiza análises detalhadas em nossa camada de dados para mitigar os impactos. Comprometemo-nos a enviar novas atualizações em breve assim que tivermos novidades. Equipe Unico.

    2. 7 Temmuz 2026 21:32 UTCmonitoring

      Prezado Cliente, Informamos que nossa equipe de tecnologia identificou e solucionou a instabilidade que afetou o tempo de resposta das requisições para retorno das capacidades de ID Score, ID Unico (Verificação de Identidade), ID Trust (Alerta de Comportamento) e ID Live (Prova de Vida). Dentro de alguns dias compartilharemos maiores detalhes através de um Postmortem. Pedimos desculpas pelo transtorno e nos colocamos à disposição para sanar dúvidas através dos nossos canais de atendimento. Atenciosamente, Equipe Unico!

    3. 7 Temmuz 2026 22:14 UTCresolved

      Prezado Cliente, Incidente resolvido. Nossa equipe identificou as causas do problema e realizou as ações para que este incidente fosse solucionado. Dentro de alguns dias compartilharemos maiores detalhes através de um Postmortem. Pedimos desculpas pelo transtorno e nos colocamos à disposição para sanar dúvidas através dos nossos canais de atendimento. Atenciosamente, Equipe Unico!

    4. 13 Temmuz 2026 21:18 UTCpostmortem

      **Post-Mortem: Availability Instability in Identity Processing** **Summary** On two occasions on consecutive days in July 2026, the identity processing service experienced brief drops in availability. These were caused by saturation in a shared database that supports part of the verification flow. Both events were quickly identified by the monitoring teams, mitigated within approximately 30 minutes, and resolved with zero data loss. **Impact** Incident 1 — July 6, 2026, from 13:00 to 13:34 \(BRT\): A sudden and legitimate spike in request volume overloaded the database replica serving the service. Clients using services dependent on verification score generation experienced slowness, as requests were automatically retried instead of returning errors. Verification processes continued to complete successfully, albeit with delays. Incident 2 — July 7, 2026, from 17:52 to 18:05 \(BRT\): A database query lacking a row-return limit was triggered by an edge-case data pattern, saturating the CPU of the same database replica. This increased latency and, for a short window \(around 13 minutes\), caused errors in certain steps of the verification flow for a subset of clients. In both cases, the impact was limited to the windows described above, without total service downtime and with zero data loss. **Root Cause** Both incidents share the same underlying cause: CPU saturation on a relational database replica that serves multiple capabilities of the identity verification service. In the first incident, a specific request volume surged roughly 10x within a few minutes, exceeding the provisioned capacity for the replica. The database infrastructure was not scaled to sustain the peak, leading to processing exhaustion \(CPU scheduling contention\) and a subsequent cascade of timeouts in dependent services. In the second incident, a specific query lacked a limit on returned rows. When executed for a record with an unusual volume of associated images, the query triggered a full table scan and sort, consuming all available processing power on the replica. This effect was amplified by two internal mechanisms that, combined, tripled the number of queries generated per request. **Resolution** In both incidents, the operations teams: Vertically scaled a secondary database replica and redirected traffic to it via a DNS update; Temporarily disabled mechanisms that were generating additional database load; Monitored the stabilization of availability metrics before declaring the incident resolved; Following the second incident, applied a definitive fix to the problematic query \(enforcing a limit on returned records\) and initiated a data-cleansing process for non-standard records that could replicate the scenario. **Lessons Learned** These incidents reinforced the need for defensive and systematic infrastructure design, applying explicit limits and pagination on database queries to eliminate latent risks under atypical traffic. It became evident that component migrations can inadvertently strip away implicit protections against overload. This makes the implementation of declarative resilience mechanisms—such as proper timeouts, circuit breakers, and connection limits—indispensable. Additionally, the scenario highlighted the importance of investigating the root cause of recurring saturation patterns rather than relying solely on point-in-time mitigations, as well as the urgency of monitoring and refactoring architectures that multiply database calls per request to mitigate load amplification risks before they become critical. **Closing** We acknowledge the impact these instabilities caused and apologize for any inconvenience experienced by our clients and partners during these windows. Transparency regarding what happened is part of our commitment to those who trust our platform. The actions taken in response to these incidents prioritize reinforcing our environment's stability and reducing the likelihood of recurrence. We continue to invest heavily in observability, infrastructure resilience, and incident response processes to ensure an increasingly reliable service. Unico Team

    Instabilidade na Integração das capacidades que utilizam IDScore

    Başlangıç 6 Temmuz 2026 16:20 UTC · 1h 6m

    OutageBüyük çaplı olay
    Etkilenen bileşenler
    APIAPI
    1. 6 Temmuz 2026 16:29 UTCidentified

      Prezado Cliente, Identificamos uma instabilidade na capacidade de verificação de identidade com orquestração com IDScore, que está apresentando lentidão no retorno do Score de autenticação de determinados processos. Clientes que utilizam orquestração com o Trust podem enfrentar também cenários de erros em determinados processos devido a lentidão identificada. Nossa engenharia já está mobilizada para o diagnóstico e trabalhando na identificação da causa raiz para normalizar o serviço o mais breve possível. No momento, o time técnico realiza análises detalhadas em nossa camada de dados para mitigar o impacto. Reforçamos que novas atualizações serão enviadas em breve. Equipe Unico.

    2. 6 Temmuz 2026 16:51 UTCmonitoring

      Prezado Cliente, Informamos que nossa equipe de tecnologia identificou e solucionou a instabilidade que afetou o tempo de resposta das requisições para retorno do Score de autenticação. Dentro de alguns dias compartilharemos maiores detalhes através de um Postmortem. Pedimos desculpas pelo transtorno e nos colocamos à disposição para sanar dúvidas através dos nossos canais de atendimento. Atenciosamente, Equipe Unico!

    3. 6 Temmuz 2026 17:25 UTCresolved

      Prezado Cliente, Incidente resolvido. Nossa equipe identificou as causas do problema e realizou as ações para que este incidente fosse solucionado. Dentro de alguns dias compartilharemos maiores detalhes através de um Postmortem. Pedimos desculpas pelo transtorno e nos colocamos à disposição para sanar dúvidas através dos nossos canais de atendimento. Atenciosamente, Equipe Unico!

    4. 13 Temmuz 2026 21:17 UTCpostmortem

      **Post-Mortem: Availability Instability in Identity Processing** **Summary** On two occasions on consecutive days in July 2026, the identity processing service experienced brief drops in availability. These were caused by saturation in a shared database that supports part of the verification flow. Both events were quickly identified by the monitoring teams, mitigated within approximately 30 minutes, and resolved with zero data loss. **Impact** Incident 1 — July 6, 2026, from 13:00 to 13:34 \(BRT\): A sudden and legitimate spike in request volume overloaded the database replica serving the service. Clients using services dependent on verification score generation experienced slowness, as requests were automatically retried instead of returning errors. Verification processes continued to complete successfully, albeit with delays. Incident 2 — July 7, 2026, from 17:52 to 18:05 \(BRT\): A database query lacking a row-return limit was triggered by an edge-case data pattern, saturating the CPU of the same database replica. This increased latency and, for a short window \(around 13 minutes\), caused errors in certain steps of the verification flow for a subset of clients. In both cases, the impact was limited to the windows described above, without total service downtime and with zero data loss. **Root Cause** Both incidents share the same underlying cause: CPU saturation on a relational database replica that serves multiple capabilities of the identity verification service. In the first incident, a specific request volume surged roughly 10x within a few minutes, exceeding the provisioned capacity for the replica. The database infrastructure was not scaled to sustain the peak, leading to processing exhaustion \(CPU scheduling contention\) and a subsequent cascade of timeouts in dependent services. In the second incident, a specific query lacked a limit on returned rows. When executed for a record with an unusual volume of associated images, the query triggered a full table scan and sort, consuming all available processing power on the replica. This effect was amplified by two internal mechanisms that, combined, tripled the number of queries generated per request. **Resolution** In both incidents, the operations teams: Vertically scaled a secondary database replica and redirected traffic to it via a DNS update; Temporarily disabled mechanisms that were generating additional database load; Monitored the stabilization of availability metrics before declaring the incident resolved; Following the second incident, applied a definitive fix to the problematic query \(enforcing a limit on returned records\) and initiated a data-cleansing process for non-standard records that could replicate the scenario. **Lessons Learned** These incidents reinforced the need for defensive and systematic infrastructure design, applying explicit limits and pagination on database queries to eliminate latent risks under atypical traffic. It became evident that component migrations can inadvertently strip away implicit protections against overload. This makes the implementation of declarative resilience mechanisms—such as proper timeouts, circuit breakers, and connection limits—indispensable. Additionally, the scenario highlighted the importance of investigating the root cause of recurring saturation patterns rather than relying solely on point-in-time mitigations, as well as the urgency of monitoring and refactoring architectures that multiply database calls per request to mitigate load amplification risks before they become critical. **Closing** We acknowledge the impact these instabilities caused and apologize for any inconvenience experienced by our clients and partners during these windows. Transparency regarding what happened is part of our commitment to those who trust our platform. The actions taken in response to these incidents prioritize reinforcing our environment's stability and reducing the likelihood of recurrence. We continue to invest heavily in observability, infrastructure resilience, and incident response processes to ensure an increasingly reliable service. Unico Team

    Instabilidade no canal de atendimento via WhatsApp

    Başlangıç 2 Temmuz 2026 22:04 UTC · 3h 10m

    IssuesKüçük çaplı olay
    Etkilenen bileşenler
    Whatsapp
    1. 2 Temmuz 2026 22:04 UTCidentified

      Prezado Cliente, Estamos analisando uma degradação em nossa plataforma de atendimento aos clientes, causando instabilidade no atendimento via Whatsapp. Orientamos nossos clientes a enviarem mensagens via formulário, e-mail ou nos contatarem pelo nosso webchat como alternativa de contato síncrono https://business.unico.io/hc/pt-br Em breve retornaremos com novas atualizações.

    2. 2 Temmuz 2026 22:05 UTCidentified

      We are continuing to work on a fix for this issue.

    3. 3 Temmuz 2026 00:04 UTCmonitoring

      Prezado Cliente, Identificamos que a instabilidade que afetava a nossa plataforma de gerenciamento de atendimento foi corrigida. As ações de correção técnica foram executadas com sucesso pelo nosso parceiro e a comunicação do canal via WhatsApp já se encontra reestabelecida. Estamos em monitoramento assistido para garantir a total estabilidade e performance do ambiente. Pedimos desculpas pelo impacto causado em sua operação. Atenciosamente, Equipe Unico

    4. 3 Temmuz 2026 01:14 UTCresolved

      Prezado Cliente, O incidente que causava instabilidade no canal de atendimento via WhatsApp foi totalmente resolvido. A causa do problema foi identificada e a correção definitiva já foi aplicada em produção junto ao nosso parceiro de tecnologia. A integração com a plataforma foi restabelecida e o nosso time de atendimento já está operando e respondendo normalmente. Agradecemos a parceria e a paciência de todos durante o período de manutenção do canal. Atenciosamente, Equipe Unico

    5. 13 Temmuz 2026 20:36 UTCpostmortem

      ### **Postmortem: WhatsApp Support Channel Instability** #### **Summary** On July 2, 2026, an instability affected our WhatsApp customer support channel. During this period, automated messages from our virtual assistant \(bot\) were not being delivered to end-users. Service was fully restored after the identification and rollback of a system change within our technology partner’s environment. #### **Impact** This incident exclusively impacted customers attempting to reach support through our WhatsApp channel. While automated messages managed by the bot failed to deliver, manual messages sent by human agents continued to operate normally. Our alternative support channels, such as email and webchat, remained fully operational and were communicated as active alternatives during the instability. #### **Root Cause** The root cause was an update deployed in the messaging service managed by our technology partner. This update introduced an incompatibility within the partner's own production environment configurations. This supplier-side infrastructure failure disrupted the automated communication flow, preventing the bot from delivering messages. #### **Resolution** Our partner's technical team investigated the issue within their environment and traced the failure back to the recently deployed update. The resolution applied by the vendor consisted of performing an immediate rollback to the previous stable version of their messaging service. Once the partner completed this rollback, message delivery was successfully restored, and our support channel returned to normal operations. #### **Lessons Learned** This incident reinforced the importance of maintaining an agile contingency and communication strategy to quickly redirect our customers to alternative channels \(such as webchat and forms\) during third-party service outages. Additionally, it highlighted the need to continuously align with our key vendors regarding the requirement for more rigorous validation and testing protocols in their own environments before promoting updates that can impact our operations.

    Instabilidade no acesso à plataforma SafeDoc

    Başlangıç 26 Haziran 2026 03:30 UTC · 0m

    Pending
    1. 26 Haziran 2026 14:10 UTCresolved

      Prezado cliente, Entre 00:17 e 10:40 de 26/06, identificamos uma instabilidade que causou falhas de acesso na plataforma SafeDoc (através do endereço seu.acesso.io) para um grupo específico de clientes. Durante esse período, alguns usuários enfrentaram dificuldades no fluxo de login, processamento e visualização de imagens e arquivos. A origem do comportamento esteve relacionada a uma atualização programada de manutenção executada na noite de 25/06, que gerou incompatibilidade na parametrização de algumas instâncias do sistema. Nossos times de Engenharia e SRE identificaram o cenário e aplicaram as correções e ajustes de configuração necessários nas instâncias afetadas. O serviço foi restabelecido e está operando normalmente. Lamentamos o ocorrido e seguimos monitorando o comportamento da plataforma para garantir a estabilidade das operações. Em caso de dúvidas, nossa equipe de CX está à disposição. Equipe Unico.

    2. 3 Temmuz 2026 18:22 UTCpostmortem

      **Resumo** No dia 26 de junho de 2026, entre 00:17 e 10:40 \(horário de Brasília\), um grupo de clientes enfrentou instabilidade que afetou o acesso a alguns de nossos serviços. A falha se manifestou em erros de login, processamento e acesso a arquivos. Nossa equipe de engenharia identificou a causa e restaurou o serviço para todos os clientes afetados. **Impacto** Durante o incidente, que durou aproximadamente 10 horas e 23 minutos, 24 clientes ficaram impossibilitados de utilizar funcionalidades essenciais de nossos serviços, impactando suas operações. O acesso foi completamente restabelecido às 10:40 do dia 26 de junho de 2026. **Causa Raiz** A causa raiz do incidente foi uma falha durante um processo de atualização programada de sistema, que ocorreu na noite do dia 25 de junho. A atualização de configuração não foi aplicada corretamente em um subconjunto de servidores, fazendo com que o sistema fizesse referência a dependências de software desatualizadas e incompatíveis. Essa falha impediu a comunicação correta com serviços de armazenamento em nuvem e de autenticação, resultando nos erros observados pelos clientes. A ausência de validação automatizada pós-implantação e de alertas centralizados para este tipo de erro de configuração impediu a detecção proativa do problema. **Resolução** Assim que o incidente foi reportado na manhã do dia 26 de junho, nossa equipe de prontidão foi acionada. Foi identificado que a falha estava relacionada a uma implantação incorreta de arquivos de configuração. As equipes de engenharia aplicaram as correções necessárias em todas as instâncias afetadas, restaurando a funcionalidade completa dos serviços. Após a aplicação da correção, foi realizada uma verificação completa para garantir que todos os sistemas estivessem operando normalmente. **Lições Aprendidas** * Automação na validação: Implementações em larga escala exigem verificações automatizadas pós-implantação para garantir que todas as instâncias tenham sido atualizadas corretamente e de forma consistente. * Observabilidade centralizada: É fundamental garantir que os registros de erros de todas as aplicações sejam transmitidos para uma plataforma centralizada, permitindo a detecção rápida de anomalias, mesmo que a falha afete a própria capacidade de comunicação da aplicação. Estamos comprometidos com a confiabilidade de nossos serviços e continuaremos trabalhando para fortalecer nossos sistemas e processos.

    Instabilidade parcial aos clientes México no Serviço de Integração IDTrust

    Başlangıç 24 Haziran 2026 18:20 UTC · 33m

    OutageBüyük çaplı olay
    Etkilenen bileşenler
    IDTrust | API
    1. 24 Haziran 2026 18:20 UTCidentified

      Prezado Cliente, Detectamos um impacto nas requisições com o fluxo do IDTrust, causando instabilidade aos clientes Mexico que utilizam essa capacidade. A nossa equipe de tecnologia está analisando o ambiente e as métricas para determinar a causa e a solução. Retornamos em breve com atualizações. Atenciosamente, Equipe Unico

    2. 24 Haziran 2026 18:31 UTCmonitoring

      Prezado Cliente, Nossa equipe identificou as causas do problema e realizou as ações para que este incidente fosse solucionado. Dentro de alguns dias compartilharemos maiores detalhes através de um Postmortem. Pedimos desculpas pelo transtorno e nos colocamos à disposição para sanar dúvidas através dos nossos canais de atendimento. Atenciosamente, Equipe Unico!

    3. 24 Haziran 2026 18:53 UTCresolved

      Prezado Cliente, Incidente resolvido. Nossa equipe identificou as causas do problema e realizou as ações para que este incidente fosse solucionado. Dentro de alguns dias compartilharemos maiores detalhes através de um Postmortem. Pedimos desculpas pelo transtorno e nos colocamos à disposição para sanar dúvidas através dos nossos canais de atendimento. Atenciosamente, Equipe Unico!

    4. 13 Temmuz 2026 19:27 UTCpostmortem

      **Summary** On June 24, 2026, between 2:55 PM and 3:26 PM \(Brasília time\), the availability indicator for the process creation flow dropped below 95%, with a total duration of approximately 31 minutes. The incident was caused by an instability in an infrastructure provider used in the risk assessment flow, which began returning errors and latency above expected levels. The impact was concentrated on users from Mexican market clients. **Impact** Users of the process creation and authentication flows that relied on the risk assessment step received timeout errors during the period. The impact was more severe for Mexican market clients but also affected authentication flows for other clients. **Root Cause** The root cause was an instability in the infrastructure provider responsible for the risk assessment step. The provider began operating with latency well above normal and returning errors, causing requests that depended on this step to become blocked and propagate failures to the process creation and authentication flows. Internal services were unable to isolate the impact of the provider's degradation, resulting in widespread unavailability for all users passing through this step. **Resolution** The infrastructure provider stabilized on its own at 3:16 PM. The team identified a timeout configuration need during the incident and opened a correction with explicit values. The incident was closed at 3:50 PM after stability was confirmed. **Lessons Learned** The incident highlighted the need to strengthen isolation mechanisms between internal services and infrastructure providers, so that isolated instabilities do not propagate to end users. As follow-ups, the team identified improvements in the resilience of the affected flows and in the documentation of critical dependencies, aiming to reduce response time and impact in future occurrences of a similar nature.

    Instabilidade no fluxo de onboarding - By Unico e IDPay

    Başlangıç 23 Haziran 2026 01:24 UTC · 1h 18m

    OutageBüyük çaplı olay
    Etkilenen bileşenler
    Messaging SystemAPI
    1. 23 Haziran 2026 01:24 UTCinvestigating

      Prezado Müşterilere, Nossa monitoração proativa detectou um comportamento düzensiz no ID Pay e no fluxo de onboarding do ByUnico. Embora bir causa exata ainda esteja sob yatırımigação, pode se showar como lentidão ou Intermitência noço. Bir donat de tecnologia está executando todos os procedimentos de Diagnóstico no environmente para identificar as causas. Em breve retornamos com atualizaç330es.

    2. 23 Haziran 2026 01:39 UTCidentified

      Prezado Müşterilere, Nossa ainda está yatırımigando a causa raiz do problema. Em breve traremos mais inualizaç330es. Agradcemos bir compreensão.

    3. 23 Haziran 2026 01:53 UTCidentified

      Prezado Müşterilere, Informamos que nossa identificou a causa da instabilidade e está ativamente trabalhando na aplicação da Solução. Seguimos empenhados em restabelecer o, o mais hızlıamente pozsível e manteremos você, sobre a homeolução. Novas inualizaç330es serão enviadas em breve.

    4. 23 Haziran 2026 02:18 UTCmonitoring

      Prezado Müşterilere, Nossa, causas'ın soruna e realizou'yu Olympuses para que este evente fosse solucionado olarak dondurdu. Dentro de alguns diyartilharemos maiores detalhes através de um Postmortem. Pedimos desculpas pelo transtorno e nos colocamos à disposição paranr dúvidas através dos nosos canais de atendimento. Atenciosamente, Equipe Unico!

    5. 23 Haziran 2026 02:41 UTCresolved

      Prezado Müşterilere, Nossa, causas'ın soruna e realizou'yu Olympuses para que este evente fosse solucionado olarak dondurdu. Dentro de alguns diyartilharemos maiores detalhes através de um Postmortem. Pedimos desculpas pelo transtorno e nos colocamos à disposição paranr dúvidas através dos nosos canais de atendimento. Atenciosamente, Equipe Unico!

    6. 14 Temmuz 2026 13:58 UTCpostmortem

      **Summary** 22 Haziran 2026'da, 9:52 PM \ (Brasília zamanında), belge tasarrufu akışı veritabanında bir eşdeğer tanımlayıcı sınırın tükenmesi nedeniyle kullanılamaz hale geldi. O andan itibaren, tüm belge ekleme işlemleri başarısız olmaya başladı, birden çok bağımlı hizmete hataları katladı. Olay yaklaşık 86 dakika sürdü. **Impact** Birden çok kritik hizmet aynı anda etkilendi - akışlar, süreç yaratımı, kimlik doğrulama ve ödemeler dahil. Bazı akışlarda, kullanılabilirlik% 3'ün altına düştü. Müşteriler, belge tasarrufuna bağlı olan operasyonlara bağlı olarak başarısızlık veya gecikmelerle etkilendi. **Root Cause** Kök nedeni, veri tabanının artık yeni tanımlayıcılar üretmesine neden oldu, bu yüzden tüm ekleme işlemleri başarısız olmaya başladı. Bu sınıra yakın takip etmek için yapılandırılan bir izleme olmadığından, egzoz aniden ve önceden uyarı olmadan meydana geldi. **Resolution** Takım yaklaşık 20 dakika içinde kök nedenini tespit etti. Acil bir masyon olarak, öznitelik tanımlayıcısı aynı veri tipinin negatif yelpazesini kullanmak için yeniden yapılandırıldı, veritabanına herhangi bir yapısal değişikliği gerektirmeden yaklaşık 2.1 milyar değerinde ücretsiz olarak. Çözüm, üretime uygulanmadan önce daha düşük ortamlarda onaylanmıştır. Servis, düzeltmenin uygulanmasından kısa bir süre sonra stabilize etmeye başladı ve tam iyileşme onaylandıktan sonra izlendi. **Lessons Learned** Olay, yüksek hacimli tablolarda yer alan tablolar için izlemenin önemini vurgulamaktadır; ve haritalama ve belgeleme işlemleri, planlanan bakım olarak ele alınmasına izin veren erken uyarılarla; 8bay tanımlayıcı tanımlayıcı türleri üst sürümdeki tablolar için üst sürümdeki tablolar için, bu kontroller ile uygulama; ve haritalama ve belgeleme hizmetleri, etkinin büyüklüğüne ve gelecekteki olaylarda etkilenen kullanıcıların daha hızlı bir şekilde önceliklendirilmesi.

    Resmî olay güncellemesinden otomatik olarak çevrilmiştir.

    Instabilidade no canal de atendimento via WhatsApp

    Başlangıç 19 Haziran 2026 13:08 UTC · 6h 34m

    IssuesKüçük çaplı olay
    Etkilenen bileşenler
    Whatsapp
    1. 19 Haziran 2026 13:08 UTCinvestigating

      Prezado Cliente, Estamos analisando uma degradação em nossa plataforma de atendimento aos clientes, causando instabilidade no atendimento via Whatsapp. Orientamos nossos clientes a enviarem mensagens via formulário, e-mail ou nos contatarem pelo nosso webchat como alternativa de contato síncrono https://business.unico.io/hc/pt-br/p/help-u Em breve retornaremos com novas atualizações.

    2. 19 Haziran 2026 18:34 UTCmonitoring

      Prezado Cliente, Identificamos que a instabilidade que afetava a nossa plataforma de gerenciamento de atendimentos foi corrigida. As ações de correção técnica foram executadas com sucesso pelo nosso parceiro e a comunicação do canal via WhatsApp já se encontra reestabelecida. Neste momento, nosso time de engenharia e operações segue em monitoramento assistido para garantir a total estabilidade e performance do ambiente. Pedimos desculpas pelo impacto causado em sua operação. Atenciosamente, Equipe Unico

    3. 19 Haziran 2026 19:42 UTCresolved

      Prezado Cliente, O incidente que causava instabilidade no canal de atendimento via WhatsApp foi totalmente resolvido. A causa do problema foi identificada e a correção definitiva já foi aplicada em produção junto ao nosso parceiro de tecnologia. A integração com a plataforma foi restabelecida e o nosso time de atendimento já está operando e respondendo normalmente. Agradecemos a parceria e a paciência de todos durante o período de manutenção do canal. Atenciosamente, Equipe Unico

    4. 3 Temmuz 2026 20:36 UTCpostmortem

      **Sumário** No dia 19 de junho de 2026, identificamos uma instabilidade que afetou nosso canal de atendimento via WhatsApp. O incidente, que teve início aproximadamente às 09:00 e foi resolvido às 15:45 \(horário de Brasília\), impediu que nossos agentes acessassem as conversas dos clientes nessa plataforma. A causa raiz foi um problema técnico originado em um de nossos parceiros de tecnologia, que já foi corrigido. **Impacto** Durante o período do incidente, o atendimento aos clientes finais através do canal de WhatsApp foi impactado. Como alternativa, os clientes foram orientados a utilizar nossos outros canais de contato, como formulário, e-mail e webchat. As operações foram normalizadas no mesmo dia. **Causa Raiz** A investigação, conduzida em conjunto com nosso parceiro tecnológico responsável pela plataforma de gestão de conversas, revelou que a causa do incidente foi uma alteração de certificados de segurança em um sistema terceiro com o qual a plataforma se integra. Essa alteração invalidou o mecanismo de autenticação utilizado pelo serviço, impedindo a comunicação entre a plataforma de atendimento e o canal do WhatsApp. A detecção do problema foi reativa, pois a falha de autenticação não gerava alertas proativos e o ambiente de testes não utiliza os mesmos certificados do ambiente de produção, o que impediu a reprodução do erro em testes preliminares. **Resolução** Após a identificação do problema, a equipe de engenharia do nosso parceiro tecnológico atualizou os certificados de autenticação em seus sistemas para restabelecer a compatibilidade com a plataforma terceira. A correção foi aplicada e validada, normalizando o acesso dos nossos agentes às conversas e restaurando completamente o serviço de atendimento via WhatsApp às 15:45. **Lições Aprendidas** * É crucial manter uma comunicação ativa e monitorar os canais de parceiros tecnológicos para se antecipar a mudanças que possam impactar os serviços integrados. * Falhas de autenticação com serviços externos são um ponto crítico e devem possuir mecanismos de alerta específicos para permitir uma detecção e resposta mais rápidas, reduzindo o tempo de indisponibilidade. Estamos empenhados em garantir a estabilidade e a qualidade de nossos canais de atendimento e continuaremos a trabalhar em estreita colaboração com nossos parceiros para fortalecer a resiliência de nossos serviços.

    Instabilidade no envio de notificações whatsapp para usuários finais - IDCloud (By unico) & ID Pay

    Başlangıç 12 Haziran 2026 15:00 UTC · 3h 32m

    OutageBüyük çaplı olay
    Etkilenen bileşenler
    Messaging System
    1. 12 Haziran 2026 15:29 UTCidentified

      Prezado Cliente, Estamos acompanhando uma instabilidade na plataforma de mensageria de WhatsApp, junto à Meta, que está gerando indisponibilidade no envio de links para usuários finais nos produtos IDCloud (By unico) e ID Pay que utilizam o fluxo com o WhatsApp. Notificações via e-mail e sms estão funcionando normalmente. Maiores informações sobre incidente da Meta: https://metastatus.com/ Em breve retornaremos com novas atualizações.

    2. 12 Haziran 2026 17:03 UTCidentified

      Prezado Cliente, Seguimos acompanhando a instabilidade na plataforma de mensageria de WhatsApp, junto à Meta, que está gerando indisponibilidade no envio de links para usuários finais nos produtos IDCloud (By unico) e ID Pay que utilizam o fluxo com o WhatsApp. Notificações via e-mail e sms estão funcionando normalmente. Maiores informações sobre incidente da Meta: https://metastatus.com/ Em breve retornaremos com novas atualizações

    3. 12 Haziran 2026 18:17 UTCmonitoring

      Prezado Cliente, As ações corretivas para o incidente foram executadas junto ao nosso parceiro. Nosso time está em monitoramento assistido acompanhando a performance do ambiente. Pedimos desculpas pelo ocorrido e nos colocamos à disposição para sanar dúvidas através dos nossos canais de atendimento. Atenciosamente, Equipe Unico

    4. 12 Haziran 2026 18:31 UTCresolved

      Prezado Cliente, Incidente resolvido. As ações corretivas para o incidente foram executadas junto ao nosso parceiro. Nosso time está em monitoramento assistido acompanhando a performance do ambiente. Pedimos desculpas pelo ocorrido e nos colocamos à disposição para sanar dúvidas através dos nossos canais de atendimento. Atenciosamente, Equipe Unico

    Instabilidade no canal de atendimento via WhatsApp

    Başlangıç 12 Haziran 2026 14:58 UTC · 3h 3m

    OutageBüyük çaplı olay
    Etkilenen bileşenler
    Whatsapp
    1. 12 Haziran 2026 14:58 UTCidentified

      Prezado Cliente, Estamos analisando uma degradação em nossa plataforma de atendimento aos clientes, causando instabilidade no atendimento via Whatsapp. Orientamos nossos clientes a enviarem mensagens via e-mail ou nos contatarem pelo nosso webchat como alternativa de contato sincrono https://business.unico.io/hc/pt-br/p/help-u Em breve retornaremos com novas atualizações.

    2. 12 Haziran 2026 17:31 UTCmonitoring

      Prezado Cliente, As ações corretivas para o incidente foram executadas pelo nosso parceiro. Nosso time está em monitoramento assistido acompanhando a performance do ambiente. Pedimos desculpas pelo ocorrido Atenciosamente, Equipe Unico

    3. 12 Haziran 2026 18:00 UTCresolved

      Prezado Cliente, Incidente resolvido. as ações corretivas para o incidente foram executadas junto ao nosso parceiro. Nosso time está em monitoramento assistido acompanhando a performance do ambiente. Pedimos desculpas pelo ocorrido e nos colocamos à disposição para sanar dúvidas através dos nossos canais de atendimento. Atenciosamente, Equipe Unico