Treasure Data の障害履歴

1. 2026年10月22日 3:24 UTCidentified

   10月13日、2026 02:00 UTC 以降、Amazon S3 からパーケットファイルを読み込み、日付と時刻の列をテキスト (文字列) ではなく、数値 (長い) として読み込みます。 行先テーブルがすでにこれらの列を定義している場合は、インポートされた値が空の(NULL)です。 パーケットファイルの日付または時刻タイプで保存された列のみが影響されます。 その他の列やその他のデータコネクタは影響しません。 10月13日発売で導入された変更、修正の準備をしました。 インパクトのフルスコープを評価しています。 更新は30分で行います.

2. 2026年10月22日 4:06 UTCidentified

   Amazon S3 Parquet は、10月13日(金)より数値(長)ではなく、読み込み日時列をテキスト(文字列)としてインポートし、修正を実施している原因を特定しました。 修正が展開されるまで、影響を受けたインポートジョブは、テキストとして読み込まれたこれらの列で正常に完了します。 その他の列やその他のデータコネクタは影響しません。 この期間中にインポートされたデータの完全性を検証しています。 1時間で更新を行います.

3. 2026年10月22日 6:22 UTCidentified

   Amazon S3 Parquet は、10月13日からの数値(長)の代わりに、日付と時刻の列をテキスト(文字列)として読み込み、修正をデプロイしています。 修正が展開されるまで、影響を受けたインポートジョブはテキストとして読み込まれたこれらの列で引き続き完了します。 その他の列やその他のデータコネクタは影響しません。 この期間中にインポートされたデータの完全性を検証しています。 更新は30分で行います.

4. 2026年10月22日 7:44 UTCmonitoring

   Amazon S3 Parquet では、日付と時刻の列をテキストとして読み込みます。 新規のインポートジョブは、これらの列を数字(長)として読み込みます。 私たちは、安定性を確保するために監視しています。 更新は30分で行います.

5. 2026年10月22日 10:15 UTCresolved

   Amazon S3 Parquet が数値(long)の代わりに日付と時刻の列をテキスト(string)として読み込むためにインポートする問題が解決されました。 修正は10月22日、2026日、07:40 UTCで展開され、新しいインポートジョブは10月13日、数字(長)として読み込みました。 10月13日、2026 02:00 UTCと10月22日、2026 07:40 UTCの間でインポートされたデータは、影響を受けた日付と時刻の列が含まれている場合があります。 影響を受けたお客様に直接ご連絡いたします。 ご迷惑をおかけし、ご迷惑をおかけいたしますが、何卒宜しくお願い申し上げます.

公式のインシデント更新を自動翻訳しています。

1. 2026年10月7日 4:21 UTCidentified

   10月6日には、Treasure AI 音声モバイルアプリのユーザが10月6日で約22:55 UTC を転送できない可能性があります。 転送は「無許可」エラーで失敗します。 これは、Wi-FiとBluetooth転送の両方に影響します。 原因を特定し、修正を展開しています。 既に転送された記録、およびそのトランスクリプトと要約は影響を受けません。 更新は30分で行います.

2. 2026年10月7日 4:27 UTCidentified

   この問題の修正には引き続き取り組んでいます。

3. 2026年10月7日 4:54 UTCmonitoring

   トレジャーAIボイスの録画転送失敗のサーバー側修正を行いました。 モバイルアプリからの新しい転送が再び成功しています。 アプリの更新は不要です。 インシデント中に転送できなかった録画は、デバイスから再び転送できます。 私たちは、安定性を確保するために監視しています.

4. 2026年10月7日 5:24 UTCresolved

   トレジャーAIボイスでの録画転送失敗が解決しました。 全てのシステムは正常に動作しています。 10月6日と10月7日(火)のUTC前後で約22:55 UTCがモバイルアプリから転送できません。 サーバ側の修正を実装し、アプリの更新は不要です。 この期間中に転送できなかった録画は、デバイスから再び転送できます。 ありがとうございます.

