61 Onfido incidents · Mayıs 2025 — official updates, affected components, duration and resolution details.
Şu anda İngiltere eVisa raporlarını ve görevlerini sağlayıcımızın kesintisi nedeniyle tamamlayamayız.
Sağlayıcının hizmetleri restore edildi, İngiltere eVisas görevleri tekrar tamamlandı.
Hizmetlerimiz tekrar çalışır.
Resmî olay güncellemesinden otomatik olarak çevrilmiştir.
Sağlayıcılarımızdan biri, bazı raporlarda gecikmelere neden olacak sorunlar yaşıyor. Sorunu araştırıyoruz.
Sağlayıcımız hala sorunları yaşıyor. Durumu yakından takip ediyoruz. ID-UK bizim en etkili hizmetimizdir.
Sağlayıcı konunun farkındadır. Biz hala sorunu çözdüğü kadar hizmetlerimizi devam etmeye hazırız.
Sağlayıcımız satıcılarından birinde büyük bir küresel olaydan etkileniyor, bu aktif olarak üzerinde çalışıyor.
Hatalar durdu. Her şeyin normale geri döndüğünden emin olmak için hizmetlerimizi izliyoruz.
Hizmetlerimiz tekrar çalışır.
Resmî olay güncellemesinden otomatik olarak çevrilmiştir.
Sağlayıcılarımız ile ilgili sorunlarla karşı karşıyayız ve Kimlik Raporlarını İngiltere yargı yetkisinde bulunmuyoruz
Sorun tespit edildi ve bir çalışma alanı uygulandık
Bir düzeltme uygulandı ve sonuçları takip ediyoruz.
Daha fazla sorun için izlemeye devam ediyoruz.
Bu olay çözüldü
Resmî olay güncellemesinden otomatik olarak çevrilmiştir.
Bu İngiltere Hükümeti hizmeti şu anda aşağı ve mevcut değil. Hizmet online geri gelene kadar durumu izliyoruz.
Bu sorun için bir düzeltme üzerinde çalışmaya devam ediyoruz.
3. parti sağlayıcısı şimdi online olarak geri dönüyor. Checks işleniyor. Durumu izlemek için devam edin.
3. parti sağlayıcısı online geri döndü. Daha önce sıkıştırma kontrolleri şimdi işlendi.
Resmî olay güncellemesinden otomatik olarak çevrilmiştir.
14:30 ve 15:30 UTC arasında, CA bölgesinde müşteriler Public API'ye erişim yaşadı. Kontrol katmanında bir hata dağıtımı, başarısız API talepleri ile sonuçlanan doğru şekilde reddedilmelidir. Sorun tamamen çözüldü. Sonunda hiçbir eylem gerekli değildir. Bozukluk için özür dileriz.
Resmî olay güncellemesinden otomatik olarak çevrilmiştir.
Yaklaşık 1:21 PM UTC'den 1:46 PM UTC'ye kadar, Web SDK'dan gelen Doküman taleplerini kabul etmek için bir kesinti oldu ve Web modüllerini içeren akışlar için Güvenilir IDV SDK'lar. Onfido Android & iOS SDKs etkilenmedi. Bu rahatsızlıktan özür dileriz. A detailed postmortem soruşturmamızı sonlandırdığımız bir kez takip edecektir.
# ### Özet 1 Eylül 2026'da, 13:21 UTC'den 13:45 UTC'ye kadar, Web SDK'da belge yakalamaya çalışan kullanıcılar oturumlarını bitiremedi. Bu aynı zamanda web modüllerini içeren konfigürasyonlar için yerli Entrust IDV SDK'lara da genişletildi. Yerli Onfido Android ve iOS SDKları etkilenmedi. # ## Root Causes Belge yapılandırma servisimiz için bir konteyner resmine rutin bir güncelleme, belgeleri içeren senkronizasyon işine bir regresyon tanıttı. Bu, SDK'larımızın "500" hataları geri getirmek için kullandığı son noktaya neden oldu. Bu, web SDK'nın devam etmesini engelledi. Yerli SDKlarımız normal olarak devam etmelerine izin veren bir yedek belge listesi kullanıyor. İlerici rulolarımız, önemli hale gelmeden önce hizmet hataları yakalamak için tasarlanmıştır. Bununla birlikte, senkronizasyon işi başarısızlığı, hazır probu sağlıksız olarak işaretlemedi, bu yüzden rollout devam etti. # ## Timeline 13:10 UTC: Değişimin ilerici bir rollout başlattık. 13:21 UTC : Servis tamamen etkilenen SDK işlevselliği üzerinde hatalara yol açtı. 13:26 UTC: Ekibi uyarmayı izleyin. 13:44 UTC: Çünkü tespit edilen ve değişim geri döndü. 13:45 UTC: Hizmet restore edilmiştir. # ## Remedies * Bu davaları gelecekte yakalamamızı sağlamak için otomatik test kapsamını ekleyeceğiz. * Web SDK'ya bir geri dönüş belgesi listesi ekleyeceğiz, yerel SDK'larda mevcut mekanizmaya benzer şekilde, benzer bir gelecekteki başarısızlık durumunda hala çalışabilmesini sağlamak için. * rollout'ın senkronizasyon belgeleri ile yanlış gittiğini sağlamak için ilerici ruloyu düzelteceğiz.
Resmî olay güncellemesinden otomatik olarak çevrilmiştir.
Bilinen Faces tüm bölgelerde daha yüksek göz oranları yaşıyor.
# # # Özet 26 Ağustos'ta 2026'da, Bilinen Faces'in dikkate alınmasındaki artış, 15:00 ve 18:00 UTC arasındaki dönemde gözlemlendi. Genel olarak gözlemlenen Faces oranı tüm bölgelerdeki% 6'dan -%23'e yükseldi. Perceived artışı, müşterinin belirli coğrafyasına veya dikeyliğe bağlı olarak daha yüksek veya daha düşük olabilir. Eşleme puanlarının Bilinen Faces maçlarında nasıl hesaplandığına dair bir değişiklik tarafından yönlendirildi, bu da rakip olmayan yüzler için şişirdi ve bu nedenle sahte maçları ve bir **consider** sonucu geri dönmesine neden oldu. ## Root Causes Değişim, eşleşen yüzler için yeni bir algoritma tanıttı, bilinen Faces’in performansını geliştirmek amaçlanmıştır. Bu, serbest bırakılmadan önce içsel kriterler tarafından kapsamlı bir şekilde değerlendirildi ve doğrulandı. Kuşkusuz, kriterlerden üretime geçiş, belirli üretim ortamı özellikleri için kısmen başarısız oldu. Kökte, geçişte tek bir sabit düzgün bir şekilde dönüştürülmedi, yeni puanlama algoritmasının yanlış davranışına yol açtı. ## Timeline 15:20 UTC: Bilinen Faces için değişim yayınlandı 17:35 UTC: Bilinen Faces hakkında artan göz fark edilir. 17:50 UTC: Değişim geri alındı. Oran kısa sürede düşer. ## Remedies Bu tür değişikliğin güvenliğini arttırabilecek içsel karşılaştırmalar ve test prosedürleri inceleyeceğiz. Özellikle, iç testlerin veri kümeleri söz konusu olduğunda gerçek üretim alanını yansıttığı ve üretime geçişlerin tamamen test edilmesi. Ayrıca, değişim prosedürleri sıkı izleme ile gerçekleştirilecektir, böylece daha hızlı bir şekilde bildirim ve hareket etmemizi sağlar.
Resmî olay güncellemesinden otomatik olarak çevrilmiştir.
Yüz Benzerlik Hareket, rastgelelik zorluklarını kullanarak kontroller, AB bölgesinde normalden çok daha yüksek bir oranda başarısız oluyor.
# # # Özet 24 Ağustos 2026'da, saat 15:00 UTC ve 06:53 UTC arasında, Yüz Benzerlik Hareketi, AB bölgesinde normalden çok daha yüksek oranda başarısız oldu. Bölgedeki tüm müşterilere tek bir müşteri ile sınırlı olması gerektiğinde, aksi takdirde reddedilecek doğrulamalara neden oldu. Etkilenen raporlar "Visual Authenticity" başarısızlığı ile geri döndü. Çünkü Hareket kontrolleri tamamen otomatikdir, bu raporların arkasındaki son kullanıcılar manuel bir inceleme ile reddedildi ve bazıları tekrar kontrol etmeye çalıştı ve ikinci kez reddedildi. Bu çeklerin net oranı yaklaşık% 97'den yaklaşık% 54'e kadar Yüz Benzerlik Hareket raporlarının% 1.67'si etkilendi. Değişimi hemen restore eden normal açık oranları ortadan kaldırmak. Diğer Hareket kontrolleri ve diğer bölgeler etkilenmedi. ## Root Causes Hareket rastgeleliği meydan okumasının katı bir geçerliliği, per-müşteri yapılandırma ayarı tarafından kontrol edilen tek bir müşteri ile yargılanmaktı. Kodımızdaki bir hata, ayarın müşteri tanımlayıcısı olmadan değerlendirilmek anlamına geliyordu, bu nedenle, AB bölgesindeki tüm müşterilere amaçlanma, amaçlanandan ziyade rastgele checks ile uygulandı. Standart geçerlilik altında geçecek olan Doğrulamalar bunun yerine reddedildi ve "Visual Authenticity" arızası altında rapor edildi. Hiçbir müşteri yapılandırması veya gönderilen veriler hatalıydı. ## Timeline Tüm zamanlarda UTC. * 24 Ağustos, 15:00: AB bölgesinde rastgelelik meydan okumaları için daha katı bir doğrulama sağladık. Rastgeleliği kullanarak hareket kontrolleri çok daha yüksek bir oranda başarısız oldu. * 24 Ağustos, 16:36: Bir müşteri iş akışı başarı oranlarında bir düşüş bildirdi ve araştırmaya başladık. * 25 Ağustos, 04:18: Yüksek başarısızlık oranını doğruladık ve yükseldik. * 25 Ağustos, 06:53: Değişimi ve açık oranları dakikalar içinde normale geri döndük. * 26 Ağustos: Kalıcı bir düzeltme kurduk. ## Remedies * Müşteriye özgü konfigürasyon değişikliklerinin etrafındaki kontrolleri güçlendirmek, amaçlanandan daha geniş bir şekilde uygulanmalıdır. * Hareket rastgeleliği net oranı kontrolleri için izleme ve uyarılandırmayı geliştirin, böylece reddedilme oranlarındaki beklenmedik değişiklikler otomatik olarak tespit edilir ve daha hızlı yükselir.
Resmî olay güncellemesinden otomatik olarak çevrilmiştir.
Şu anda ABD kümemizde yüz Benzerlik, Doküman ve Bilinen Faces raporlarının işlenmesi için gecikmeleri araştırıyoruz.
Arama grubumuzda bazı düğümlerin olağanüstü performanslarını indekslenen yüzler için görüyoruz. Kök nedenini ve olası remediasyonları araştırmaya devam ediyoruz.
ABD arama grubumuzda bozulan performansın kök nedenini tespit ettik ve bunu çözmek için aktif olarak çalışıyoruz. Tamamen restore edilmiş bir kez takip edeceğiz.
Bir düzeltme uyguladık ve şimdi geliştirilmiş olan işleme süresini izlemeye devam ettik.
İşleme zamanı gelişiyor, tüm sistemler artık operasyonel.
İşleme süreleri normale geri döndü. Bu konu şimdi çözüldü. Yakında takip etmek için Post-mortem.
Resmî olay güncellemesinden otomatik olarak çevrilmiştir.
Kimlik geliştirmesi, İngiltere dışında tüm dünyada başvuranlar için büyük bir düşüş yaşıyor
Sorunu çözmek için üçüncü taraf sağlayıcımızla çalışıyoruz ve mevcut oldukları gibi güncelleştirmeleri paylaşacağız.
Bu sorun için bir düzeltme üzerinde çalışmaya devam ediyoruz.
Sağlayıcımızın hizmet kurtarmasını görüyoruz ve başarı oranlarının iyileştirilmesini talep ediyoruz. Durumu yakından izlemeye devam ediyoruz.
Sağlayıcı sorunu çözdü ve hizmet artık normal olarak çalışıyor
Resmî olay güncellemesinden otomatik olarak çevrilmiştir.
We cannot complete QES tasks because our electronic signature provider is encountering issues.
Our provider is experiencing issues. All QES tasks cannot complete for now.
Our provider is still experiencing issues. All QES tasks cannot complete for now.
The issue has been fixed. We're monitoring and resuming blocked QES tasks, if they can be.
This incident has been resolved.
We're currently monitoring the EU cluster after an Amazon RDS issue.
We’re seeing recovery across our internal metrics, and processing has now returned to full capacity. At this time, the issue appears to be resolved. Our current leading hypothesis is resource contention on a shared Amazon RDS instance that several services depend on, potentially related to a VACUUM operation running alongside a long-running job deleting a large volume of accumulated historical data. We have not yet confirmed the root cause and will continue investigating as follow-up, but service has been restored for now. We'll be following up with a public post-mortem.
**Incident date:** 22 June 2026 **Region:** EU \(eu-west-1\) **Affected EU services**: API, Dashboard, Applicant Form, Document Verification, Facial Similarity, Watchlist, Identity Enhanced, Webhooks, Known Faces, Autofill, QES and Device Intelligence. **Customer impact:** ~16:50–17:00 UTC \(acute degradation\); ~17:00–17:20 UTC \(backlog recovery\) ## Summary On 22 June 2026, from approximately 16:50 UTC, a shared database cluster serving our EU region came under severe load and could not reliably serve queries for about 10 minutes. EU services returned elevated errors, and processing throughput briefly fell to ~20–35% of normal levels, with many subcomponents of our system \(e.g., Facial Similarity report processing\) being entirely disrupted, some others less heavily impacted \(e.g., Document report processing\). Service recovered by 17:01 UTC, the database fully stabilizing after an automatic failover \(~17:05–17:07 UTC\). A resultant report backlog was cleared by ~17:20 UTC. Requests in flight during the acute degradation window may have failed unless retried; queued background work was processed automatically once the database recovered. ## Root cause The incident was triggered by a routine database storage-reclamation task following standard scheduled data-deletion processing. This task normally completes without issue; why it failed on this occasion remains under investigation, although we observed that it was processing a larger-than-usual backlog. We have a support case open with our cloud provider to confirm a definitive root cause. The reclamation task began to compete with normal application queries, which slowed as the database struggled to keep up. Applications opened more and more connections, leading to connection saturation and causing queries across the affected services to fail. The database stabilized when an automatic failover to a healthy standby was triggered; the contention fully resolving with the failover to a new instance. ## Timeline \(UTC\) * **16:50** — Our monitoring detected errors and elevated latency across EU services caused by resource contention on a shared database cluster. * **16:53** — We start to see improvements, but system still not acting at normal levels of performance. * **~17:00** — Customer-facing errors subsided and processing resumed as the contention eased. * **17:01** — On-call engineers opened an incident and continued investigations. * **~17:05–17:07** — The database performed an automatic failover to a healthy instance, which reset the overloaded writer and fully stabilised the cluster. The failover was triggered because of resource contention \(out of memory\) caused by the heavy vacuuming in the preceding minutes of the incident. Once the impacting vacuum operations had finished freeing up resources, we had started to see signs of improvement \(16:53—17:01\), but added latency in the feedback loop and aggregation window at AWS still decided to trigger the failover, even though we were already in a recovering state. * **17:15–17:20** — Requests that had queued during the incident were worked through and the backlog returned to normal. * **17:21–17:56** — We monitored the recovery and confirmed processing remained at full capacity. ## Remedies * Reviewing connection limits and pooling so a single service cannot saturate a shared database, and evaluating dedicated database clusters per product to remove cross-service impact. * Changing large historical-data deletions to run in smaller, throttled batches, and tuning database maintenance to avoid large catch-up operations. * Adding earlier, proactive alerting on database memory, connections and load so we can intervene before customer impact. * Continue working with our cloud provider on a definitive root cause.
One of our providers is still experiencing issues, resulting in higher TaT for electronic signature tasks.
Our provider is actively working on fixing the issue.
Our provider is still working on fixing the issue. We're monitoring the impact and we're making sure to keep the TaT as low as possible, considering the situation.
Our provider's error rate dropped significantly. The TaT of QES tasks is now close to the usual value.
We're working closely with our provider to find the reason of the remaining errors. The error rate contacting our provider is stable and the impact on the QES task TaT is under control.
Our provider was able to fix the issue and we don't get any error when contacting them. The TaT of QES tasks is back to normal. Monitoring the situation to make sure the errors don't come back.
The QES tasks TaT is back to normal.
Our electronic signature tasks are taking more time to complete because one of our providers is doing some maintenance.
Our provider is still not able to answer to all requests, resulting in longer-than-usual electronic signature task processing time.
The service is operational again.
Incident was solved.
## Summary Between May and June 2026, around 0.037% of the evidence files generated on the platform were incomplete and included in the corresponding evidence folders. There was no impact on workflow results, and no incorrect information was ever displayed — the affected files were simply empty rather than wrong. A small number of requests to generate timeline files were also affected \(around 0.073%\). ## Root Causes The issue was introduced during an initiative to improve how timeline and evidence PDFs are generated — making them significantly smaller, more efficient, and more resilient to produce. As part of these changes, in rare cases the new flow attempted to generate the PDF before its content had fully loaded, resulting in a blank or nearly empty file. Because the problem was intermittent and occurred only in rare timing conditions, it was not consistently reproduced during rollout testing. ## Timeline * 15 June 2026: Engineering investigation found an incomplete PDF and started the root cause investigation * 17 June 2026: Root cause investigation completed and a safeguard to prevent incomplete PDFs was deployed ## Remedies * We corrected the PDF generation flow so PDFs are only printed after content has fully loaded, and added a safeguard that stops generation when an incomplete PDF is detected. * We also improved our monitoring and test coverage for PDF generation, so similar issues are caught earlier in the future.
Some Watchlist search search profiles are not working correctly the impacted reports are not being processed. We are investigation the root cause.
We identified the issue and are implementing a fix.
The issue has been fixed, and the reports are being processed correctly. We are still monitoring the service.
This incident has been resolved.
We are facing issues with one of our providers and we see a slight decrease in clear rate for Identity Reports in UK jurisdiction
A fix has been implemented and we are monitoring the results. All clear rates should be back to normal
All reports are back to normal.
We cannot complete QES tasks because our electronic signature provider is encountering issues.
The provider is working on a fix.
Our provider fixed the issue. QES tasks are completing now. Tasks started during the incident were resumed.
The service is operational, no error where detected after the fix.
We noticed an issue with our QES tasks, we're investigating.
Our provider is experiencing issues. All QES tasks cannot complete for now.
Our provider is fixing the issue. QES tasks still cannot complete.
The issue has been fixed. We're monitoring and resuming blocked QES tasks, if they can be.
QES is operational again.
We identified an issue with one of our provider and some QES tasks may encounter some problems.
Our provider is still experiencing issues. All QES tasks cannot complete for now.
Our provider continues experiencing issues and is working on a fix.
Our provider is slowly recovering, we expect some QES tasks to complete.
QES is operational again.
