История сбоев Onfido

1. 23 октября 2026 г. в 01:22 UTCidentified

   В настоящее время мы не можем заполнить отчеты и задания по электронной визе в Великобританию из-за сбоя нашего провайдера.

2. 23 октября 2026 г. в 01:47 UTCmonitoring

   Услуги провайдера восстановлены, наши задачи по eVisas в Великобритании снова выполняются.

3. 23 октября 2026 г. в 01:56 UTCresolved

   Наши службы снова работают.

Автоматический перевод официального обновления инцидента.

1. 20 октября 2026 г. в 06:23 UTCinvestigating

   Один из наших провайдеров имеет проблемы, которые могут привести к задержкам в некоторых отчетах. Мы расследуем этот вопрос.

2. 20 октября 2026 г. в 07:05 UTCidentified

   Наш провайдер по-прежнему испытывает проблемы. Мы внимательно следим за ситуацией. ID-UK - наш самый востребованный сервис.

3. 20 октября 2026 г. в 07:52 UTCidentified

   Провайдер знает об этой проблеме. Мы готовы возобновить наши услуги, как только проблема будет решена.

4. 20 октября 2026 г. в 08:55 UTCidentified

   На нашего провайдера влияет крупный глобальный инцидент у одного из его поставщиков, над которым активно ведется работа.

5. 20 октября 2026 г. в 09:25 UTCmonitoring

   Ошибки прекратились. Мы следим за нашими услугами, чтобы убедиться, что все в порядке.

6. 20 октября 2026 г. в 09:59 UTCresolved

   Наши службы снова работают.

Автоматический перевод официального обновления инцидента.

1. 30 сентября 2026 г. в 10:55 UTCinvestigating

   Мы сталкиваемся с проблемами с нашими поставщиками, и мы видим, что отчеты об идентификации не обрабатываются в юрисдикции Великобритании

2. 30 сентября 2026 г. в 11:20 UTCidentified

   Вопрос был выявлен, и мы применили обходной путь

3. 30 сентября 2026 г. в 12:35 UTCmonitoring

   Реализовано исправление, и мы отслеживаем результаты.

4. 30 сентября 2026 г. в 12:37 UTCmonitoring

   Мы продолжаем отслеживать любые дополнительные проблемы.

5. 30 сентября 2026 г. в 14:01 UTCresolved

   Этот инцидент был урегулирован

Автоматический перевод официального обновления инцидента.

1. 22 сентября 2026 г. в 11:23 UTCidentified

   В настоящее время эта служба правительства Великобритании недоступна. Мы следим за ситуацией до тех пор, пока сервис не вернется в онлайн.

2. 22 сентября 2026 г. в 11:24 UTCidentified

   Мы продолжаем работать над решением этой проблемы.

3. 22 сентября 2026 г. в 11:40 UTCmonitoring

   3-й провайдер, похоже, вернулся в Интернет. Проверки проходят. Продолжать следить за ситуацией.

4. 22 сентября 2026 г. в 11:49 UTCresolved

   Поставщик 3-й партии вернулся в Интернет. Проверки, ранее застрявшие, теперь обработаны.

Автоматический перевод официального обновления инцидента.

1. 7 сентября 2026 г. в 15:53 UTCresolved

   В период с 14:30 до 15:30 UTC клиенты в регионе CA испытали ухудшение доступа к публичному API. Неправильное развертывание в слое аутентификации привело к неправильному отклонению действительных токенов, что привело к неудачным запросам API. Вопрос был полностью решен. Никаких действий с вашей стороны не требуется. Мы приносим извинения за срыв.

Автоматический перевод официального обновления инцидента.

1. 1 сентября 2026 г. в 14:37 UTCresolved

   Примерно с 1:21 до 1:46 вечера UTC было нарушено принятие запросов на Документы от Web SDK и Entrust IDV SDK для потоков, содержащих веб-модули. Onfido Android и iOS SDK не пострадали. Мы приносим извинения за это нарушение. Подробное вскрытие последует, как только мы завершим наше расследование.

