История сбоев Treasure Data

1. 22 октября 2026 г. в 03:24 UTCidentified

   С 13 октября 2026 года 02:00 UTC некоторые импортные задания, которые читают файлы Parquet от Amazon S3, успешно завершаются, но загружают столбцы даты и времени в виде текста (струн) вместо цифр (длинных). Если таблица назначения уже определяет эти столбцы как длинные, импортируемые значения пусты (NULL). Поражаются только столбцы, хранящиеся с типом даты или времени в файле Parquet. Другие столбцы и другие соединители данных не затронуты. Мы определили причину, изменения, внесенные в релиз 13 октября, и готовим исправление. Мы оцениваем весь масштаб воздействия. Мы предоставим обновление через 30 минут.

2. 22 октября 2026 г. в 04:06 UTCidentified

   Мы определили причину импорта колонок даты и времени загрузки Amazon S3 Parquet в виде текста (струн) вместо цифр (длинных) с 13 октября 2026 года 02:00 UTC и внедряем исправление. До тех пор, пока исправление не будет развернуто, затронутые импортные рабочие места продолжают успешно завершаться с этими столбцами, загруженными в виде текста. Другие столбцы и другие соединители данных не затронуты. Мы проверяем целостность данных для данных, импортированных в течение этого периода. Мы предоставим обновление через 1 час.

3. 22 октября 2026 г. в 06:22 UTCidentified

   Мы определили причину импорта колонок даты и времени загрузки Amazon S3 Parquet в виде текста (струн) вместо цифр (длинных) с 13 октября 2026 года 02:00 UTC и внедряем исправление. До тех пор, пока исправление не будет развернуто, затронутые импортные рабочие места продолжают заполняться этими столбцами, загруженными в виде текста. Другие столбцы и другие соединители данных не затронуты. Мы проверяем целостность данных для данных, импортированных в течение этого периода. Мы предоставим обновление через 30 минут.

4. 22 октября 2026 г. в 07:44 UTCmonitoring

   Мы внедрили исправление для Amazon S3 Parquet импорта загрузочных столбцов даты и времени в виде текста. Новые импортные рабочие места загружают эти колонки в виде цифр (длинных), как и до 13 октября 2026 года. Мы проводим мониторинг для обеспечения стабильности. Мы предоставим обновление через 30 минут.

5. 22 октября 2026 г. в 10:15 UTCresolved

   Проблема, из-за которой импорт Amazon S3 Parquet загружает столбцы даты и времени в виде текста (струн) вместо цифр (длинных), была решена. Фиксация была развернута 22 октября 2026 года в 07:40 UTC, и новые импортные рабочие места загружают эти колонки в виде цифр (длинных), как и до 13 октября 2026 года. Данные, импортированные между 13 октября 2026 года 02:00 UTC и 22 октября 2026 года 07:40 UTC, могут содержать затронутые столбцы даты и времени. Мы свяжемся с пострадавшими клиентами напрямую. Мы приносим извинения за неудобства и благодарим вас за терпение.

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

1. 7 октября 2026 г. в 04:21 UTCidentified

   С 22:55 UTC 6 октября пользователи мобильного приложения Treasure AI Voice могут быть не в состоянии передавать новые записи со своего устройства. Передача не выполняется с ошибкой «Несанкционированный». Это влияет как на Wi-Fi, так и на передачу Bluetooth. Мы определили причину и внедряем исправление. Записи, которые уже были переданы, а также их стенограммы и резюме, не затрагиваются. Мы предоставим обновление через 30 минут.

2. 7 октября 2026 г. в 04:27 UTCidentified

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

3. 7 октября 2026 г. в 04:54 UTCmonitoring

   Мы развернули исправление на стороне сервера для сбоев передачи записи в Treasure AI Voice. Новые переводы из мобильного приложения снова увенчались успехом. Обновление приложения не требуется. Записи, которые не удалось перенести во время инцидента, могут быть перенесены снова с устройства. Мы проводим мониторинг для обеспечения стабильности.

4. 7 октября 2026 г. в 05:24 UTCresolved

   Сбои в передаче записей в Treasure AI Voice были устранены. Все системы работают нормально. Между 22:55 UTC 6 октября и 7 октября новые записи не могли быть перенесены из мобильного приложения. Мы развернули исправление на стороне сервера, и обновление приложения не требуется. Записи, которые не удалось перенести в течение этого периода, могут быть перенесены снова с устройства. Спасибо за ваше терпение.

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

