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

1. 21 октября 2026 г. в 16:25 UTCmonitoring

   Статус: Информационный, без последствий Мы знаем об уязвимости PHP, известной как «php2shell» (CVE-2026-109618 и CVE-2026-109619). Мы оценили уязвимость и можем подтвердить, что она не влияет на Viedoc Suite. От наших клиентов не требуется никаких действий, и это не влияет на доступность, безопасность или целостность ваших данных. Мы продолжаем следить за ситуацией в рамках наших стандартных процессов безопасности. Если что-то изменится, мы обновим это уведомление.

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

1. 8 сентября 2026 г. в 14:07 UTCinvestigating

   Предупреждения по электронной почте, вызванные действиями EDC в Viedoc, периодически падают на производственном экземпляре ЕС в течение следующих временных окон: Понедельник, 31 августа, 11:02-17:25 CEST Четверг, 3 сентября, 13:31 CEST - Пятница, 4 сентября, 22:07 CEST Большинство писем отправляются, как и ожидалось, но подмножество задерживается или, в некоторых случаях, не доставляется вообще. Никакие другие случаи не затрагиваются. Мы активно изучаем и будем публиковать обновления по мере поступления дополнительной информации.

2. 10 сентября 2026 г. в 13:51 UTCmonitoring

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

3. 11 сентября 2026 г. в 08:25 UTCresolved

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

4. 17 сентября 2026 г. в 08:12 UTCpostmortem

   **Спорадические сбои в работе электронной почты на производстве ЕС** **Описание** Во время двух окон ниже оповещения по электронной почте, вызванные действиями в Viedoc, отправлялись с перерывами. Большинство было доставлено, как и ожидалось. Подмножество было задержано, а некоторые вообще не были доставлены. * Понедельник, 31 августа, 11:02-17:25 CEST * четверг, 3 сентября, 13:31 CEST - пятница, 4 сентября, 22:07 CEST Оповещения по электронной почте в Viedoc не отправляются приложением в тот момент, когда пользователь сохраняет данные. Они производятся путем фоновой обработки, которая запускается сразу после этого и решает, на основе конфигурации вашего исследования, какие оповещения должны быть отправлены. Во время этих двух окон фоновая обработка не всегда завершалась, поэтому оповещения, которые она производила, задерживались или никогда не генерировались. Данные, введенные и сохраненные пользователями в течение этих периодов, хранились, как и ожидалось. Прерывание затронуло работу, выполняемую конкретными серверами обработки, а не платформой в целом, поэтому оповещения были прерывистыми, а не полностью прекращались. ** Причина** Обработка фона Viedoc проходит через несколько серверов, работающих параллельно. Каждый сервер нуждается в рабочем соединении с общим внутренним сервисом, который Viedoc использует для безопасной координации этой работы, например, для обеспечения того, чтобы два сервера никогда не обрабатывали один и тот же объект в один и тот же момент. Во время этих окон отдельные серверы потеряли это соединение и не восстановили его. Пострадавший сервер продолжал принимать работу, но не мог ее завершить. Другие серверы, работающие в то же время, не пострадали, поэтому влияние было прерывистым и платформа продолжала выглядеть здоровой в целом. **Правильное действие** * Пострадавшие серверы были идентифицированы и заменены. Обычная обработка, включая генерацию оповещений, возобновилась сразу после этого. Мы подтвердили, что последующая обработка завершена правильно, и что никаких дальнейших сбоев электронной почты не произошло. ** Меры профилактики** Увеличение контроля Мы увеличили мониторинг и добавили оповещения, которые обнаруживают этот конкретный сбой на любом отдельном сервере гораздо быстрее, предотвращая его бесшумный отказ. Основная причина - продолжающееся расследование Расследование того, почему эти связи потерпели неудачу, остается открытым, и мы рассматриваем его отдельно от вышеупомянутых мер.

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

1. 4 сентября 2026 г. в 16:15 UTCresolved

   У нас было временное нарушение, которое привело к тому, что клиенты не могли связаться с порталами .cn примерно с 23:00 до 00:00. Проблема была в нашей инфраструктуре, и мы приносим извинения за неудобства. Системы вернулись к норме, и нет никаких проблем с конфиденциальностью или целостностью. Эта проблема касается только доступа к нашим системам.

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