2. 14 сентября 2026 г. в 09:18 UTCpostmortem

   ###Резюме 1 сентября 2026 года, с 13:21 по 13:45 UTC, пользователи, пытающиеся захватить документ в Web SDK, не смогли завершить сеанс. Это также распространялось на нативные конфигурации Entrust IDV SDK, которые содержат веб-модули. Native Onfido Android и iOS SDK не пострадали. ###Коренные причины Регулярное обновление изображения контейнера для нашей службы конфигурации документов ввело регрессию в работу синхронизации, которая обновляет список документов. Это привело к конечной точке, которую наши SDK используют для извлечения документов, возвращающих «500» ошибок. Это не позволило продолжить потоки SDK. Наши родные SDK используют резервный список документов, который позволяет им продолжать работу в обычном режиме. Наши прогрессивные развертывания предназначены для улавливания ошибок обслуживания, прежде чем они станут значительными. Однако сбой в работе синхронизации не обозначил зонд готовности как нездоровый, поэтому развертывание продолжалось. ###Время 13:10 UTC: Мы начали постепенное внедрение изменений. 13:21 UTC : Сервис был полностью развернут, что привело к ошибкам в функциональности SDK. 13:26 UTC: Мониторинг предупредил команду. 13:44 UTC: Причина выявлена и перемена откатилась назад. 13:45 UTC: Служба восстановлена. ###Средства правовой защиты Мы добавим недостающее автоматическое покрытие тестирования, чтобы гарантировать, что мы поймаем эти случаи в будущем. Мы добавим список резервных документов в Web SDK, аналогичный механизму, присутствующему в нативных SDK, чтобы гарантировать, что он все еще может функционировать в случае любых подобных будущих сбоев. Мы исправим прогрессивное развертывание, чтобы гарантировать, что развертывание не будет продолжаться в случае, если что-то пошло не так с синхронизацией документов.

Автоматический перевод официального обновления инцидента.

1. 8 сентября 2026 г. в 13:24 UTCresolved

   Известные лица, испытывающие более высокие показатели во всех регионах.

2. 8 сентября 2026 г. в 13:24 UTCpostmortem

   ##Резюме 26 августа 2026 года в период между 15:00 и 18:00 UTC наблюдалось увеличение скорости рассмотрения известных лиц. Общее количество известных лиц увеличилось с ~6% до ~23% во всех регионах. Воспринимаемое увеличение может быть выше или ниже, в зависимости от конкретной географии или вертикали клиента. Это было обусловлено изменением того, как вычисляются совпадающие баллы для матчей с известными лицами, что завышало баллы для несоответствующих лиц и, таким образом, приводило к тому, что многие отчеты возвращали ложные матчи и результат. ##Коренные причины Изменение ввело новый алгоритм для подсчета совпадающих лиц, который предназначен для улучшения производительности отзыва известных лиц. Это было тщательно оценено и подтверждено внутренними контрольными показателями перед выпуском. Непреднамеренно переход от эталонных показателей к производству частично не учитывал конкретных характеристик производственной среды. В корне, одна постоянная не была должным образом преобразована в переходе, что привело к неправильному поведению нового алгоритма оценки. ##Время 15:20 Выход UTC: Change to Known Faces 17:35 UTC: Замечено увеличение скорости рассмотрения на известных лицах. 17:50 UTC: Изменения откатываются назад. Рассмотрим снижение ставок вскоре после этого. ##Средства правовой защиты Мы пересматриваем внутренние критерии и процедуры тестирования, которые могут повысить безопасность такого рода изменений. В частности, обеспечение внутреннего тестирования отражает реальный производственный ландшафт, когда речь идет о наборах данных, и что переход от внутренних эталонов и экспериментов к производству тщательно проверяется. Кроме того, процедуры изменения будут проводиться с более жестким контролем, чтобы мы могли быстрее замечать и действовать.

Автоматический перевод официального обновления инцидента.

1. 8 сентября 2026 г. в 13:17 UTCresolved

   Проверки движения с использованием проблем случайности терпят неудачу с гораздо более высокой скоростью, чем обычно в регионе ЕС.