1. 30 сентября 2026 г. в 04:36 UTCresolved

   Между 28 сентября (5:30 вечера UTC) и 29 сентября (6:30 вечера UTC) клиенты без сегментов пакетов, которые запланировали обновления атрибутов, увидели бы неудачные работы, предотвращающие загрузку пакетных данных в Reactor. Клиенты могли видеть ошибки, ожидая изменения конфигурации для обновления. Влияние - это любые приложения, персонализации или кампании в реальном времени во время этого окна, которые могут полагаться на устаревшие данные атрибутов пакета. Система восстановилась, и рабочие процессы теперь отправляют обновленные данные.

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

1. 29 сентября 2026 г. в 17:22 UTCinvestigating

   В настоящее время мы расследуем случаи непогрузки данных в Reactor в регионе США (AWS). Обновления данных будут отложены до 24 часов. Мы обновим статус через час.

2. 29 сентября 2026 г. в 18:20 UTCmonitoring

   Реализовано исправление, и мы заметили, что рабочие места успешны.

3. 29 сентября 2026 г. в 21:18 UTCresolved

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

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

1. 28 сентября 2026 г. в 03:41 UTCinvestigating

   В настоящее время мы испытываем проблему с нашей функцией Live Chat для корпоративных и корпоративных планов поддержки. Наша команда ведет активное расследование. Вы все еще можете связаться с нашей службой поддержки, как обычно, по электронной почте [email protected]. Мы ценим ваше терпение и приносим извинения за любые неудобства.

2. 28 сентября 2026 г. в 13:16 UTCresolved

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

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

1. 17 сентября 2026 г. в 03:14 UTCidentified

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

2. 17 сентября 2026 г. в 03:44 UTCmonitoring

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

3. 17 сентября 2026 г. в 06:10 UTCmonitoring

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

4. 18 сентября 2026 г. в 06:51 UTCmonitoring

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

5. 25 сентября 2026 г. в 04:44 UTCmonitoring

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

6. 5 октября 2026 г. в 02:19 UTCmonitoring

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

7. 5 октября 2026 г. в 02:20 UTCmonitoring

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

8. 16 октября 2026 г. в 00:04 UTCresolved

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

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

1. 27 июля 2026 г. в 08:29 UTCresolved

   Между 7/25 и сегодня, 7/27 в 11:30 утра JST, мы столкнулись с проблемой ухудшения производительности, затрагивающей BulkLoad (импорт разъемов данных), экспорт результатов (активация) и импорт навалок. После сообщений, полученных сегодня утром, наша команда инженеров исследовала проблему и определила в качестве первопричины высокую системную нагрузку в определенных условиях (повышение задержки связи внутренних компонентов). Проблема была решена полным вращением наших серверных узлов, а полная производительность была восстановлена по состоянию на 11:30 утра по JST. Мы искренне извиняемся за причиненные неудобства. В настоящее время мы пересматриваем наши правила мониторинга и предупреждения, чтобы предотвратить подобные проблемы в будущем.

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

1. 7 июля 2026 г. в 17:04 UTCinvestigating

   Мы наблюдаем ухудшение показателей в Treasure Work и tdx в регионе Токио. Этот выпуск ограничен моделью Claude Haiku 4.5 только в регионе Токио. Пользователи могут заметить, что запросы с помощью Claude Haiku 4.5 возвращают ошибки или тайм-аут. В настоящее время мы не видим никаких проблем с другими моделями. В качестве обходного пути пользователи могут выбрать другую модель. Мы активно изучаем эту проблему и постараемся предоставить обновление в течение 30 минут.

2. 7 июля 2026 г. в 17:40 UTCinvestigating

   Мы продолжаем изучать эту проблему и предоставим еще одно обновление через 30 минут.

3. 7 июля 2026 г. в 18:07 UTCidentified

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

4. 7 июля 2026 г. в 19:42 UTCidentified

   Мы продолжаем работать над потенциальным исправлением и определением любых потенциальных факторов. Опять же, поскольку проблема локализована на моделях Haiku 4.5 в регионе Токио, мы рекомендуем пользователям временно использовать другую модель, если они испытывают какие-либо повышенные показатели ошибок. Мы приносим свои извинения за неудобства и скоро получим еще одно обновление.

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

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

