Treasure Data 中断历史

1. 2026年10月22日 UTC 03:24identified

   自2026年10月13日 UTC凌晨2:00起,一些从Amazon S3读取 Parquet 文件的导入任务成功完成,但将日期和时间列作为文本(字符串)而不是数字(长)加载. 如果目标表格已经定义了这些列的长度,则导入的值为空 (NULL). 只有存储在 Parquet 文件内的日期或时间类型的列受到影响. 其他列和其他数据连接器不受影响. 我们已查明了原因,即10月13日的发布中引入的改变,并正在准备解决。 我们正在评估影响的全部范围。 我们将在30分钟后提供最新情况.

2. 2026年10月22日 UTC 04:06identified

   我们自协调世界时2026年10月13日02:00起,已确定亚马逊S3 Parquet进口加载日期和时间栏的原因为文本(字符串)而不是数字(长),并正在执行固定. 在固定装置部署之前,受影响的导入任务继续以文字装入这些列来成功完成。 其他列和其他数据连接器不受影响. 我们正在核实在此期间输入的数据的完整性。 我们将在1小时内提供最新情况.

3. 2026年10月22日 UTC 06:22identified

   我们确定亚马逊 S3 Parquet 进口加载日期和时间列的原因为文字(字符串)而不是数字(长)自2026年10月13日 UTC凌晨2:00起,并且正在部署固定. 在固定装置部署之前,受影响的导入任务将继续以文本装入这些列来完成。 其他列和其他数据连接器不受影响. 我们正在核实在此期间输入的数据的完整性。 我们将在30分钟后提供最新情况.

4. 2026年10月22日 UTC 07:44monitoring

   我们为Amazon S3 Parquet进口的装入日期和时间栏安装了一个固定的文本。 2026年10月13日前,新的进口工作将这些列作为数字(长)加载。 我们正在监测以确保稳定。 我们将在30分钟后提供最新情况.

5. 2026年10月22日 UTC 10:15resolved

   导致亚马逊 S3 Parquet 导入时间和日期列作为文本(字符串)而不是数字(长)的问题已经解决. 2026年10月22日协调世界时07:40部署固定装置,2026年10月13日之前,新的进口工作将这些列作为数字(长)加载. 在协调世界时2026年10月13日02:00至协调世界时2026年10月22日07:40之间导入的数据可能包含受影响的日期和时间列. 我们将直接与受影响的客户联系。 我们为不便而道歉,并感谢你的耐心.

自动翻译自官方事件更新。

1. 2026年10月7日 UTC 04:21identified

   自UTC10月6日约22:55起,"财宝AI Voice"移动app的用户可能无法从他们的设备中传输出新的录音. 转移失败时出现"未经授权"错误. 这影响了Wi-Fi和蓝牙的传输. 我们已经查明了原因,正在部署一个解决办法。 已经移交的记录及其记录和摘要不受影响。 我们将在30分钟后提供最新情况.

2. 2026年10月7日 UTC 04:27identified

   我们正在继续努力解决这个问题。

3. 2026年10月7日 UTC 04:54monitoring

   我们安装了服务器侧修复器 用于宝藏AI Voice的录制传输故障 移动应用程序的新传输再次成功. 不需要应用程序更新 。 事件期间未能转移的记录可以再次从设备上转移. 我们正在监测以确保稳定.

4. 2026年10月7日 UTC 05:24resolved

   宝地AI Voice的录音传输故障已经解决. 所有系统都正常运行。 在协调世界时10月6日约22:55到协调世界时10月7日[固定时间]之间,新的录音无法从移动应用中传输. 我们安装了服务器端的修复装置,不需要更新应用程序。 在此期间未能转移的记录可以再次从设备中转移. 谢谢你的耐心.

自动翻译自官方事件更新。

1. 2026年9月30日 UTC 04:36resolved

   9月28日(协调世界时下午5:30)至9月29日(协调世界时下午6:30)之间,没有定出属性更新的批量段的客户会发现批量数据无法装入反应堆的工作失败. 客户在等待配置修改更新时会看到出错. 其影响是任何实时应用、个性化或该窗口期间的运动都可能依赖于陈旧的批量属性数据。 该系统已经恢复,工作流程目前正在发送最新数据.

自动翻译自官方事件更新。

1. 2026年9月29日 UTC 17:22investigating

   我们目前正在调查美国(AWS)地区未将数据装入反应堆的批量出口工作。 数据更新将延迟至24小时。 我们一小时后更新状态.

2. 2026年9月29日 UTC 18:20monitoring

   一项固定措施已经实施,我们观察到工作正在取得成功.

3. 2026年9月29日 UTC 21:18resolved

   这一事件已经解决,我们的支助小组将跟踪受影响的客户.

自动翻译自官方事件更新。

