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

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

   В настоящее время мы изучаем проблему, вызывающую медлительность в представлении о работе в рамках Phrase TMS (EU). Пользователи могут испытывать задержку времени загрузки или снижение производительности при доступе к функциям управления проектами. Наша команда активно работает над выявлением первопричины и восстановлением нормальной работы как можно быстрее.

2. 1 сентября 2026 г. в 15:00 UTCinvestigating

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

3. 1 сентября 2026 г. в 15:34 UTCmonitoring

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

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

   Проблема решена, и производительность стабильна.

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

1. 31 августа 2026 г. в 15:06 UTCinvestigating

   В настоящее время мы испытываем периодические ошибки при общении с Gengo, одним из наших сторонних поставщиков переводов. Это вызывает тайм-ауты и 502 ошибки при расчете цен и подаче заказов на переводы, направляемые через Gengo, что влияет как на центры обработки данных в ЕС, так и в США. Гэнго подтвердил этот вопрос и ведет расследование.

2. 2 сентября 2026 г. в 11:46 UTCresolved

   Гэнго решил основную проблему с их стороны. Расчеты цен и заявки на перевод в Gengo снова работают.

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

1. 31 августа 2026 г. в 13:11 UTCinvestigating

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

2. 31 августа 2026 г. в 13:22 UTCinvestigating

   Мы продолжаем расследование этого вопроса.

3. 31 августа 2026 г. в 13:46 UTCidentified

   Этот вопрос был определен, и в настоящее время осуществляется исправление.

4. 31 августа 2026 г. в 16:02 UTCmonitoring

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

5. 31 августа 2026 г. в 16:53 UTCresolved

   Вопрос решен.

6. 4 сентября 2026 г. в 08:45 UTCpostmortem

   ##Введение Мы хотели бы поделиться подробностями об инциденте, который затронул Фразу TMS 31 августа 2026 года. Между 2:26 и 5:57 PM CEST некоторые пользователи устаревшей страницы Project не смогли использовать действия Tools-menu, такие как создание или редактирование заданий и запуск анализов, а нажатие на открытие работы не запустило веб-редактор CAT, как ожидалось, вместо этого возвращая пользователей на страницу проекта. Этот вскрытие объясняет, что произошло, как это было решено, и что мы делаем, чтобы предотвратить это снова. ##Время ** 31 августа 2026 года в 2:26 вечера CEST** - Изменение кода достигло производства, содержащего дефект, который нарушил выполнение сценария на странице Проекта для любого пользователя, который его загрузил. ** 31 августа 2026 года в 2:49 вечера CEST** - Первые отчеты о клиентах появились в описании кнопок «Инструменты-меню» как отключенных и не открывающихся в редакторе рабочих мест. 31 августа 2026 года, примерно в 3:10 вечера по восточному времени - Наша команда определила первопричину проблемы. ** 31 августа 2026 года в 3:48 вечера CEST** — исправление основного дефекта было завершено. ** 31 августа 2026 года в 4:04 вечера CEST** - Фиксация была проверена в предпроизводственной среде. ** 31 августа 2026 года в 5:18 вечера CEST** — Началось развертывание фиксатора к производству. ** 31 августа 2026 года в 5:57 вечера CEST** Ремонт был полностью запущен в производство, и нормальная функциональность была восстановлена для всех пострадавших клиентов. ##Коренная причина Инцидент был вызван изменением кода, предназначенного для устранения несвязанной, незначительной проблемы отображения на общих страницах проекта. Это изменение изменило способ вставки значения в скрипт, встроенный непосредственно на странице. Система, которая отображает страницу, автоматически кодирует значения для безопасности, но это кодирование не различает значение, размещаемое в обычном контенте страницы, по сравнению с внутренним сценарием. В результате синтаксис встроенного скрипта был бесшумно нарушен, как только изменение достигло производства. Поскольку браузеры перестают выполнять любой дополнительный код на странице, как только они сталкиваются с недействительным синтаксисом сценария, каждый сценарий, размещенный после этого момента на странице, перестает работать, а не только часть, связанная с первоначальным изменением. Вот почему клиенты испытали то, что выглядело как две отдельные проблемы (отключенные кнопки меню и рабочие места, не открывающиеся в редакторе), которые на самом деле были побочными эффектами одного и того же дефекта. Проблема не была обнаружена до релиза, потому что проверка, выполненная в то время, подтвердила, что вставленные базовые данные были правильными, но не загрузила фактическую страницу в браузере, чтобы подтвердить, что она отображается и выполняется правильно. ## Меры по предотвращению рецидивов 1. ** Исправлено** - Основной дефект был исправлен и доставлен на производство в тот же день, когда он был обнаружен. 2. ** Инжиниринговое руководство обновлено** Мы обновили нашу внутреннюю инженерную документацию, чтобы четко описать эту конкретную схему отказа и правильный, безопасный способ ее обработки, поэтому эта категория ошибок улавливается во время проверки кода в будущем. 3. ** Автоматизированные улучшения обнаружения** Мы работаем над добавлением автоматизированного мониторинга для этого класса сбоев интерфейса, поэтому аналогичные проблемы могут быть обнаружены и решены до того, как клиенты будут затронуты, а не полагаться на отчеты клиентов.

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