1. 17 августа 2026 г. в 09:54 UTCmonitoring

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

2. 17 августа 2026 г. в 10:09 UTCmonitoring

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

3. 17 августа 2026 г. в 11:25 UTCresolved

   Инцидент был разрешен Microsoft, и мы можем подтвердить, что Viedoc снова полностью работает. Приносим извинения за неудобства.

4. 17 августа 2026 г. в 12:27 UTCpostmortem

   ##Резюме Мы столкнулись с проблемами в базовом компоненте платформы от Azure \(Azure App Services\) в Центральном регионе Франции, что привело к некоторой потере трафика, который клиенты испытывали, поскольку услуга не была доступна. Наш системный мониторинг сразу же выявил проблемы и предупредил нашу команду платформы, которая ответила в течение 1 минуты. Мы можем подтвердить в течение 15 минут, что проблема была с поставщиком платформы. ## Пострадавшие случаи Вся продукция в Европе ## Продолжительность 2026-08-17 09:32 UTC до 2026-08-17 11:20 UTC. ##Коренная причина Инфраструктурный компонент Microsoft Azure Cloud, отвечающий за обработку входящих запросов на платформе Azure App Service в Центральном регионе Франции, превысил операционные пороги, сократив доступность сервисных ресурсов, поддерживающих рабочие нагрузки клиентов. В результате Viedoc столкнулся с периодическими проблемами доступности и неудавшимися запросами. # # Влияние Это повлияло на доступность Viedoc, не влияя на достоверность данных, целостность или конфиденциальность. ##Действия Сопровождение с поставщиком платформы о возможностях.

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

1. 29 июля 2026 г. в 13:35 UTCinvestigating

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

2. 29 июля 2026 г. в 14:11 UTCinvestigating

   Этот вопрос связан с выводом из эксплуатации центра обработки данных в Китае, и мы продолжаем расследование.

3. 29 июля 2026 г. в 17:06 UTCresolved

   Инцидент был идентифицирован как проблема в Azure Cloud China, и теперь у нас есть подтверждение того, что проблема была смягчена. Как только у нас будет анализ причин, мы обновим отчет об инциденте. Приносим извинения за любые неудобства.

4. 31 июля 2026 г. в 13:23 UTCpostmortem

   ##Резюме В нашем китайском регионе произошел сбой из-за неисправности конфигурации в нашей платформе, связанной с внутренним обменом сообщениями между компонентами системы, что фактически сделало наш набор продуктов непригодным для использования в течение 4 часов 40 минут. Ожидается, что влияние на клиентов будет низким из-за того, что в Китае в ночное время обычно очень низкий объем трафика. Наш системный мониторинг немедленно выявил проблемы и предупредил нашу команду платформы, которая ответила в течение 1 минуты, и мы могли подтвердить в течение 1 часа, что проблема была с поставщиком платформы. Билет поддержки типа А был зарегистрирован у нашего провайдера платформы, который мог подтвердить, что у них действительно была проблема через 2 часа и 32 минуты, и она была решена через 38 минут после этого. ## Пострадавшие случаи Вся продукция в Китае ## Продолжительность 2026-07-29 12:07 UTC до 2026-07-29 16:47 UTC. ##Коренная причина Ошибка конфигурации, допущенная провайдером платформы 21ViaNet/Microsoft Azure Cloud China. # # Влияние Доступность только. Целостность и конфиденциальность данных не затронуты. ##Действия Сопровождение работы с провайдером платформы для улучшения операционных процедур, мониторинга и реагирования на инциденты.

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

1. 9 июля 2026 г. в 21:40 UTCidentified

   С момента выпуска 4.95 Viedoc Мои материалы были записаны в базе данных с использованием времени UTC, а не местного часового пояса сайта. Если дата UTC и местная дата сайта отличаются на момент подачи заявки, дата события в клинике Viedoc будет неправильно отражать дату UTC вместо местной даты. В зависимости от окон ввода данных, определенных в дизайне исследования, это также может привести к запросам из окна. Аудиторский след в интерфейсе клиники Viedoc, доступ к которому осуществляется через «Показать историю», отображает правильную дату и время в соответствии с местным часовым поясом. Эта проблема затрагивает как текущие, так и устаревшие версии приложения Viedoc Me. Проблема была выявлена, и в настоящее время готовится исправление. Это исправление обеспечит хранение новых представлений с использованием локального часового пояса сайта, но не исправит временные метки или запросы из окна, которые уже произошли. Они будут рассмотрены в будущем обновлении.