公式のインシデント更新を自動翻訳しています。

1. 2026年9月30日 4:36 UTCresolved

   9月28日(金)(午後5時30分)と9月29日(火)(午後6時30分)の間、予定されている属性の更新があったバッチセグメントがないお客様は、バッチデータをReactorに読み込むのを防ぐのに失敗したジョブが見られた。 設定の変更が更新されるのを待ちながら、エラーが発生しました。 影響は、そのウィンドウ内のリアルタイムアプリケーション、パーソナライゼーション、またはキャンペーンが、Stale Batch 属性データに依存している可能性があります。 システムが復元され、ワークフローが更新されたデータを送信できるようになりました.

公式のインシデント更新を自動翻訳しています。

1. 2026年9月29日 17:22 UTCinvestigating

   現在、米国(AWS)地域のReactorにデータを読み込むのに失敗したバッチエクスポートジョブを調査しています。 データ更新は24時間遅れます。 1時間でステータスを更新します.

2. 2026年9月29日 18:20 UTCmonitoring

   修正が実施され、ジョブが成功していることが確認されています.

3. 2026年9月29日 21:18 UTCresolved

   この事件は解決され、当社のサポートチームは影響を受けたお客様とフォローアップします.

公式のインシデント更新を自動翻訳しています。

1. 2026年9月28日 3:41 UTCinvestigating

   現在、コーポレート・エンタープライズ・サポート・プランのライブチャット機能に関する問題が発生しています。 私たちのチームは積極的に調査しています。 [email protected] をメールで送信することで、いつも通りサポートチームにご連絡ください。 誠に有難うございます.

2. 2026年9月28日 13:16 UTCresolved

   企業・企業支援計画のライブチャット機能に影響を及ぼす問題を特定し解決しました。 サービスは完全に復元され、正常に動作しています。 誠に申し訳ございませんが、ご迷惑をおかけいたしますが、何卒宜しくお願い申し上げます.

公式のインシデント更新を自動翻訳しています。

1. 2026年9月17日 3:14 UTCidentified

   当社は、Webインターフェイスからトランザクションメールに影響を与える遅延の原因を特定し、解決に取り組んでいます。 お客様からは、この時期に予想以上のメールが届きます。 不具合メールには、システム通知とパスワードリセットリクエストが含まれます。 他のメールサービスは正常に動作しています。 更新は30分以内に行います.

2. 2026年9月17日 3:44 UTCmonitoring

   トランザクションメール配信は回復していますが、通常のレベルに戻るには時間がかかることがあります。 今後も監視を続けてまいります。 その他の電子メールサービスは、影響を受けません。 2時間以内に別の更新を行います.

3. 2026年9月17日 6:10 UTCmonitoring

   トランザクションメール配信は回復していますが、通常のレベルに戻るには時間がかかることがあります。 今後も監視を続けてまいります。 その他の電子メールサービスは、影響を受けません。 24時間体制で更新いたします.

4. 2026年9月18日 6:51 UTCmonitoring

   トランザクションメール配信は回復していますが、通常のレベルに戻るには時間がかかることがあります。 お届けは着実に改善し続けています。 今後も監視を続けてまいります。 その他の電子メールサービスは、影響を受けません。 弊社では、7日以内に別のアップデートを実施いたします.

5. 2026年9月25日 4:44 UTCmonitoring

   トランザクションメール配信は回復し続けていますが、通常のレベルに戻るには時間がかかることがあります。 配達は安定し、私達はサービスを監視し続けます。 その他の電子メールサービスは、影響を受けません。 条件が変更されたら、7日以内に別の更新を、または早く提供します.

6. 2026年10月5日 2:19 UTCmonitoring

   今後の問題がないか引き続き監視しています。

