61 Onfido incidents · maj 2025 — official updates, affected components, duration and resolution details.
Nie możemy obecnie wypełniać UK eVisa raportów i zadań z powodu braku naszego dostawcy.
Usługi usługodawcy zostały przywrócone, nasze zadania eVisas UK ponownie się kończy.
Nasze usługi znów działają.
Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.
Jeden z naszych dostawców ma problemy, co spowoduje opóźnienia w niektórych raportach. Badamy sprawę.
Nasz dostawca wciąż ma problemy. Obserwujemy sytuację. ID- UK to nasza najbardziej wpływowa usługa.
Dostawca jest świadomy tej kwestii. Nadal jesteśmy gotowi do wznowienia naszych usług, jak tylko sprawa zostanie rozwiązana.
Nasz dostawca jest dotknięty poważnym globalnym incydentem w jednym z jego dostawców, który jest aktywnie pracuje nad.
Błędy ustały. Monitorujemy nasze usługi, żeby wszystko wróciło do normy.
Nasze usługi znów działają.
Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.
Mamy do czynienia z problemami z naszymi dostawcami i widzimy raporty tożsamości nie są przetwarzane w jurysdykcji Wielkiej Brytanii
Problem został zidentyfikowany i zastosowaliśmy pracę wokół
Wprowadzono rozwiązanie i monitorujemy wyniki.
Nadal monitorujemy wszelkie dalsze problemy.
Ten incydent został rozwiązany
Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.
Ta usługa rządu brytyjskiego jest obecnie w dół i nie jest dostępna. Monitorujemy sytuację, dopóki usługa nie wróci do sieci.
Kontynuujemy prace nad rozwiązaniem tego problemu.
Wygląda na to, że dostawca stron trzecich wrócił do sieci. Sprawdzanie jest w toku. Kontynuuję monitorowanie sytuacji.
Dostawca stron trzecich jest z powrotem online. Kontrole, które wcześniej zostały sprawdzone.
Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.
Między 14: 30 a 15: 30 UTC, klienci w regionie CA mieli zdegradowany dostęp do publicznego API. Wadliwe zastosowanie w warstwie uwierzytelniania spowodowało nieprawidłowy odrzucenie ważnych żetonów, co doprowadziło do nieudanych wniosków API. Kwestia została w pełni rozwiązana. Nie musisz podejmować żadnych działań. Przepraszamy za zakłócenia.
Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.
Od około 1: 21 PM UTC do 1: 46 PM UTC, nastąpiło zakłócenie akceptacji wniosków o dokumenty z Web SDK oraz Entrust IDV SDK dla przepływów zawierających moduły internetowe. Onfido Android & iOS SDK nie miały wpływu. Przepraszamy za to zakłócenie. Szczegółowy pośmiertny będzie po zakończeniu śledztwa.
Podsumowanie 1 września 2026 r., od 13: 21 UTC do 13: 45 UTC, użytkownicy próbujący przechwytywać dokumenty w Web SDK nie byli w stanie zakończyć sesji. To również rozszerzyło się na natywne Entrust IDV SDK do konfiguracji zawierających moduły webowe. Native Onfido Android i iOS SDK nie zostały naruszone. * * Root Causes * Rutynowa aktualizacja obrazu kontenera dla naszej usługi konfiguracji dokumentu wprowadziła regresję do zadania synchronizacji, która uaktualnia listę dokumentów. Spowodowało to punkt końcowy, którego używają nasze SDK do pobierania dokumentów zwracających błędy "500". Zapobiega to przepływowi SDK w sieci. Nasze rodzime SDK używają listy kopii zapasowych dokumentów, które pozwoliły im kontynuować jako normalne. Nasze progresywne roll- out są zaprojektowane, aby łapać błędy usługi, zanim staną się znaczące. Jednak awaria zadania synchronizacji nie oznaczała sondy gotowości jako niezdrowe, więc kontynuowano. # # Timeline _ 13: 10 UTC: _ Zaczęliśmy progresywną zmianę. 13: 21 UTC _: Usługa została w pełni rozbudowana, co doprowadziło do błędów w funkcji SDK. _ 13: 26 UTC: _ Monitoring powiadomił zespół. _ 13: 44 UTC: _ Przyczyna zidentyfikowana i zmiana cofnięta. _ 13: 45 UTC: _ Usługa przywrócona. Remedies * Dodamy brakujące automatyczne pokrycie testowe, aby zapewnić, że będziemy łapać te przypadki w przyszłości. * Dodamy listę dokumentów awaryjnych do Web SDK, podobną do mechanizmu obecnego w rodzimych SDK, aby upewnić się, że może nadal funkcjonować w przypadku podobnych przyszłych awarii. * Naprawimy progresywny routing, aby upewnić się, że routout nie będzie kontynuowany w przypadku, że coś poszło nie tak z synchronizacji dokumentów.
Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.
Znane twarze doświadczające wyższych wskaźników rozważenia we wszystkich regionach.
Podsumowanie W dniu 26 sierpnia 2026 r. zaobserwowano wzrost częstości rozważań dotyczących znanych twarzy w okresie od 15: 00 do 18: 00 UTC. Ogólny obserwowany odsetek znanych twarzy wzrósł z ~ 6% do ~ 23% we wszystkich regionach. Przypuszczalny wzrost może być wyższy lub niższy, w zależności od specyfiki geograficznej lub pionowej. Powoduje to zmianę w sposobie obliczania wyników dopasowania dla meczów znanych twarzy, które zawyżone wyniki dla twarzy niepasujących i tym samym powodując wiele zgłoszeń do zwrotu fałszywych meczów i * * rozważać * * wynik. # # Root Causes Zmiana wprowadziła nowy algorytm do zdobywania dopasowanych twarzy, który ma na celu poprawę jakości zapamiętywania znanych twarzy. Zostało to szeroko ocenione i potwierdzone wewnętrznymi wskaźnikami referencyjnymi przed ich uwolnieniem. Przypadkowo przejście z poziomu referencyjnego na produkcję częściowo nie odpowiadało szczególnym cechom środowiska produkcji. U źródła, pojedyncza stała nie została odpowiednio przekonwertowana w okresie przejściowym, co spowodowało błędne zachowanie nowego algorytmu punktacji. # # Timeline 15: 20 UTC: Zmiana znanych twarzy jest uwalniana 17: 35 UTC: Zwiększona szybkość rozważania znanych twarzy jest zauważona. 17: 50 UTC: Zmiana jest cofnięta. Rozważ spadek stawki wkrótce po. # Remedies Przeglądamy wewnętrzne poziomy odniesienia i procedury testowania, które mogą zwiększyć bezpieczeństwo tego rodzaju zmian. W szczególności, zapewnienie wewnętrznych testów odzwierciedla rzeczywisty krajobraz produkcji w odniesieniu do zbiorów danych i że przejścia od wewnętrznych wzorców i eksperymentów do produkcji są dokładnie badane. Ponadto procedury zmian będą prowadzone przy ścisłym monitorowaniu, co pozwoli nam zauważyć i działać szybciej.
Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.
Podobieństwo twarzy Kontrola ruchu przy użyciu wyzwań losowości nie idzie w dobrym tempie w regionie UE.
Podsumowanie W dniu 24 sierpnia 2026 r., między 15: 00 UTC a 06: 53 UTC następnego dnia rano, kontrole facial siduarity Motion z wykorzystaniem wyzwań losowości nie powiodły się w znacznie większym tempie niż zwykle w regionie UE. W odniesieniu do wszystkich klientów w regionie zastosowano bardziej rygorystyczną walidację, która powinna być ograniczona do jednego klienta, powodując odrzucenie weryfikacji, które w przeciwnym razie zostałyby odrzucone. Doniesienia zostały zwrócone z niepowodzeniem "Visual Authenticity". Ponieważ kontrole ruchu są w pełni zautomatyzowane, użytkownicy końcowi za tymi sprawozdaniami zostali odrzuceni bez ręcznego przeglądu, a niektórzy próbowali ponownie sprawdzić i zostały odrzucone po raz drugi. Jasny wskaźnik tych kontroli zmniejszył się z około 97% do około 54% w przypadku około 1,67% zgłoszeń dotyczących podobieństwa twarzy. Wyłączenie zmiany natychmiast przywrócone do normy. Inne kontrole ruchu i inne regiony nie zostały naruszone. # # Root Causes Zaostrzenie walidacji wyzwania losowości ruchu było testowane z jednym klientem, kontrolowanym przez ustawienie konfiguracji klienta. Błąd w naszym kodzie oznaczał, że ustawienia zostały ocenione bez identyfikatora klienta, więc bardziej rygorystyczne walidacja została zastosowana do wszystkich klientów w regionie UE uruchomionych Motion z kontroli losowości zamiast do zamierzonego. Weryfikacje, które przeszłyby w ramach standardowej walidacji, zostały odrzucone i zgłoszone w podziale "Autentyczność wizualna". Żadna konfiguracja klienta lub przekazane dane nie były błędne. # # Timeline Zawsze UTC. * 24 sierpnia, 15: 00: umożliwiliśmy bardziej rygorystyczne zatwierdzanie wyzwań związanych z losowością ruchu w regionie UE. Sprawdzanie ruchu przy użyciu losowości zaczęło zawodzić w znacznie większym tempie. * 24 sierpnia, 16: 36: klient zgłosił spadek odsetka sukcesów w pracy i rozpoczęliśmy dochodzenie. * 25 sierpnia, 04: 18: potwierdziliśmy podwyższony wskaźnik awarii i zwiększyliśmy go. * 25 sierpnia, 06: 53: w ciągu kilku minut odwróciliśmy zmianę i wyraźne tempo powrotu do normy. * 26 sierpnia: wprowadziliśmy stałe rozwiązanie. # Remedies * Wzmocnienie kontroli wokół zmian konfiguracji specyficznych dla klienta, aby zapewnić, że nie mogą być stosowane szerzej niż zamierzone. * Poprawa monitorowania i ostrzegania o losowych kontrolach ruchowych, tak aby niespodziewane zmiany częstości odrzucania były wykrywane automatycznie i zwiększane szybciej.
Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.
Obecnie badamy opóźnienia w naszym amerykańskim klastrze w zakresie przetwarzania raportów o podobieństwie twarzy, dokumentów i znanych twarzach.
Widzimy zdegradowane wyniki niektórych węzłów w naszym klastrze poszukiwań zindeksowanych twarzy. Kontynuujemy badanie przyczyn i możliwych środków zaradczych.
Zidentyfikowaliśmy główną przyczynę zdegradowanych wyników w naszym amerykańskim klastrze poszukiwań i aktywnie pracujemy nad jego rozwiązaniem. Sprawdzimy to, gdy już będziemy w pełni odrestaurowani.
Wprowadziliśmy fix i nadal monitorować jakość czasu przetwarzania, który jest obecnie ulepszony.
Czas przetwarzania ciągle się poprawia, wszystkie systemy działają.
Czas przetwarzania wraca do normy. Sprawa ta została rozwiązana. Wkrótce po śmierci.
Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.
Zwiększona tożsamość doświadcza znacznego spadku wyraźnych stawek dla wnioskodawców na całym świecie z wyjątkiem Zjednoczonego Królestwa
Współpracujemy z naszym dostawcą trzeciej partii w celu rozwiązania problemu i udostępnimy aktualizacje w miarę ich dostępności.
Kontynuujemy prace nad rozwiązaniem tego problemu.
Obserwujemy poprawę usług naszego dostawcy i żądamy poprawy wskaźników sukcesu. Nadal uważnie monitorujemy sytuację.
Dostawca rozwiązał problem, a usługa działa teraz normalnie
Automatyczne tłumaczenie oficjalnej aktualizacji incydentu.
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.