2. 14 июля 2026 г. в 14:57 UTCidentified

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

3. 16 июля 2026 г. в 06:53 UTCidentified

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

4. 16 июля 2026 г. в 09:42 UTCresolved

   Инцидент был урегулирован с выпуском исправления 4.95.2 для всех учебных и производственных инстанций. Этот выпуск предотвращает повторение проблемы в будущем. Тем не менее, даты событий, уже записанные в UTC, пока не изменятся, и любые запросы из окна, уже вызванные этой проблемой, также останутся до исправления. Материалы, хранящиеся в настоящее время в UTC, будут исправлены позднее. Сроки этой коррекции пока не подтверждены.

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

1. 10 июня 2026 г. в 18:32 UTCinvestigating

   After the Viedoc 4.95 release, when a revision is applied to a form containing a repeating item group, and a user upgrades the form from the landing page, data previously entered in the repeating item group is cleared. The issue is occurring on the EU and US training and production instances. Investigation is ongoing. Until further information is known, we advise all customers to refrain from applying revisions requiring form upgrades on forms containing repeating item groups.

2. 10 июня 2026 г. в 23:31 UTCidentified

   The issue has been identified and a fix is being implemented.

3. 16 июня 2026 г. в 14:45 UTCidentified

   Hotfix 4.95.1 has been released on the US training and production instances. The incident is resolved on those instances. The hotfix will be deployed to EU training and production instances tomorrow.

4. 17 июня 2026 г. в 10:40 UTCresolved

   Hotfix 4.95.1 has been released on the EU training and production instances. The incident is now resolved on all instances.

1. 3 июня 2026 г. в 12:12 UTCmonitoring

   Temporary operational disturbance observed in the Viedoc suite on the Chinese instance (clinic.viedoc.cn).

2. 3 июня 2026 г. в 13:23 UTCresolved

   This incident has been resolved.

1. 28 мая 2026 г. в 07:35 UTCinvestigating

   Operational disturbance observed in Viedoc suite on the Chinese instance (clinic.viedoc.cn). Investigations are ongoing since 05:20 CMT

2. 28 мая 2026 г. в 07:38 UTCresolved

   The incident has been resolved since 06:40 CMT

1. 18 мая 2026 г. в 10:24 UTCinvestigating

   Operational disturbance observed in Training on the Chinese instance (clinic.viedoc.cn). Investigations are ongoing.

2. 18 мая 2026 г. в 10:26 UTCinvestigating

   We are continuing to investigate this issue.

3. 18 мая 2026 г. в 10:32 UTCresolved

   This incident has been resolved.

1. 6 мая 2026 г. в 09:48 UTCidentified

   After the Viedoc 4.94 release, the following issues affect the EU and US training and production instances: - Users cannot approve randomization configurations in Viedoc Admin when kit allocation is not used. Randomization and kit allocation in Viedoc Clinic are not affected. - WHO Drug dictionary terms are not loading as expected in the legacy medical coding tool. The new medical coding tool is not affected. We are working on a fix for these issues.

2. 7 мая 2026 г. в 06:34 UTCidentified

   After the Viedoc 4.94 release, the following issues affect the EU and US training and production instances: - Users cannot approve randomization configurations in Viedoc Admin when kit allocation is not used. Randomization and kit allocation in Viedoc Clinic are not affected. - WHO Drug dictionary terms are not loading as expected in the legacy medical coding tool. The new medical coding tool is not affected. - Intermittent failures in Designer, where users are unexpectedly logged out, are affecting certain users. We are working on a fix for these issues, and the Designer issue is currently under investigation.

3. 8 мая 2026 г. в 08:22 UTCidentified

   A hotfix is currently being prepared and will be deployed to both our EU and US instances. Based on preliminary timelines, we expect this release to go out on Monday, May 11.