7. 2026年10月5日 2:20 UTCmonitoring

   トランザクションメール配信は回復し続けていますが、通常のレベルに戻るには時間がかかることがあります。 配達は安定し、私達はサービスを監視し続けます。 その他の電子メールサービスは、影響を受けません。 条件が変更された場合は、14日以内に別の更新をいたします.

8. 2026年10月16日 0:04 UTCresolved

   配送遅延を一切防ぎません。 モニタリングを強化し、中断を続けていきます。 万が一の配達に気付いた場合は、サポートチームにお問い合わせください.

公式のインシデント更新を自動翻訳しています。

1. 2026年7月27日 8:29 UTCresolved

   7月25日、本日、7月27日(日)11時11時30分より、バルクロード(データコネクタインポート)、結果エクスポート(アクティベーション)、バルクインポート(バルクインポート)に関する性能劣化問題を経験しました。 翌朝、当社のエンジニアリングチームは、根本的な原因として、特定の条件(内部コンポーネント通信の遅延を減少させる)の下で問題を調査し、高システム負荷を特定しました。 サーバノードのフル回転で解決し、フルパフォーマンスを午前11時30分に復元しました。 ご迷惑をおかけいたしますが、何卒宜しくお願い申し上げます。 今後同様の問題を防ぐため、モニタリングやアラートルールを見直しています.

公式のインシデント更新を自動翻訳しています。

1. 2026年7月7日 17:04 UTCinvestigating

   東京地域における宝物・tdxの劣化性能を観察しています。 この問題は東京地方のクロード俳句4.5モデルに限られます。 ユーザーは、Claude俳句4.5のエラーやタイムアウトのリクエストに気づくことがあります。 現時点では、他のモデルの問題は見られません。 ワークアラウンドとして、異なるモデルを選択できます。 本件を積極的に調査し、30分で更新する予定です.

2. 2026年7月7日 17:40 UTCinvestigating

   この問題を調査し、30分で別の更新を行います.

3. 2026年7月7日 18:07 UTCidentified

   今後もこの問題を探求し続けていきますが、現在では潜在的な修正を評価しています。 試験が完了次第、更新いたします.

4. 2026年7月7日 19:42 UTCidentified

   私たちは、潜在的な修正を通して働き続け、潜在的な貢献要因を特定するために働いています。 繰り返しますが、この問題は東京地域の俳句4.5モデルにローカライズされているため、高値の誤差が発生すると、一時的に別のモデルを使用することをお勧めします。 ご迷惑をおかけしますが、もうしばらくお待ち下さい.

5. 2026年7月7日 20:27 UTCmonitoring

   修正を実装し、結果を監視しています.

6. 2026年7月7日 20:59 UTCresolved

   この問題は解決しました。 トレジャーワークとtdxは普通に動作しており、東京地域のクロード俳句4.5モデルはエラーやタイムアウトを経験しません。 ありがとうございます.

公式のインシデント更新を自動翻訳しています。

1. 2026年6月26日 21:48 UTCidentified

   米国地域におけるハイブクエリのパフォーマンス劣化を経験しています。 2026年6月25日(水)より発売されました。 ユーザーは、想定されるクエリ実行時間よりも長く観察できます。特に、大量のデータ量で長時間のジョブを監視できます。 原因を特定し、修正に取り組んでいます。 更新は30分で行います.

2. 2026年6月26日 22:22 UTCidentified

   米国地域におけるハイブクエリのパフォーマンス劣化を経験しています。 2026年6月25日(水)より発売されました。 ユーザーは、想定されるクエリ実行時間よりも長く観察できます。特に、大量のデータ量で長時間のジョブを監視できます。 原因を特定しました。 これに対処するため、生産環境に適用する前にクラスター構成変更を有効にします。 更新は30分で行います.

3. 2026年6月26日 22:57 UTCidentified

   修正作業を続けております。 当社のチームは、生産環境に適用する前にクラスター構成変更を有効にします。 更新は30分で行います.