2. 8 сентября 2026 г. в 13:17 UTCpostmortem

   ##Резюме 24 августа 2026 года, между 15:00 UTC и 06:53 UTC на следующее утро, проверки движения лица с использованием случайностей провалились с гораздо более высокой скоростью, чем обычно в регионе ЕС. Более строгая проверка была применена ко всем клиентам в регионе, когда она должна была быть ограничена одним клиентом, в результате чего проверки, которые в противном случае прошли бы, были отклонены. Пострадавшие сообщения были возвращены с отказом «Визуальной подлинности». Поскольку проверки движения полностью автоматизированы, конечные пользователи, стоящие за этими отчетами, были отклонены без ручного обзора, а некоторые попытались снова проверить и были отклонены во второй раз. Четкая ставка для этих проверок упала с примерно 97% до примерно 54% для примерно 1,67% сообщений о движении лица. Отключение изменений немедленно восстановило нормальные четкие показатели. Другие проверки движения и другие регионы не пострадали. ##Коренные причины Более строгая проверка задачи случайности движения была опробована с одним клиентом, контролируемым конфигурацией на одного клиента. Ошибка в нашем коде означала, что настройка была оценена без идентификатора клиента, поэтому более строгая проверка была применена ко всем клиентам в регионе ЕС, выполняющим Motion с проверками случайности, а не к предполагаемому. Вместо этого проверки, которые прошли бы в соответствии со стандартной валидацией, были отклонены и представлены в разделе «Визуальная подлинность». Никакая конфигурация клиента или представленные данные не были ошибочными. ##Время Все время UTC. * 24 августа, 15:00: мы сделали более жесткую проверку на случайность движения в регионе ЕС. Проверки движения с использованием случайности начали давать сбой с гораздо более высокой скоростью. 24 августа, 16:36: клиент сообщил о снижении показателей успеха рабочего процесса, и мы начали расследование. 25 августа, 04:18: мы подтвердили повышенный уровень отказов и увеличили его. 25 августа, 06:53: мы вернули изменения и четкие ставки вернулись к норме в течение нескольких минут. 26 августа: мы развернули постоянное исправление. ##Средства правовой защиты Усилить контроль за изменениями конфигурации, характерными для клиента, чтобы гарантировать, что они не могут быть применены более широко, чем предполагалось. Улучшить мониторинг и оповещение для проверки случайности движения, чтобы неожиданные изменения в показателях отказов обнаруживались автоматически и быстрее.

Автоматический перевод официального обновления инцидента.

1. 27 июля 2026 г. в 18:12 UTCinvestigating

   В настоящее время мы расследуем задержки в нашем кластере в США для обработки отчетов о сходстве лиц, документах и известных лицах.

2. 27 июля 2026 г. в 18:23 UTCinvestigating

   Мы видим ухудшение производительности некоторых узлов в нашем поисковом кластере для индексированных лиц. Мы продолжаем исследовать первопричину и возможные исправления.

3. 27 июля 2026 г. в 18:51 UTCidentified

   Мы определили первопричину снижения производительности в нашем поисковом кластере в США и активно работаем над ее устранением. После этого мы полностью восстановимся.

4. 27 июля 2026 г. в 19:18 UTCmonitoring

   Мы внедрили исправление и продолжаем следить за качеством времени обработки, которое сейчас улучшено.

5. 27 июля 2026 г. в 19:20 UTCmonitoring

   Время обработки постоянно улучшается, все системы работают.

6. 27 июля 2026 г. в 19:21 UTCresolved

   Время обработки возвращается к норме. Сейчас этот вопрос решен. Скоро после смерти.

Автоматический перевод официального обновления инцидента.

1. 24 июля 2026 г. в 04:18 UTCinvestigating

   Identity Enhanced испытывает значительное снижение четких ставок для заявителей во всем мире, кроме Великобритании

2. 24 июля 2026 г. в 04:36 UTCidentified

   Мы работаем с нашим сторонним поставщиком для решения этой проблемы и будем делиться обновлениями по мере их появления.

3. 24 июля 2026 г. в 04:55 UTCidentified

   Мы продолжаем работать над решением этой проблемы.

4. 24 июля 2026 г. в 05:09 UTCmonitoring

   Мы видим, что восстановление услуг нашего провайдера и показатели успеха запросов улучшаются. Мы продолжаем внимательно следить за ситуацией.

5. 24 июля 2026 г. в 07:08 UTCresolved

   Поставщик решил проблему, и теперь сервис работает нормально

Автоматический перевод официального обновления инцидента.

1. 23 июня 2026 г. в 02:38 UTCinvestigating

   We cannot complete QES tasks because our electronic signature provider is encountering issues.

2. 23 июня 2026 г. в 02:57 UTCidentified

   Our provider is experiencing issues. All QES tasks cannot complete for now.

3. 23 июня 2026 г. в 03:20 UTCidentified

   Our provider is still experiencing issues. All QES tasks cannot complete for now.

4. 23 июня 2026 г. в 03:45 UTCmonitoring

   The issue has been fixed. We're monitoring and resuming blocked QES tasks, if they can be.