4. 11 мая 2026 г. в 09:54 UTCresolved

   This incident was resolved this morning with the release of hotfix version 4.94.1 on both the EU and US instances.

1. 27 апреля 2026 г. в 13:04 UTCinvestigating

   Operational disturbance observed in Viedoc 4 on the European instance (v4.viedoc.net). Investigations are ongoing.

2. 27 апреля 2026 г. в 17:40 UTCinvestigating

   Microsoft Azure experienced a power event at their France Central datacenter, caused by a loss of utility power from an external provider. Power has since been restored via backup generators and recovery is underway. As of now, there are no active disruptions to Viedoc services, and we continue to monitor the situation closely.

3. 27 апреля 2026 г. в 17:42 UTCmonitoring

   Microsoft Azure experienced a power event at their France Central datacenter, caused by a loss of utility power from an external provider. Power has since been restored via backup generators and recovery is underway. As of now, there are no active disruptions to Viedoc services, and we continue to monitor the situation closely.

4. 27 апреля 2026 г. в 19:00 UTCresolved

   This incident has been resolved.

1. 9 декабря 2025 г. в 09:37 UTCinvestigating

   We have received reports of intermittent delivery failures affecting text messages sent to numbers with country codes +31 (Netherlands), +32 (Belgium), +33 (France), and +44 (United Kingdom). An investigation is currently underway together with the subproccessor. The default SMS sender is changed from a phone number to "Viedoc" to reduce the risk of texts being treated as spam.

2. 9 декабря 2025 г. в 12:20 UTCresolved

   Since 10.30 CET today text messages are delivered as expected to numbers with country codes previously listed.

1. 5 декабря 2025 г. в 12:25 UTCidentified

   The User Administration Log (Excel) and Log of Users and Roles (PDF) cannot currently be generated for studies containing more than 100 users. This issue was introduced in the 4.90 release and affects all instances where version 4.90 has been deployed. The root cause has been identified, and a corrective fix is currently in preparation.

2. 9 декабря 2025 г. в 08:30 UTCidentified

   A fix has been developed and is currently undergoing testing. The fix is planned to be deployed as a hotfix.

3. 16 декабря 2025 г. в 15:18 UTCresolved

   This issue has been resolved with the release of Viedoc 4.90.1, which was deployed to all production instances on 2025-12-16. The User Administration Log (Excel) and Log of Users and Roles (PDF) can now be generated as expected, including for studies containing more than 100 users.

1. 1 декабря 2025 г. в 13:10 UTCidentified

   Since around 12.30 CET, 1st of December, Viedoc is not sending any emails from the EU and US training and production instances due to a service disruption. The issue has been identified and we are working with our subprocessor to resolve the issue. All emails triggered during the affected period have been queued and will be delivered. The incident is caused by a malfunction at one of our subprocessors.

2. 1 декабря 2025 г. в 13:46 UTCmonitoring

   The email queue is currently being processed, and messages are being delivered, although with a temporary delay.

3. 2 декабря 2025 г. в 08:21 UTCresolved

   The queue had been fully processed at around 9.20 PM CET on 2025-12-01. Since that time emails have been delivered without delay.

1. 25 ноября 2025 г. в 13:31 UTCmonitoring

   Between 13:22 CET and 14:12 CET on 25 November 2025, Viedoc did not send any emails from the EU training and production instance due to a service disruption. The issue was identified and fully resolved at 14:12 CET, after which email processing resumed as normal. All emails triggered during the affected period have been queued and will be delivered. The incident was caused by a malfunction at one of our subprocessors.

2. 25 ноября 2025 г. в 14:16 UTCmonitoring

   The email queue is currently being processed, and messages are being delivered, although with a temporary delay.

3. 26 ноября 2025 г. в 09:08 UTCresolved

   The queue had been fully processed at around 5.30 PM CET on 2025-11-25.

1. 25 ноября 2025 г. в 03:19 UTCresolved

   Operational disturbance observed on the Chinese instance (clinic.viedoc.cn). Resolved