1. 19 августа 2026 г. в 12:16 UTCinvestigating

   В настоящее время мы изучаем проблему, затрагивающую функциональность Translation Memory в Phrase TMS (EU). За это время у пользователей могут возникнуть проблемы с созданием переводческих воспоминаний и других связанных с ними операций. Наша команда активно работает над выявлением причины и восстановлением полной функциональности как можно быстрее.

2. 19 августа 2026 г. в 12:34 UTCidentified

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

3. 19 августа 2026 г. в 13:19 UTCmonitoring

   Было принято решение, и мы следим за ситуацией.

4. 19 августа 2026 г. в 14:09 UTCresolved

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

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

1. 7 августа 2026 г. в 07:27 UTCinvestigating

   We are currently investigating an issue with branching events missing in Phrase Strings (EU), which may cause changes to not be applied when branches are merged.

2. 7 августа 2026 г. в 07:54 UTCinvestigating

   We are continuing to investigate this issue.

3. 7 августа 2026 г. в 08:18 UTCidentified

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

4. 7 августа 2026 г. в 08:30 UTCmonitoring

   A fix has been implemented. The backlog of missing events is now being processed. Once the queue is fully processed, unmerged branches will automatically receive the missing changes. We are monitoring the queue and results.

5. 7 августа 2026 г. в 14:12 UTCresolved

   Changes made to branches during the incident window are now fully applied. Merged branches that were affected have been identified and impacted customers have been contacted directly. This incident has been resolved.

1. 6 августа 2026 г. в 08:11 UTCinvestigating

   We are currently investigating an issue affecting Connectors in Phrase TMS. Customers may be unable to access or use Connector functionality during this time. Our engineering team is actively working to identify the cause and restore full service as quickly as possible.

2. 6 августа 2026 г. в 08:18 UTCinvestigating

   We are continuing to investigate this issue.

3. 6 августа 2026 г. в 08:43 UTCmonitoring

   We have identified the root cause and the issue has now been resolved. Connectors should be appearing as active again. We will continue to monitor the situation to ensure full stability.

4. 6 августа 2026 г. в 12:00 UTCmonitoring

   We continue monitoring the situation.

5. 6 августа 2026 г. в 13:19 UTCresolved

   The incident has been resolved and all components are back to operational.

1. 28 июля 2026 г. в 07:19 UTCinvestigating

   Инженерная группа выявила проблему с Orchestrator, когда новый Workflow Engine в настоящее время не выполняет рабочие процессы. Проблема находится под следствием.

2. 28 июля 2026 г. в 07:53 UTCinvestigating

   Мы продолжаем расследование этого вопроса.

3. 28 июля 2026 г. в 08:30 UTCidentified

   Этот вопрос был определен, и в настоящее время осуществляется исправление.

4. 28 июля 2026 г. в 08:35 UTCmonitoring

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