6. 7 июля 2026 г. в 20:59 UTCresolved

   Этот вопрос решен. Treasure Work и tdx работают нормально, а модель Claude Haiku 4.5 в Токийском регионе больше не испытывает ошибок или тайм-аутов. Спасибо за ваше терпение.

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

1. 26 июня 2026 г. в 21:48 UTCidentified

   Мы испытываем ухудшение производительности запросов Hive в регионе США. Этот вопрос начался 25 июня 2026 года. Пользователи могут наблюдать более длительное, чем ожидалось, время выполнения запросов, особенно для длительных заданий с большими объемами данных. Мы определили причину и работаем над исправлением. Мы предоставим обновление через 30 минут.

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

   Мы испытываем ухудшение производительности запросов Hive в регионе США. Этот вопрос начался 25 июня 2026 года. Пользователи могут наблюдать более длительное, чем ожидалось, время выполнения запросов, особенно для длительных заданий с большими объемами данных. Мы определили причину. Для решения этой проблемы мы проверяем изменение конфигурации кластера до его применения в производственной среде. Мы предоставим обновление через 30 минут.

3. 26 июня 2026 г. в 22:57 UTCidentified

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

4. 26 июня 2026 г. в 23:57 UTCmonitoring

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

5. 27 июня 2026 г. в 01:13 UTCresolved

   Деградация производительности ульевых запросов в регионе США была решена. Мы успешно создали новый кластер и направили на него весь трафик. Сейчас системы работают нормально. Спасибо за ваше терпение.

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

1. 25 июня 2026 г. в 11:46 UTCresolved

   Некоторые результаты экспорта (экспорт данных) рабочих мест в США, Токио и регионах ЕС, возможно, потерпели неудачу или были отложены между 24 июня 2026 21:00 UTC и 25 июня 2026 05:26 UTC. В течение этого периода базовые вычислительные узлы были периодически нестабильными, что могло привести к прекращению работы по экспорту до завершения. В некоторых случаях работа может закончиться без четкого сообщения об ошибке. Проблема решена, все системы работают нормально. Целостность данных не затрагивается — исходные данные в данных о сокровищах не были затронуты; только поставка экспортных рабочих мест во внешние пункты назначения во время этого окна могла быть нарушена. Если во время этого окна вы запускали экспорт результатов / данных, мы рекомендуем подтвердить его завершение и повторно запустить его, если результат выглядит неполным. Мы также свяжемся с пострадавшими клиентами напрямую. Спасибо за ваше терпение.

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

1. 24 июня 2026 г. в 11:11 UTCresolved

   Мы определили задержку в записи данных о событиях электронной почты (таких как открытие, клик, отказ, события доставки и события ошибок) в таблицы событий клиентов. Пораженный период (приблизительно): - 22 июня, 03:45 UTC - 23 июня, 04:15 UTC - 23 июня, 07:00 UTC - 24 июня, 07:30 UTC В течение этих периодов запись данных о событиях по электронной почте задерживалась. Сама доставка электронной почты не пострадала — электронные письма были отправлены и получены в обычном режиме. Проблема решена, все системы работают нормально. Отложенные события были полностью обработаны. Если вы запускали запросы в таблицах событий или событий ошибок в течение затронутых периодов, мы предлагаем повторно запустить эти запросы, чтобы получить точные результаты. Приносим извинения за любые неудобства.

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

1. 5 мая 2026 г. в 16:20 UTCidentified

   Incident: Real-time Profile Deletion Workflow Failures Status: Identified Impacted Regions: EU01, US01, Tokyo, AP03 (USA) Update (May 5, 2026 - 11:19 AM CDT) We have identified the root cause of the failures affecting Real-time (RT) bulk profile deletion, load, and stitch workflows in the affected regions. Summary of the Issue: A backend configuration issue resulted in a loss of necessary permissions for the service responsible for processing Real-time bulk profile operations. As a result, impacted workflows are failing with an "Authorization" or "400" error when attempting to invoke internal functions. Current Status: Our engineering team has developed a fix and is currently in the process of deploying it to all affected regions. We expect service to be restored shortly after the deployment is completed. We will provide a further update once the fix has been fully deployed and we have confirmed that workflow processing has returned to normal.

2. 5 мая 2026 г. в 16:23 UTCidentified

   We are continuing to work on a fix for this issue.