1. 11 ноября 2025 г. в 11:55 UTCresolved

   The planned release of version 4.89 to the CN training and production instances has been cancelled due to unforeseen technical issues specific to the Chinese server environment. As the 4.90 release is already scheduled for December, we will proceed directly from version 4.88 to 4.90 for the CN training and production instances. The impact to end users is minimal, as version 4.89 contains only non-critical bug fixes. No other instances or regions are affected by this change. We appreciate your understanding and apologize for any inconvenience this may cause.

1. 3 ноября 2025 г. в 13:27 UTCresolved

   From approximately 23.44 UTC to 23.54 UTC, users faced issues logging in to the European production instance. Investigations to find the root cause are ongoing. No other instances were affected.

2. 10 ноября 2025 г. в 10:45 UTCpostmortem

   Description From approximately 23.44 UTC to 23.54 UTC on 2025-11-02, users were unable to log in to the European production instance. It is possible that users faced sporadic issues logging in also between approximately 23.00 UTC and 23.44 UTC. No other instances were affected. ‌ Cause The cause of the issue was an unexpected error in the identity provider \(idp\), leading to an accumulating memory consumption during the evening \(UTC\) of 2025-11-02. From approximately 23.00 UTC users would face sporadic failures when trying to log in. From approximately 23.44 UTC users could not log in. At 23.54 UTC on 2025-11-02 the idp was restarted, and users could log in as expected again. ‌ Corrective Action Alerts were triggered when the idp did not respond and the idp was restarted again at 2354 UTC on 2025-11-02. After the restart users could log in as expected again. ‌ Preventive Action Preliminary investigation identified a few improvements that could be made to make the idp more resilient. Implementation of these improvements have been initiated while the investigation of the issue continues.

1. 2 сентября 2025 г. в 13:56 UTCinvestigating

   Emails triggered from EDC actions in Viedoc has been failing sporadically on the EU production instance since approximately 9AM CEST 2025-09-02. No other instances are affected. Investigations are ongoing.

2. 3 сентября 2025 г. в 08:49 UTCidentified

   The issue has been identified and a fix is being implemented.

3. 3 сентября 2025 г. в 11:25 UTCmonitoring

   A fix has been implemented and emails are now being sent as expected. We will continue to monitor the situation.

4. 3 сентября 2025 г. в 14:27 UTCresolved

   Since approximately noon CEST, emails triggered from the EDC has been delivered as expected.

5. 9 сентября 2025 г. в 20:22 UTCpostmortem

   **Description** Between 9AM CEST on 2025-09-02 and noon CEST 2025-09-03 there were sporadic failures in email alerts expected to be triggered from Viedoc on the EU production instance. No other instances were affected. Customers were initially informed through the status page at 15.56 CEST on 2025-09-03. ‌ **Cause** On Tuesday at 9AM CEST on 2025-09-02, there was a very high load on the system. The high load on the system caused worker function apps, used to handle various processes  in the EDC, to scale out to the maximum use of 20 instances in parallel. This caused failures, and in combination with in-built retry policy of failing actions, there was an overload on the system. While form save and form view continued to work as expected throughout the duration of the issue, there were sporadic errors in specific system actions in the post-processing step. * EDC email alerts, configured in the CRF design, were sporadically not sent during this time window. It did not affect all emails. * Terms defined to be coded in the medical coding tool sporadically failed to sync to Viedoc Coder. It did not affect all terms. ‌ **Corrective action** Once the root cause of the exceptions was identified, the worker function app was gradually scaled down to run on 4 instances to avoid having too many actions ongoing at the same time. This work begun around 11AM CET on 2025-09-03 and an immediate improvement could be seen. Around noon 2025-09-03 the situation was completely resolved, and all emails could be sent as expected again. ‌ Email alerts not sent during this issue could not be re-sent and will also not show up in the communication log. ‌ All terms that had not synced properly with Viedoc Coder during the issue, were synced with Viedoc Coder on the afternoon of 2025-09-03 and 2025-09-04. ‌ **Preventive action** Scaling down the worker function app to run on 4 instances is not considered to bring any noticeable impact on performance, but will ensure the same overload issue will not occur again. An evaluation will be performed if it is necessary to scale up the worker function app again and if so, how this could be done without causing any similar issues.