5. 28 июля 2026 г. в 11:49 UTCresolved

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

6. 30 июля 2026 г. в 07:09 UTCpostmortem

   ##Введение Мы хотели бы поделиться подробностями об инциденте, который произошел 27-28 июля 2026 года. В течение этого периода выполнение рабочих процессов в движке рабочего процесса Next-Gen не могло прогрессировать и оставалось в «исполняющем» состоянии. Во время инцидента никаких данных не было потеряно. Вскрытие объясняет, что произошло, когда это было решено, и шаги, которые мы предприняли, чтобы предотвратить повторение. ##Время ** 27 июля 2026 в 18:55 CEST** Движок рабочего процесса начал производить ошибки, поскольку производительность запросов базы данных ухудшилась. Выполнение рабочих процессов застопорилось и перестало прогрессировать. ** 27 июля 2026 в 20:54 CEST** Получен первый клиентский отчет о казнях, застрявших в «исполнении». ** 27 июля 2026 в 22:39 CEST** Инцидент был официально объявлен. ** 28 июля 2026 года в 02:18 CEST** — Временная помощь была возобновлена при перезапуске службы. ** 28 июля 2026 в 05:15 CEST** - Проблема повторялась по мере того, как сохранялась основная проблема производительности базы данных. ** 28 июля 2026 в 09:56 CEST** - Была выявлена и устранена первопричина. Никаких казней не было потеряно; однако из-за частичного перезапуска службы некоторые действия в казнях были восстановлены, что, возможно, привело к тому, что небольшое количество казней потерпело неудачу, которая в противном случае была бы успешной. ** 28 июля 2026 в 13:46 CEST** Полное отставание в казнях было подтверждено. Система была признана стабильной. ** 28 июля 2026 года в 13:48 CEST** — Инцидент разрешен. ##Коренная причина Инцидент был вызван прогрессивным вздутием индексов баз данных, используемых системой планирования рабочих процессов. Производительность этих конкретных индексов постепенно ухудшалась с течением времени, поскольку они накапливали мертвые записи индекса из предыдущих записей и обновлений. Механизм планирования работы получает блоки координации на уровне базы данных при запросе этих индексов, чтобы определить, какие рабочие места отправлять. По мере того, как поиски индексов росли медленнее, они начали превышать настроенный тайм-аут в базе данных. Когда поиск был отменен тайм-аутом, процесс планирования, ответственный за эту работу, потерпел крах и возобновился. Без запуска планировщиков не могли быть отправлены шаги рабочего процесса, и все выполняемые рабочие процессы застряли. Сам сервер базы данных оставался здоровым на протяжении всего инцидента, с нормальным процессором и уровнем подключения. Проблема заключалась исключительно в блокировке и задержке внутри слоя планирования. Сервисный перезапуск очистил разбитые процессы и временно восстановил исполнение. Однако из-за того, что раздутие индекса все еще присутствовало, такая же деградация повторялась после возобновления нагрузки запроса. Ручной индекс полностью восстановил производительность и решил проблему. ## Меры по предотвращению рецидивов 1. ** Автоматизированное техническое обслуживание индекса добавлено ** - Запланированное автоматическое техническое обслуживание индекса было настроено для соответствующих индексов. Это гарантирует, что вздутие не может накапливаться с течением времени и устраняет условия, которые вызвали этот инцидент. 2. ** Индексы наследственности удалены ** - Неиспользованные индексы устаревших баз данных были идентифицированы и удалены, что снижает общую поверхность обслуживания и упрощает гигиену будущих индексов. 3. ** Обновленная информация о мониторинге** Наш ландшафт мониторинга пересматривается и обновляется, чтобы отразить текущее состояние двигателя рабочего процесса. Эта работа закроет пробелы, которые позволили не обнаружить деградацию до первого отчета клиента.

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

1. 27 июля 2026 г. в 23:48 UTCinvestigating

   Инженеры выявили проблему с Orchestrator, когда новый Workflow Engine в настоящее время не выполняет рабочие процессы. Проблема находится под следствием.