1. 2026年9月28日 UTC 03:41investigating

   我们目前正在经历一个问题,即我们公司和企业支助计划的Live Chat功能。 我们的团队正在积极调查。 您仍可通过电子邮件联系我们的支援团队@treasure.ai。 我们赞赏你的耐心,并对任何不便表示歉意.

2. 2026年9月28日 UTC 13:16resolved

   我们确定并解决了影响公司和企业支助计划实况聊天功能的问题。 该服务已完全恢复,正常运行。 我们对此可能造成的不便表示诚挚的歉意,并感谢你的耐心.

自动翻译自官方事件更新。

1. 2026年9月17日 UTC 03:14identified

   我们已查明影响我们网络界面交易邮件的延误原因,并正在寻找解决办法。 客户可能收到一些电子邮件的时间比预计的要晚。 受影响的电子邮件包括系统通知和密码重置请求. 其他电子邮件服务正常运行。 我们将在30分钟内提供另一个最新情况.

2. 2026年9月17日 UTC 03:44monitoring

   交易邮件发送正在恢复,但可能需要一些时间才能恢复到正常水平。 我们正在继续监测这项服务。 其他电子邮件服务没有受到影响。 我们将在两小时内再提供一次最新情况.

3. 2026年9月17日 UTC 06:10monitoring

   交易邮件发送正在恢复,但可能需要一些时间才能恢复到正常水平。 我们正在继续监测这项服务。 其他电子邮件服务没有受到影响。 我们会在24小时内提供另一个最新情况.

4. 2026年9月18日 UTC 06:51monitoring

   交易邮件发送正在恢复,但可能需要一些时间才能恢复到正常水平。 交付情况继续稳步改善。 我们正在继续监测这项服务。 其他电子邮件服务没有受到影响。 我们将在7天内提供另一个最新情况.

5. 2026年9月25日 UTC 04:44monitoring

   交易邮件发送继续恢复,但可能需要一些时间才能恢复到正常水平. 服务提供情况保持稳定,我们正在继续监测服务情况。 其他电子邮件服务没有受到影响。 我们将在七天内提供另一个最新情况,或者在条件发生变化时提前提供.

6. 2026年10月5日 UTC 02:19monitoring

   我们正在继续监测任何其他问题.

7. 2026年10月5日 UTC 02:20monitoring

   交易邮件发送继续恢复,但可能需要一些时间才能恢复到正常水平. 服务提供情况保持稳定,我们正在继续监测服务情况。 其他电子邮件服务没有受到影响。 如果条件发生变化,我们将在14天内提供另一个最新情况.

8. 2026年10月16日 UTC 00:04resolved

   我们不再看到任何拖延交货的情况。 我们加强了我们的监测,并将继续注意中断。 如果你发现有问题 请联系支援组寻求援助.

自动翻译自官方事件更新。

1. 2026年7月27日 UTC 08:29resolved

   7/25至今天,即上午11:30的7/27,我们经历了影响BulkLoad(数据连接器进口)、结果出口(活动)和Bulk进口的性能退化问题。 在今天上午收到报告后,我们的工程小组调查了这一问题,并确定在特定条件下(内部部件通信日益延误)的系统负荷高是根源。 这个问题已经通过服务器节点的完全旋转来解决,从11:30 AM JST开始恢复了完全性能. 我们对造成的任何不便表示诚挚的歉意。 我们目前正在审查我们的监测和警报规则,以防止今后出现类似问题.

自动翻译自官方事件更新。

1. 2026年7月7日 UTC 17:04investigating

   我们正观察东京地区 " 财富工作 " 和 " tdx " 的退化表现。 这个问题仅限于东京地区的克洛德·海库 4.5模式. 用户可能注意到使用 Claude Haiku 4.5 返回错误或超时的请求. 目前,我们不认为其他模式有任何问题。 作为一种工作,用户可以选择不同的模型. 我们正在积极调查这一问题,并力求在30分钟后提供最新情况.

2. 2026年7月7日 UTC 17:40investigating

   我们正在继续调查这一问题,并将在30分钟后再次提供最新情况.

3. 2026年7月7日 UTC 18:07identified

   我们正在继续探讨这一问题,并正在评估可能的解决办法。 测试完成后我们会尽快更新.

4. 2026年7月7日 UTC 19:42identified

   我们正在继续通过潜在的解决办法来努力,并努力确定任何潜在的促成因素。 同样,由于这个问题被本地化到东京地区的Haiku 4.5模型,我们建议用户在遇到高误差率时暂时使用不同的模型. 我们对此不便表示歉意,并将很快获得另一个最新情况.

5. 2026年7月7日 UTC 20:27monitoring

   一项措施已经执行,我们正在监测结果.

6. 2026年7月7日 UTC 20:59resolved

   这个问题已经得到解决。 宝地活活和tdx正常运行,东京地区的克洛德·海库 4.5模式不再出错或超时. 谢谢你的耐心.