4. 2026年6月26日 23:57 UTCmonitoring

   十分な容量を持つ新しいクラスターを準備し、ジョブをルーティングできるようになりました。 クエリのパフォーマンスは、クラスターが安定するように徐々に回復することが期待されます。 状況を密接に監視しています。 1時間で更新を行います.

5. 2026年6月27日 1:13 UTCresolved

   米国地域におけるハイブなクエリ性能劣化が解決しました。 新たなクラスターを配備し、すべてのトラフィックをルート化しました。 システムが正常に動作しています。 ありがとうございます.

公式のインシデント更新を自動翻訳しています。

1. 2026年6月25日 11:46 UTCresolved

   解決済み — 米国、東京、EU地域における一部の結果のエクスポート(データエクスポート)ジョブは、6月24日、2026 21:00 UTCと6月25日、2026 05:26 UTCの間で失敗または遅れている可能性があります。 この期間中は、計算ノードの不足が断続的に不安定であったため、コンプリートする前にエクスポートジョブが終了する可能性があります。 一部のケースでは、影響を受けたジョブがエラーメッセージなしで終了することがあります。 問題は解決され、すべてのシステムは正常に動作しています。 データの整合性は影響されません。 宝データ内のソースデータは影響を受けていません。このウィンドウの間にエクスポートジョブの配送のみが中断された可能性があります。 このウィンドウで結果/データエクスポートを実行すると、出力が不完全に見えるかどうか確認して再実行することをお勧めします。 また、影響を受けたお客様に直接お問い合わせください。 ありがとうございます.

公式のインシデント更新を自動翻訳しています。

1. 2026年6月24日 11:11 UTCresolved

   電子メールイベントデータを録画する遅延(オープン、クリック、バウンス、配信イベント、エラーイベントなど)を顧客イベントテーブルに特定しました。 感染期間(目安): - 6月 22, 03:45 UTC – 6月 23, 04:15 UTC - 6月23日、07:00 UTC - 6月24日、UTC これらの期間中、メールイベントの記録が遅れていました。 メール配信自体は影響を受けていないため、メールが送信され、正常に受信されました。 問題は解決され、すべてのシステムは正常に動作しています。 遅延したイベントを完全に処理しました。 影響を受ける期間にイベントやerror eventテーブルに問い合わせた場合、これらのクエリを再実行して正確な結果を得ることができます。 大変申し訳ございません.

公式のインシデント更新を自動翻訳しています。

1. 2026年5月5日 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. 2026年5月5日 16:23 UTCidentified

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

3. 2026年5月5日 17:43 UTCresolved

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

1. 2026年4月27日 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. 2026年4月27日 18:25 UTCresolved

   The upstream provider has restored service.

1. 2026年2月18日 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. 2026年2月18日 21:27 UTCidentified

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

3. 2026年2月18日 21:32 UTCmonitoring

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

4. 2026年2月18日 22:00 UTCresolved

   This incident has been resolved.

1. 2026年1月21日 2: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. 2026年1月21日 3: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. 2026年1月21日 3:40 UTCidentified

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

4. 2026年1月21日 4: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. 2026年1月21日 4: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. 2026年1月21日 4: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. 2026年1月21日 5: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. 2026年1月26日 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. 2025年12月10日 6: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. 2025年12月5日 9: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. 2025年12月5日 9:22 UTCmonitoring

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

3. 2025年12月5日 9:30 UTCresolved

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

1. 2025年11月5日 3: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. 2025年11月5日 3:55 UTCmonitoring

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

3. 2025年11月5日 7: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. 2025年10月20日 8: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. 2025年10月20日 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. 2025年10月20日 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. 2025年10月20日 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. 2025年10月20日 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. 2025年10月20日 8: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. 2025年10月20日 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. 2025年10月20日 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. 2025年10月20日 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. 2025年10月20日 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. 2025年10月20日 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