2. 28 июля 2026 г. в 00:41 UTCresolved

   Все рабочие процессы выполняются снова, как и ожидалось.

3. 30 июля 2026 г. в 07:08 UTCpostmortem

   ##Введение Мы хотели бы поделиться подробностями об инциденте, который произошел 27-28 июля 2026 года. В течение этого периода выполнение рабочих процессов в движке рабочего процесса Next-Gen не могло прогрессировать и оставалось в «исполняющем» состоянии. Во время инцидента никаких данных не было потеряно. Вскрытие объясняет, что произошло, когда это было решено, и шаги, которые мы предприняли, чтобы предотвратить повторение. ##Время ** 27 июля 2026 в 18:55 CEST** Движок рабочего процесса начал производить ошибки, поскольку производительность запросов базы данных ухудшилась. Выполнение рабочих процессов застопорилось и перестало прогрессировать. ** 27 июля 2026 в 20:54 CEST** Получен первый клиентский отчет о казнях, застрявших в «исполнении». ** 27 июля 2026 в 22:39 CEST** Инцидент был официально объявлен. ** 28 июля 2026 года в 02:18 CEST** — Временная помощь была возобновлена при перезапуске службы. ** 28 июля 2026 в 05:15 CEST** - Проблема повторялась по мере того, как сохранялась основная проблема производительности базы данных. ** 28 июля 2026 в 09:56 CEST** - Была выявлена и устранена первопричина. Никаких казней не было потеряно; однако из-за частичного перезапуска службы некоторые действия в казнях были восстановлены, что, возможно, привело к тому, что небольшое количество казней потерпело неудачу, которая в противном случае была бы успешной. ** 28 июля 2026 в 13:46 CEST** Полное отставание в казнях было подтверждено. Система была признана стабильной. ** 28 июля 2026 года в 13:48 CEST** — Инцидент разрешен. ##Коренная причина Инцидент был вызван прогрессивным вздутием индексов баз данных, используемых системой планирования рабочих процессов. Производительность этих конкретных индексов постепенно ухудшалась с течением времени, поскольку они накапливали мертвые записи индекса из предыдущих записей и обновлений. Механизм планирования работы получает блоки координации на уровне базы данных при запросе этих индексов, чтобы определить, какие рабочие места отправлять. По мере того, как поиски индексов росли медленнее, они начали превышать настроенный тайм-аут в базе данных. Когда поиск был отменен тайм-аутом, процесс планирования, ответственный за эту работу, потерпел крах и возобновился. Без запуска планировщиков не могли быть отправлены шаги рабочего процесса, и все выполняемые рабочие процессы застряли. Сам сервер базы данных оставался здоровым на протяжении всего инцидента, с нормальным процессором и уровнем подключения. Проблема заключалась исключительно в блокировке и задержке внутри слоя планирования. Сервисный перезапуск очистил разбитые процессы и временно восстановил исполнение. Однако из-за того, что раздутие индекса все еще присутствовало, такая же деградация повторялась после возобновления нагрузки запроса. Ручной индекс полностью восстановил производительность и решил проблему. ## Меры по предотвращению рецидивов 1. ** Автоматизированное техническое обслуживание индекса добавлено ** - Запланированное автоматическое техническое обслуживание индекса было настроено для соответствующих индексов. Это гарантирует, что вздутие не может накапливаться с течением времени и устраняет условия, которые вызвали этот инцидент. 2. ** Индексы наследственности удалены ** - Неиспользованные индексы устаревших баз данных были идентифицированы и удалены, что снижает общую поверхность обслуживания и упрощает гигиену будущих индексов. 3. ** Обновленная информация о мониторинге** Наш ландшафт мониторинга пересматривается и обновляется, чтобы отразить текущее состояние двигателя рабочего процесса. Эта работа закроет пробелы, которые позволили не обнаружить деградацию до первого отчета клиента.

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