3. 5 мая 2026 г. в 17:43 UTCresolved

   We have applied the fix, and are observing that traffic is flowing correctly now.

1. 27 апреля 2026 г. в 17:31 UTCmonitoring

   Between 8:05 AM and 8:30 AM PDT, customers operating in the EU01 (Europe) region may have experienced intermittent errors (5xx) affecting two primary areas: Data Ingestion: Errors when attempting to send records via the Ingest API. Real-Time Personalization: Request failures for personalization and profile lookup services. The disruption was caused by an service interruption with an upstream provider in our data processing layer within the eu-central-1 region. This prevented our systems from successfully persisting incoming data to our streaming infrastructure and executing real-time lookups during the affected window. The upstream provider has confirmed the issue is resolved. Our engineering team monitored the recovery, and we have confirmed that all services in the EU01 region have returned to normal operating parameters. Data Integrity: For data ingestion, records that were rejected with a retryable error code during this window should be resubmitted. Records that have already been successfully ingested following the recovery require no further action. Personalization: Real-time request success rates have returned to 100%. We are continuing to monitor the stability of the region. We apologize for any inconvenience this may have caused to your operations. For further questions, please contact our support team at [email protected].

2. 27 апреля 2026 г. в 18:25 UTCresolved

   The upstream provider has restored service.

1. 18 февраля 2026 г. в 20:45 UTCinvestigating

   We are investigating a possible problem currently affecting Treasure Insights. We will provide an update as soon as we know more.

2. 18 февраля 2026 г. в 21:27 UTCidentified

   We have partially resolved the incident. We are continuously working to resolve the incident.

3. 18 февраля 2026 г. в 21:32 UTCmonitoring

   The performance went back to normal, and no errors are observed now. We will monitor at least for 15 minutes.

4. 18 февраля 2026 г. в 22:00 UTCresolved

   This incident has been resolved.

1. 21 января 2026 г. в 02:55 UTCinvestigating

   Starting at approximately 17:00 PST, we observed increased latency affecting all operations accessing table resources in Plazma. At around 19:00 PST, we applied temporary tuning to the database managing table resources and confirmed recovery based on internal performance metrics. We are currently continuing to monitor the system to ensure overall performance remains stable. Visible impacts are: - Streaming, Mobile, and JavaScript/Browser imports may delay - Jobs execution may delay - Table creation may error - Console execution may delay - Plazma Public API may return errors - Treasure Workflow may delay and fail - Workflow REST API may be unavailable - Workflow operations in Console and CLI may become unavailable - Presto JDBC/ODBC queries and CDP segmentation queries may fail - Console Table preview update may delay - The REST API to submit and cancel jobs may be unavailable - Data Connector Integrations may become unavailable - ADH (Ads Data Hub) and DCR (Data Clean Room) service may be unavailable - ADL (Active Data Layer) service may be unavailable We will send an additional update in 30 minutes

2. 21 января 2026 г. в 03:37 UTCidentified

   We identified the same issue in the Tokyo region and applied database parameter tuning. We are currently assessing the impact of this change on system performance. As a result of this temporary mitigation applied in both the US and Tokyo regions, the following impact is observed: In Data Workbench, updates to table metadata for row counts and preview data are temporarily paused. We will continue monitoring and provide further updates as we make progress.

3. 21 января 2026 г. в 03:40 UTCidentified

   We are continuing to work on a fix for this issue.

4. 21 января 2026 г. в 04:06 UTCidentified

   Performance in the Tokyo region improved at approximately 12:50 JST. The Tokyo region had been experiencing gradually increasing performance degradation since around 09:00 JST. We are currently proceeding with the steps to resume updates of table metadata in Data Workbench. Due to the temporary pause of metadata updates, application metrics that rely on this information, such as Parent Segment size, have also been temporarily not updated. We will continue monitoring the system and share further updates as needed.

5. 21 января 2026 г. в 04:12 UTCidentified

   In the US region, table metadata updates have been resumed. At this point, the system in the US region is expected to be fully recovered, and we are continuing to monitor it closely. For the Tokyo region, metadata updates will be resumed after we complete confirmation of system performance. We will provide another update when this step begins.

6. 21 января 2026 г. в 04:41 UTCmonitoring

   The system in the US region is operating normally with no observed issues. In the Tokyo region, table metadata updates have also been resumed. At this point, the Tokyo region is expected to be fully recovered, and we will continue to monitor system performance. Once stability is fully confirmed, we plan to close this status page.