自动翻译自官方事件更新。

1. 2026年6月26日 UTC 21:48identified

   我们正在经历蜂巢调查 美国地区的性能下降。 这个问题从2026年6月25日开始. 用户观察到的查询执行时间可能比预期的要长,对于数据量大的长期工作尤其如此。 我们已经查明了原因,并且正在设法解决问题。 我们将在30分钟后提供最新情况.

2. 2026年6月26日 UTC 22:22identified

   我们正在经历蜂巢调查 美国地区的性能下降。 这个问题从2026年6月25日开始. 用户观察到的查询执行时间可能比预期的要长,对于数据量大的长期工作尤其如此。 我们已经确定了原因。 为了解决这个问题,我们正在验证一个集群配置变化,然后将其应用于生产环境。 我们将在30分钟后提供最新情况.

3. 2026年6月26日 UTC 22:57identified

   我们正在继续努力解决问题。 我们的团队正在验证一个集群配置的改变,然后将其应用于生产环境. 我们将在30分钟后提供最新情况.

4. 2026年6月26日 UTC 23:57monitoring

   我们为一个新的集群提供了足够的能力,目前正在为它寻找工作。 随着集群稳定,查询性能有望逐步恢复. 我们正在密切监测局势。 我们将在1小时内提供最新情况.

5. 2026年6月27日 UTC 01:13resolved

   美国地区蜂窝查询性能退化问题已经解决. 我们成功地提供了一个新的组群,并将所有交通线路通向它。 系统现在正常运行。 谢谢你的耐心.

自动翻译自官方事件更新。

1. 2026年6月25日 UTC 11:46resolved

   已解决——在协调世界时6月24日2026:00至协调世界时2026年6月25日05:26之间,美国,东京,欧盟地区的一些结果输出(数据输出)工作可能已经失败或被延迟. 在此期间,基础计算节点间歇性不稳定,可能导致出口工作在完成前被终止. 在某些情况下,一项受影响的工作可能在没有明确错误信息的情况下结束。 这个问题已经解决,所有系统都正常运行。 数据完整性没有受到影响——"财富"数据中的源数据没有受到影响;只有在这个窗口期间向外出目的地提供出口工作才能被中断. 如果您在此窗口中运行了结果/ 数据导出, 我们建议确认它是否已完成, 如果输出看起来不完整, 我们建议重新运行它 。 我们还将直接与受影响的客户联系。 谢谢你的耐心.

自动翻译自官方事件更新。

1. 2026年6月24日 UTC 11:11resolved

   我们发现在客户事件表记录电子邮件事件数据(如打开、点击、回弹、发送事件和出错事件)方面出现延误。 受影响时期(近似时间): - 6月22日 03:45 UTC – 6月23日 04:15 UTC - 协调世界时6月23日07:00 - 协调世界时6月24日07:30 在这些期间,电子邮件事件数据记录被推迟。 电子邮件发送本身没有受到影响——电子邮件的发送和接收是正常的。 这个问题已经解决,所有系统都正常运行。 已全面处理被拖延的事件。 如果您在受影响的期间运行了事件或出错事件表上的查询,我们建议重运行这些查询以获得准确的结果。 我们为任何不便而道歉.

自动翻译自官方事件更新。

1. 2026年5月5日 UTC 16:20identified

   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日 UTC 16:23identified

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

3. 2026年5月5日 UTC 17:43resolved

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

1. 2026年4月27日 UTC 17:31monitoring

   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日 UTC 18:25resolved

   The upstream provider has restored service.

1. 2026年2月18日 UTC 20:45investigating

   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日 UTC 21:27identified

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

3. 2026年2月18日 UTC 21:32monitoring

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

4. 2026年2月18日 UTC 22:00resolved

   This incident has been resolved.

1. 2026年1月21日 UTC 02:55investigating

   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日 UTC 03:37identified

   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日 UTC 03:40identified

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

4. 2026年1月21日 UTC 04:06identified

   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日 UTC 04:12identified

   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日 UTC 04:41monitoring

   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日 UTC 05:07resolved

   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日 UTC 18:36postmortem

   ## 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日 UTC 06:03resolved

   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日 UTC 09:18investigating

   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日 UTC 09:22monitoring

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

3. 2025年12月5日 UTC 09:30resolved

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

1. 2025年11月5日 UTC 03:49investigating

   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日 UTC 03:55monitoring

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

3. 2025年11月5日 UTC 07:58resolved

   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日 UTC 08:53investigating

   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日 UTC 10:15investigating

   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日 UTC 15:09investigating

   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日 UTC 18:53identified

   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日 UTC 21:32resolved

   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日 UTC 08:27investigating

   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日 UTC 15:05investigating

   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日 UTC 18:49investigating

   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日 UTC 19:35monitoring

   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日 UTC 21:42monitoring

   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日 UTC 23:15resolved

   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