1. 20 июля 2026 г. в 12:53 UTCresolved

   Между 16 июня 2026 года 01:00PM CEST и 17 июня 2026 года 11:00AM CEST разъем Phrase Job Sync имел ухудшенную производительность. Клиенты, использующие Job Sync с типом подключения по умолчанию, испытывали сбои. Инженерная команда определила первопричину и предоставила исправление.

2. 20 июля 2026 г. в 12:54 UTCpostmortem

   ###Введение Мы хотели бы поделиться более подробной информацией о событиях, которые произошли с Phrase между 16 июня 2026 года, 01:00PM CEST и 17 июня 2026 года, 11:00AM CEST, что привело к ухудшению производительности API Phrase Strings, в результате чего клиенты, использующие Job Sync с типом подключения по умолчанию, испытывают сбои. Мы приносим извинения за нарушения и стремимся предотвратить подобные инциденты в будущем. ###Время ** 16 июня 2026 года @ 01:00 PM CEST** — Job Sync начала выходить из строя для клиентов, использующих тип подключения по умолчанию. Коннекторы не смогли аутентифицироваться против API Phrase Strings. ** 17 июня 2026 @ 10:00 AM CEST** - Провал аутентификации был выявлен инженерной командой. ** 17 июня 2026 @ 10:28 AM CEST** — Подтверждена область воздействия: Пострадали клиенты, использующие соединение Job Sync по умолчанию. Клиенты, использующие разъемы на основе токенов, не пострадали. ** 17 июня 2026 @ 10:29 AM CEST** — Была выявлена первопричина: Недавнее изменение, которое добавило поддержку мультиплатформенных токенов, непреднамеренно ввело ошибки с некоторыми существующими токенами платформы. ** 17 июня 2026 года @ 10:40 AM CEST** — исправление подготовлено и представлено на рассмотрение. ** 17 июня 2026 @ 10:53 AM CEST** - Ремонт был развернут, а функциональность JobSync полностью восстановлена. ###Коренная причина Изменение кода, введенное для добавления поддержки многоплатформенных токенов аутентификации, изменило то, как входящие токены платформы проверяются и обрабатываются в API Phrase Strings. Это изменение не было совместимо с существующим форматом токенов, используемым по умолчанию. В результате токены платформы были отклонены API Strings с ответом «401 Unauthorized». Разъем повторно устанавливал соединение до тех пор, пока не исчерпал свой бюджет повторного использования, в результате чего все затронутые операции вышли из строя. Клиенты, использующие токены личного доступа, не пострадали, поскольку их токены следуют другому пути кода. ###Действия по предотвращению рецидивов Основной причиной было обратно несовместимое изменение обработки токенов, которое не было обнаружено во время разработки. Принимаются следующие меры: ** Тестирование совместимости формата токена в изменениях: ** При введении нового формата токена/аутентификации наряду с существующим, тесты должны явно охватывать случай перехода — токены старого формата, обрабатываемые в соответствии с новой логикой обнаружения, а не только каждый формат в отдельности.

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

1. 16 июля 2026 г. в 15:47 UTCinvestigating

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

2. 16 июля 2026 г. в 16:29 UTCidentified

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

3. 16 июля 2026 г. в 17:31 UTCmonitoring

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

4. 16 июля 2026 г. в 19:04 UTCidentified

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

5. 17 июля 2026 г. в 13:02 UTCmonitoring

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

6. 20 июля 2026 г. в 12:07 UTCresolved

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

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

1. 16 июля 2026 г. в 14:49 UTCinvestigating

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

2. 16 июля 2026 г. в 15:27 UTCinvestigating

   Мы продолжаем расследование этого вопроса.

3. 16 июля 2026 г. в 15:27 UTCidentified

   Этот вопрос был определен, и в настоящее время осуществляется исправление.

4. 16 июля 2026 г. в 15:41 UTCmonitoring

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

5. 16 июля 2026 г. в 16:12 UTCresolved

   Orchestrator (EU) доступен с 5:32 PM CEST. Все ожидаемые казни обрабатываются. Этот инцидент был урегулирован.

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

1. 10 июля 2026 г. в 14:24 UTCinvestigating

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