7. 21 января 2026 г. в 05:07 UTCresolved

   Incident Impact Summary (Plazma / Table Resources) We have confirmed that the system in the Tokyo region is operating normally with no remaining issues. What happened - All operations accessing Plazma table resources experienced increased latency. When - US region: 17:00 PST – 18:40 PST - Tokyo region: 09:00 JST – 12:50 JST Temporary impact during recovery - Updates to table row counts and preview data were temporarily paused. Recovery status - US region: Table metadata updates resumed at 20:00 PST. - Tokyo region: Table metadata updates resumed at 13:40 JST. Both regions are now fully recovered. Data integrity - No data loss or data corruption occurred. We will prepare and publish a post-mortem document to explain the circumstances under which this incident occurred one day after the recent system maintenance. With this confirmation, the incident is now closed.

8. 26 января 2026 г. в 18:36 UTCpostmortem

   ## Post-Mortem Summary This incident was related to a database maintenance performed on January 19, during which management of Plazma table resources was migrated from the existing RDBMS to a dedicated Aurora database. The purpose of this change was to better isolate table resource workloads and improve long-term scalability. The migration itself completed successfully, and both the original database and the newly introduced Aurora database were operating normally immediately after the maintenance. On the following day, when internal batch processes began running, the newly introduced database experienced unexpected load. Investigation determined that the internal batch system was configured to connect to the master database endpoint instead of a reader endpoint. As a result, internal batch processing competed with user-facing requests, causing increased latency when accessing table resources. To mitigate the impact and enable rapid recovery, temporary database tuning was applied. This tuning was intended solely as a short-term measure to stabilize the system and has since been fully reverted. The permanent fix consisted of correcting the configuration of the internal batch system so that it accesses the appropriate database endpoint. Following these actions, system performance recovered in both the US and Tokyo regions, and all services returned to normal operation. No data loss or data corruption occurred. To prevent similar issues in the future, we are reviewing our configuration and deployment practices, including reducing configuration differences between staging and production environments and strengthening validation of database endpoints used by internal workloads.

1. 10 декабря 2025 г. в 06:03 UTCresolved

   An unexpected behavior occurred in the REST API "GET /v3/job/result/{job_id}" which caused it to return only a partial set of results. This issue stemmed from an update to the job result download mechanism implemented around 2025/12/09 01:00 (UTC). The issue was resolved after a fix was applied around 2025/12/10 04:36(UTC). The affected API is used through the following methods: - Directly calling the REST API - Using functions in libraries (e.g., pytd) that reference job results - Toolbelt commands that refers to job results - Setting store_last_results:true in the td>:/td_run> operator in Treasure Workflows - Using the td_for_each>, td_wait> and td_wait_table>: operators in Treasure Workflows Unfortunately, we are unable to identify which API requests were affected. Please compare the number of results retrieved by your job with the download results to see if you were affected. We sincerely apologize for the inconvenience this has caused.

1. 5 декабря 2025 г. в 09:18 UTCinvestigating

   We are currently experiencing issues accessing Treasure Insights. Our investigation has identified that this is caused by an outage with a third-party service provider utilized by Treasure Insights. We are monitoring the situation and working with the provider to resolve the issue. We will provide updates as soon as more information becomes available.

2. 5 декабря 2025 г. в 09:22 UTCmonitoring

   The third-party service provider has implemented a fix. We are monitoring the results.

3. 5 декабря 2025 г. в 09:30 UTCresolved

   We confirmed the third-party service is now operational. The incident has been resolved.

1. 5 ноября 2025 г. в 03:49 UTCinvestigating

   We have encountered a temporary issue with the availability of Premium Audit Logs for Artificial Intelligence services (AI Agent Foundry and Audience Agent) during the period of November 4th 23:19:26 UTC to November 5th 00:57:55 UTC. While some data during this period may not have been captured, our engineering team is actively investigating the situation. We are taking all necessary steps to restore full service and ensure that all future logs are recorded without issue. We apologize for any inconvenience this may have caused and will keep you updated on our progress.

2. 5 ноября 2025 г. в 03:55 UTCmonitoring

   A fix has been implemented and we are monitoring the results.