5. 23 июня 2026 г. в 03:49 UTCresolved

   This incident has been resolved.

1. 22 июня 2026 г. в 17:44 UTCmonitoring

   We're currently monitoring the EU cluster after an Amazon RDS issue.

2. 22 июня 2026 г. в 17:56 UTCresolved

   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.

3. 2 июля 2026 г. в 14:27 UTCpostmortem

   **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.

1. 17 июня 2026 г. в 04:59 UTCidentified

   One of our providers is still experiencing issues, resulting in higher TaT for electronic signature tasks.

2. 17 июня 2026 г. в 05:30 UTCidentified

   Our provider is actively working on fixing the issue.

3. 17 июня 2026 г. в 06:19 UTCidentified

   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.

4. 17 июня 2026 г. в 06:50 UTCidentified

   Our provider's error rate dropped significantly. The TaT of QES tasks is now close to the usual value.

5. 17 июня 2026 г. в 08:17 UTCidentified

   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.

6. 17 июня 2026 г. в 08:48 UTCmonitoring

   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.

7. 17 июня 2026 г. в 09:23 UTCresolved

   The QES tasks TaT is back to normal.

1. 16 июня 2026 г. в 22:19 UTCidentified

   Our electronic signature tasks are taking more time to complete because one of our providers is doing some maintenance.

2. 16 июня 2026 г. в 22:52 UTCidentified

   Our provider is still not able to answer to all requests, resulting in longer-than-usual electronic signature task processing time.

3. 16 июня 2026 г. в 23:17 UTCresolved

   The service is operational again.

1. 13 июля 2026 г. в 08:39 UTCresolved

   Incident was solved.

2. 13 июля 2026 г. в 08:40 UTCpostmortem

   ## 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.

1. 6 июня 2026 г. в 14:08 UTCinvestigating

   Some Watchlist search search profiles are not working correctly the impacted reports are not being processed. We are investigation the root cause.

2. 6 июня 2026 г. в 14:36 UTCidentified

   We identified the issue and are implementing a fix.

3. 6 июня 2026 г. в 15:05 UTCmonitoring

   The issue has been fixed, and the reports are being processed correctly. We are still monitoring the service.

4. 6 июня 2026 г. в 15:49 UTCresolved

   This incident has been resolved.

1. 12 мая 2026 г. в 12:25 UTCidentified

   We are facing issues with one of our providers and we see a slight decrease in clear rate for Identity Reports in UK jurisdiction

2. 12 мая 2026 г. в 12:55 UTCmonitoring

   A fix has been implemented and we are monitoring the results. All clear rates should be back to normal

3. 12 мая 2026 г. в 13:14 UTCresolved

   All reports are back to normal.

1. 9 мая 2026 г. в 11:27 UTCidentified

   We cannot complete QES tasks because our electronic signature provider is encountering issues.

2. 9 мая 2026 г. в 11:27 UTCidentified

   The provider is working on a fix.

3. 9 мая 2026 г. в 11:32 UTCmonitoring

   Our provider fixed the issue. QES tasks are completing now. Tasks started during the incident were resumed.

4. 9 мая 2026 г. в 12:03 UTCresolved

   The service is operational, no error where detected after the fix.

1. 5 мая 2026 г. в 06:52 UTCinvestigating

   We noticed an issue with our QES tasks, we're investigating.

2. 5 мая 2026 г. в 06:56 UTCidentified

   Our provider is experiencing issues. All QES tasks cannot complete for now.

3. 5 мая 2026 г. в 07:35 UTCidentified

   Our provider is fixing the issue. QES tasks still cannot complete.

4. 5 мая 2026 г. в 08:04 UTCmonitoring

   The issue has been fixed. We're monitoring and resuming blocked QES tasks, if they can be.

5. 5 мая 2026 г. в 08:39 UTCresolved

   QES is operational again.

1. 21 апреля 2026 г. в 14:56 UTCidentified

   We identified an issue with one of our provider and some QES tasks may encounter some problems.

2. 21 апреля 2026 г. в 15:14 UTCidentified

   Our provider is still experiencing issues. All QES tasks cannot complete for now.

3. 21 апреля 2026 г. в 16:12 UTCidentified

   Our provider continues experiencing issues and is working on a fix.

4. 21 апреля 2026 г. в 17:02 UTCidentified

   Our provider is slowly recovering, we expect some QES tasks to complete.

5. 21 апреля 2026 г. в 17:12 UTCresolved

   QES is operational again.