61 Onfido incidents · maj 2025 — official updates, affected components, duration and resolution details.
Vi kan ikke i øjeblikket fuldføre UK eVisa rapporter og opgaver på grund af en afbrydelse af vores udbyder.
Leverandørens tjenester er blevet genoprettet, vores britiske eVisas opgaver er afsluttet igen.
Vores tjenester er operationelle igen.
Automatisk oversat fra den officielle hændelsesopdatering.
En af vores udbydere har problemer, hvilket vil forårsage forsinkelser i nogle rapporter. Vi undersøger sagen.
Vores udbyder oplever stadig problemer. Vi overvåger situationen nøje. ID-UK er vores mest påvirkede service.
Udbyderen er klar over problemet. Vi er stadig klar til at genoptage vores tjenester, så snart problemet er løst.
Vores udbyder er påvirket af en større global hændelse på en af sine leverandører, som aktivt bliver arbejdet på.
Fejl stoppede. Vi overvåger vores tjenester for at sikre, at alt er normalt igen.
Vores tjenester er operationelle igen.
Automatisk oversat fra den officielle hændelsesopdatering.
Vi står over for problemer med vores udbydere, og vi ser Identity Reports ikke blive behandlet i UK jurisdiktion
Spørgsmålet er blevet identificeret, og vi har arbejdet med
Et fix er blevet gennemført, og vi overvåger resultaterne.
Vi fortsætter med at overvåge for yderligere spørgsmål.
Denne hændelse er blevet løst
Automatisk oversat fra den officielle hændelsesopdatering.
Denne britiske regering service er i øjeblikket nede og ikke tilgængelig. Vi overvåger situationen, indtil tjenesten kommer online.
Vi fortsætter med at arbejde på en løsning på dette problem.
Tredje part udbyder synes at være tilbage online nu. Kontrollen er under behandling. Fortsætter med at overvåge situationen.
Tredje part udbyder er tilbage online. Den kontrol, der tidligere er blevet foretaget, er blevet behandlet nu.
Automatisk oversat fra den officielle hændelsesopdatering.
Mellem 14: 30 og 15: 30 UTC, kunder i CA-regionen oplevede forringet adgang til den offentlige API. En defekt implementering i autentificering lag forårsaget gyldige tokens at blive forkert afvist, hvilket resulterer i mislykkedes API anmodninger. Spørgsmålet er helt løst. Der kræves ingen handling i din ende. Vi undskylder forstyrrelsen.
Automatisk oversat fra den officielle hændelsesopdatering.
Fra ca. 1: 21 UTC til 1: 46 UTC var der en afbrydelse i at acceptere dokumentanmodninger fra Web SDK samt Entrust IDV SDKs for strømme, der indeholder webmoduler. Onfido Android & iOS SDK var ikke påvirket. Vi undskylder forstyrrelsen. En detaljeret post mortem vil følge, når vi har afsluttet vores undersøgelse.
# # # Oversigt Den 1. september 2026, fra 13: 21 UTC til 13: 45 UTC, brugere forsøger dokument fangst i Web SDK var ude af stand til at afslutte deres session. Dette også udvidet til indfødte Entrust IDV SDK er for konfigurationer, der indeholder web-moduler. Native Onfido Android og iOS SDK var upåvirket. # # Root Årsager En rutinemæssig opdatering til et containerbillede til vores dokument konfiguration service indført en regression til synkronisering job, der opdaterer dokumentlisten. Dette resulterede i det endepunkt, som vores SDK bruger til at hente dokumenter, der returnerer '500' fejl. Dette forhindrede web SDK i at gå videre. Vores indfødte SDKs bruge en backup dokument liste, som tillod dem at fortsætte som normalt. Vores progressive udrulninger er designet til at fange servicefejl, før de bliver betydelige. Men synkroniseringen job fiasko ikke markere parathed sonden som usund, så udrulningen fortsatte. Timeline _ 13: 10 UTC: _ Vi startede en gradvis udrulning af ændringen. _ 13: 21 UTC _: Tjenesten blev fuldt rullet ud, hvilket førte til fejl på påvirket SDK funktionalitet. _ 13: 26 UTC: _ Overvågning alarmerede holdet. _ 13: 44 UTC: _ Årsag identificeret og ændring rullede tilbage. _ 13: 45 UTC: _ Service genoprettet. # # Remedies * Vi vil tilføje manglende automatiseret test dækning for at sikre, at vi fanger disse sager i fremtiden. * Vi vil tilføje en fallback dokument liste til Web SDK, svarende til den mekanisme, der findes i de indfødte SDKs, for at sikre, at det stadig kan fungere i tilfælde af lignende fremtidige svigt. * Vi vil fastsætte den progressive udrulning for at sikre, at udrulningen ikke vil fortsætte i tilfælde af, at noget er gået galt med synkronisering dokumenter.
Automatisk oversat fra den officielle hændelsesopdatering.
Kendt Faces oplever højere hensyn satser på tværs af alle regioner.
# # Summary Den 26. august 2026 blev der observeret en stigning i betænkningsraten for kendte ansigter i perioden mellem 15: 00 og 18: 00 UTC. Det samlede observerede antal kendte ansigter steg fra ~ 6% til ~ 23% i alle regioner. Den forventede stigning kan have været højere eller lavere, afhængigt af kundens specifikke geografi eller lodret. Den blev drevet af en ændring til, hvordan matchende scorer er beregnet for Kendte Faces kampe, som oppustede scorer for ikke-matchende ansigter og dermed forårsager mange rapporter til at returnere falske kampe og et * * overveje * * resultat. # Root Årsager Ændringen indførte en ny algoritme til scoring matchende ansigter, som er beregnet til at forbedre kendte ansigter huske ydeevne. Dette blev grundigt evalueret og valideret af interne benchmarks, før det blev frigivet. Overgangen fra benchmarks til produktion var utilsigtet ikke i stand til at tage højde for særlige produktionsmiljøegenskaber. Ved roden, blev en enkelt konstant ikke ordentligt konverteret i overgangen, hvilket resulterer i forkert adfærd af den nye scoring algoritme. # Tidslinje 15: 20 UTC: Skift til kendte ansigter er udgivet 17: 35 UTC: Øget hensyn sats på kendte ansigter er bemærket. 17: 50 UTC: Ændringen rulles tilbage. Overvej hastigheden falder kort tid efter. # Remedies Vi gennemgår interne benchmarks og testprocedurer, som kan øge sikkerheden ved denne form for ændringer. Specifikt afspejler sikring af intern afprøvning det virkelige produktionslandskab, når det gælder datasæt, og at overgangen fra interne benchmarks og eksperimenter til produktion er grundigt testet. Desuden vil ændringsprocedurerne blive gennemført med strammere overvågning, så det giver os mulighed for at lægge mærke til og handle hurtigere.
Automatisk oversat fra den officielle hændelsesopdatering.
Ansigtslighed Bevægelseskontrol ved hjælp af tilfældige udfordringer svigter i langt højere grad end normalt i EU-regionen.
# # Summary Den 24. august 2026, mellem 15: 00 UTC og 06: 53 UTC den følgende morgen, facial lighed Motion kontrol ved hjælp af tilfældighed udfordringer mislykkedes i en meget højere hastighed end normalt i EU-regionen. Der blev anvendt en strengere validering for alle kunder i regionen, når den skulle have været begrænset til en enkelt kunde, hvilket forårsagede verifikationer, som ellers ville have været afvist. Berørte rapporter blev returneret med en "Visual Autenticity" fiasko. Da Motion-checks er fuldt automatiserede, blev slutbrugerne bag disse rapporter afvist uden manuel gennemgang, og nogle forsøgte at kontrollere igen og blev afvist igen. Den klare sats for disse kontroller faldt fra ca. 97% til ca. 54% for ca. 1,67% af rapporterne om facial lighed Motion blev påvirket. Deaktivering af ændringen genoprettet normale klare satser straks. Andre Motion-kontroller og andre regioner blev ikke berørt. # Root Årsager En strengere validering af bevægelsen tilfældighed udfordring blev trialled med en enkelt kunde, styret af en per- kunde konfiguration indstilling. En fejl i vores kode betød, at indstillingen blev evalueret uden kundeidentifikatoren, så den strengere validering blev anvendt på alle kunder i EU-regionen, der kører Motion med tilfældige kontroller snarere end på den tilsigtede. Verifikationer, der ville have bestået under standard validering blev afvist i stedet, og rapporteret under "Visual Autenticity" opdeling. Ingen kundekonfiguration eller indsendte data var skyld i fejl. # Tidslinje Alle gange UTC. * 24. august, 15: 00: vi muliggjorde en strengere validering for bevægelse tilfældighed udfordringer i EU-regionen. Bevægelseskontrol ved hjælp af tilfældighed begyndte at mislykkes i en meget højere hastighed. * 24 August, 16: 36: en kunde rapporterede et fald i workflow succesrater og vi begyndte at undersøge. * 25 August, 04: 18: vi bekræftede den forhøjede fejlprocent og eskalerede det. * 25 August, 06: 53: vi vendt ændringen og klare satser tilbage til normal inden for få minutter. * 26 August: vi indsat en permanent fix. # Remedies * Styrke kontrollen omkring brugerspecifikke konfigurationsændringer for at sikre, at de ikke kan anvendes mere bredt end hensigten. * Forbedre overvågning og varsling for Motion tilfældighed klar sats kontrol, så uventede ændringer i afstødningsrater detekteres automatisk og eskaleres hurtigere.
Automatisk oversat fra den officielle hændelsesopdatering.
Vi er i øjeblikket ved at undersøge forsinkelser i vores amerikanske klynge til behandling af facial ligheder, dokumenter og kendte ansigter rapporter.
Vi ser nedbrudt ydeevne af nogle knudepunkter i vores søgning klynge for indekserede ansigter. Vi fortsætter med at undersøge den grundlæggende årsag og mulige oprensninger.
Vi har identificeret årsagen til forringet ydeevne i vores amerikanske søgeklynge og arbejder aktivt på at løse det. Vi følger op, når vi er færdige.
Vi implementerede en rettelse og fortsætter med at overvåge kvaliteten af behandlingstiden, som nu er forbedret.
Bearbejdelses tiden bliver ved med at blive bedre, alle systemer er nu i drift.
Forarbejdningstiden er normal igen. Dette spørgsmål er nu løst. Efter døden følger snart efter.
Automatisk oversat fra den officielle hændelsesopdatering.
Identitet Forbedret oplever et stort fald i klare satser for ansøgere hele verden undtagen UK
Vi arbejder med vores tredjeparts udbyder for at løse problemet og vil dele opdateringer, efterhånden som de bliver tilgængelige.
Vi fortsætter med at arbejde på en løsning på dette problem.
Vi ser vores udbyders service opsving og anmode om succes satser forbedring. Vi følger fortsat situationen nøje.
Udbyderen har løst problemet, og tjenesten fungerer nu normalt
Automatisk oversat fra den officielle hændelsesopdatering.
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.