3. 5 ноября 2025 г. в 07:58 UTCresolved

   Services have been restored to normal operations, and all of our systems are reporting healthy once again. If you observe any lingering issues, please connect with our support team, and we would be happy to help: https://docs.treasuredata.com/articles/#!pd/contacting-treasure-data-support

1. 20 октября 2025 г. в 08:53 UTCinvestigating

   We are aware of an issue affecting log writing and reading for the Profile API in all regions. This is due to an incident with an upstream service. Our team is monitoring the provider's status. We will provide an update shortly.

2. 20 октября 2025 г. в 10:15 UTCinvestigating

   We are also investigating reports indicating that this incident might be causing login errors for customers using SSO (Single Sign-On) to log into our service. Customers attempting a new login via SSO may be unable to access the service. We believe users who are already logged in (have an active session) and users logging in with methods other than SSO (e.g., username/password) are not affected by this login issue. We are working to confirm this.

3. 20 октября 2025 г. в 15:09 UTCinvestigating

   Our upstream service provider is gradually recovering its services, and our services are gradually recovering too. SSO login is working fine, however profile API 1.0 is still recovering its service with latency. As the upstream service provider incident is still ongoing, you might still encounter unexpected errors or issues. We will closely monitoring our services and work with our upstream service provider.

4. 20 октября 2025 г. в 18:53 UTCidentified

   We are continuing to work with our service provider to track this issue. Customers may continue to observe higher latency than normal and may notice delays in processing. We are monitoring the situation closely and are adding additional capacity in anticipation of a recovery. As this situation develops, we will keep you updated on any changes in expected behavior.

5. 20 октября 2025 г. в 21:32 UTCresolved

   Delays should be improving for all customers, and services should be returning to normal. Given the similarity of the two issues, we'll continue tracking any concerns related to this interruption as part of the "[US Region] Issue Affecting Treasure Data Services" issue. For further updates, please track here: https://status.treasuredata.com/incidents/w7v5wtmkdllj If you experience continued issues specifically relating to our Profiles API or SSO Logins, please contact our support team: https://docs.treasuredata.com/articles/#!pd/contacting-treasure-data-support

1. 20 октября 2025 г. в 08:27 UTCinvestigating

   We are currently investigating an issue originating from an upstream service provider used by our infrastructure. This may be affecting the normal operation of some Treasure Data services. We are working to determine the scope of the impact. Observed symptoms may include, but are not limited to, the failure of various jobs (such as Trino, Hive, Result Export, Import, and Custom Script execution) to start. Our team is actively monitoring the situation and working with the provider. We will provide further updates as more information becomes available.

2. 20 октября 2025 г. в 15:05 UTCinvestigating

   Our upstream service provider is gradually recovering its services, and our services are gradually recovering too. Most of our Treasure Data services are back to normal except for Custom Script, autoML and realtime services such as profile API 1.0, and realtime 2.0. As the upstream service provider incident is still ongoing, you might still encounter unexpected errors or issues. We will closely monitoring our services and work with our upstream service provider.

3. 20 октября 2025 г. в 18:49 UTCinvestigating

   We are continuing to monitor ongoing recovery efforts, and most of our systems remain operating. As the situation with our upstream provider develops we will react if we discover any new issues. At this time, we are observing delays in our systems, including Profile API 1.0 and Realtime 2.0. Requests are being processed as they have been received, but users may see a slowdown in results, and may notice delays when updating configurations or journeys. You may notice continued slower performance or unexpected errors. We are working with our service provider to address these issues and will provide an update with new information soon.

4. 20 октября 2025 г. в 19:35 UTCmonitoring

   We are seeing continued recovery across our systems, and are currently working to process any buffered or delayed messages. Customers may continue to observe delays in data processing and may notice slower-than-usual processing of configuration changes. We expect these delays to decrease as our systems catch up. Our team is continuing to track recovery closely, and we'll inform you of any new developments.

5. 20 октября 2025 г. в 21:42 UTCmonitoring

   Service levels continue to improve as upstream services become more stable. Users may still see processing delays, though those should be decreasing as we process the backlog of messages from this event. We are continuing to monitor our systems and deploy capacity as needed. We will update you with additional information as it develops.

6. 20 октября 2025 г. в 23:15 UTCresolved

   Services have been restored to normal operations, and all of our systems are reporting healthy once again. If you observe any lingering issues, please connect with our support team, and we would be happy to help: https://docs.treasuredata.com/articles/#!pd/contacting-treasure-data-support