2. 10 июля 2026 г. в 14:37 UTCmonitoring

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

3. 10 июля 2026 г. в 15:24 UTCresolved

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

4. 7 августа 2026 г. в 07:14 UTCpostmortem

   ## Introduction On July 10, 2026, parts of the Phrase Strings frontend at [app.phrase.com](http://app.phrase.com/) failed to load correctly for a short period, after required stylesheets and scripts failed to load — the underlying service itself stayed available. The issue began at 16:08 CEST and was resolved by 16:27 CEST. This post-mortem explains what happened and what we're doing to prevent a recurrence. ## Timeline * **Jul 10, 2026 at 16:08 CEST** – A deployment introduced new application assets that were never uploaded to our storage service, so the application could no longer load its stylesheets and scripts for customers. * **Jul 10, 2026 at 16:21 CEST** – Issue detected, incident declared. * **Jul 10, 2026 at 16:24 CEST** – Root cause identified. * **Jul 10, 2026 at 16:26 CEST** – Fix applied. * **Jul 10, 2026 at 16:27 CEST** – Customer-facing impact ended. * **Jul 10, 2026 at 16:32 CEST** – Incident downgraded to monitoring while the underlying configuration was addressed. * **Jul 10, 2026 at 17:12 CEST** – Configuration corrected, incident resolved. ## Root Cause During a planned, routine maintenance, a configuration change unintentionally disabled the process that uploads application assets \(stylesheets, scripts\) to our storage and content-delivery service. This went unnoticed at first, since the assets already in place kept working and no new versions had been shipped yet. On July 10, 2026, a deployment shipped new versions of these assets. Because uploading was still disabled, the new files never reached the storage service, and the application could not load its stylesheets and scripts. ## Actions to Prevent Recurrence 1. **Asset synchronization re-enabled** – The disabled process was fixed, restoring correct asset delivery. 2. **Asset availability monitoring** – Adding monitoring to detect asset load failures automatically, before customers are affected.

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

1. 8 июля 2026 г. в 12:57 UTCinvestigating

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

2. 8 июля 2026 г. в 13:08 UTCmonitoring

   Вопрос определен, исправление осуществлено, и мы следим за ситуацией.

3. 8 июля 2026 г. в 13:55 UTCresolved

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

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

1. 7 июля 2026 г. в 08:34 UTCinvestigating

   We are currently investigating issues with CAT Web Editor.

2. 7 июля 2026 г. в 08:59 UTCmonitoring

   The issue has been identified, a fix was implemented and we are monitoring the situation.

3. 7 июля 2026 г. в 09:27 UTCresolved

   The incident has been resolved.

1. 29 июня 2026 г. в 07:30 UTCinvestigating

   Hi everyone, this is a test. Please ignore, thank you!

2. 29 июня 2026 г. в 08:05 UTCidentified

   Hi everyone, this is a test. Please ignore, thank you!

3. 29 июня 2026 г. в 08:09 UTCresolved

   This incident has been resolved.

1. 26 июня 2026 г. в 16:19 UTCinvestigating

   Hi everyone, this is a test. Please ignore. Thank you!

1. 26 июня 2026 г. в 07:31 UTCinvestigating

   Hello everyone, this is a test. Please ignore, thank you!

2. 26 июня 2026 г. в 08:16 UTCinvestigating

   Hello everyone, this is a test. We're "investigating" the issue. Please ignore, thank you!

1. 26 июня 2026 г. в 07:00 UTCinvestigating

   Hi everyone, this is a test. Please ignore, thank you!

2. 26 июня 2026 г. в 07:02 UTCresolved

   This incident has been resolved.

1. 23 июня 2026 г. в 12:53 UTCinvestigating

   Hello everyone, this is a test, kindly ignore.

2. 23 июня 2026 г. в 12:57 UTCresolved

   This incident has been resolved.

1. 22 июня 2026 г. в 14:16 UTCinvestigating

   This is a test, please ignore.

2. 22 июня 2026 г. в 14:21 UTCinvestigating

   This incident has been resolved.